- 17 Jun, 2019 7 commits
-
-
Shashank Sharma authored
ICL introduces a new gamma correction mode in display engine, called multi-segmented-gamma mode. This mode allows users to program the darker region of the gamma curve with sueprfine precision. An example use case for this is HDR curves (like PQ ST-2084). If we plot a gamma correction curve from value range between 0.0 to 1.0, ICL's multi-segment has 3 different sections: - superfine segment: 9 values, ranges between 0 - 1/(128 * 256) - fine segment: 257 values, ranges between 0 - 1/(128) - corase segment: 257 values, ranges between 0 - 1 This patch: - Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256), so that userspace can program with highest precision supported. - Changes default gamma mode (non-legacy) to multi-segmented-gamma mode. - Adds functions to program/detect multi-segment gamma. V2: Addressed review comments from Ville - separate function for superfine and fine segments. - remove enum for segments. - reuse last entry of the LUT as gc_max value. - replace if() ....cond with switch...case in icl_load_luts. - add an entry variable, instead of 'word' V3: Addressed review comments from Ville - extra newline - s/entry/color/ - remove LUT size checks - program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw - Change the comments in description of fine and coarse segments, and try to make more sense. - use 8 * 128 instead of 1024 - add 1 entry in LUT for GCMAX V4: Addressed review comments from Ville - Remove unused macro - missing shift entry in blue - pick correct entry for GCMAX - Added Ville's R-B Note: Tested and confirmed the programming sequence of odd/even registers in the HW. The correct sequence should be: ilk_lut_12p4_udw ilk_lut_12p4_ldw v5: Addressed Ville's review comments and renamed odd/even register helpers to be more consistent with the values. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1560321900-18318-5-git-send-email-uma.shankar@intel.com
-
Shashank Sharma authored
This patch renames function ivb_load_lut_10_max to ivb_load_lut_ext_max. V3: Added Vill'es r-b. Cc: Uma Shankar <uma.shankar@intel.com> Suggested-by:
-
Uma Shankar authored
Add macros to define multi segmented gamma registers V2: Addressed Ville's comments: Add gen-lable before bit definition Addressed Jani's comment - Use REG_GENMASK() and REG_BIT() V3: Addressed Ville's comments: - Put comments at the end of line. - Change the comment at start of ICL multisegmented gamma registers. Added Ville's r-b Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: -
Shashank Sharma authored
Currently, data type of gamma_lut_size & degamma_lut_size elements in intel_device_info is u16, which means it can accommodate maximum 64k values. In case of ICL multisegmented gamma, the size of gamma LUT is 256K. This patch changes the data type of both of these elements to u32. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> V4: Added Uma's r-b. Reviewed-by:
-
Maarten Lankhorst authored
They have been unused since rotation was added to drm core in 2015, time to get rid of them. Signed-off-by:
-
Jani Nikula authored
Add a new subdirectory for display code, and start off by moving modesetting output/encoder code. Judging by the include changes, this is a surprisingly clean operation. v2: - move intel_sdvo_regs.h too - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-2-jani.nikula@intel.com
-
Jani Nikula authored
Ensure intel_sdvo_regs.h is self-contained and remains that way. v2: - include <linux/compiler.h> for __packed (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 15 Jun, 2019 2 commits
-
-
Matt Roper authored
EHL defines two new MOCS table entries but is otherwise compatible with the ICL MOCS table. These table entries (16 and 17) should still be considered unused for ICL and as such their behavior remains undefined for that platform. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190530234014.22340-1-matthew.d.roper@intel.comReviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
Chris Wilson authored
While we need to flush the wakeref before parking, we do not need to perform the i915_gem_park() itself underneath the wakeref lock, merely the struct_mutex. If we rearrange the locks, we can avoid the unnecessary tainting. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614220616.24932-1-chris@chris-wilson.co.uk
-
- 14 Jun, 2019 16 commits
-
-
Chris Wilson authored
To continue the onslaught of removing the assumption of a global execution ordering, another casualty is the engine->timeline. Without an actual timeline to track, it is overkill and we can replace it with a much less grand plain list. We still need a list of requests inflight, for the simple purpose of finding inflight requests (for retiring, resetting, preemption etc). Signed-off-by:
-
Chris Wilson authored
We no longer track the execution order along the engine and so no longer need to enforce ordering of retire along the engine. Signed-off-by:
-
Chris Wilson authored
We need to keep the context image pinned in memory until after the GPU has finished writing into it. Since it continues to write as we signal the final breadcrumb, we need to keep it pinned until the request after it is complete. Currently we know the order in which requests execute on each engine, and so to remove that presumption we need to identify a request/context-switch we know must occur after our completion. Any request queued after the signal must imply a context switch, for simplicity we use a fresh request from the kernel context. The sequence of operations for keeping the context pinned until saved is: - On context activation, we preallocate a node for each physical engine the context may operate on. This is to avoid allocations during unpinning, which may be from inside FS_RECLAIM context (aka the shrinker) - On context deactivation on retirement of the last active request (which is before we know the context has been saved), we add the preallocated node onto a barrier list on each engine - On engine idling, we emit a switch to kernel context. When this switch completes, we know that all previous contexts must have been saved, and so on retiring this request we can finally unpin all the contexts that were marked as deactivated prior to the switch. We can enhance this in future by flushing all the idle contexts on a regular heartbeat pulse of a switch to kernel context, which will also be used to check for hung engines. v2: intel_context_active_acquire/_release Signed-off-by:
-
Daniele Ceraolo Spurio authored
intel_runtime_pm is the only thing they use from the i915 structure, so use that directly. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
Matching the underlying get/put functions. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
The functions where internally already only using the structure, so we need to just flip the interface. v2: rebase Signed-off-by:
-
Daniele Ceraolo Spurio authored
Focusing on the functions called in few places. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Asserts aside, all the code working on this structure is in intel_runtime_pm.c and uses the intel_ prefix, so move the structure to intel_runtime_pm.h and adopt the same prefix. Since all the asserts are now working on the runtime_pm structure, bring them across as well. v2: drop unneeded include (Chris), don't rename debugfs, rebase Signed-off-by:
-
Daniele Ceraolo Spurio authored
With this all the rpm assert-related functions consistently work on the i915_runtime_pm structure Signed-off-by:
-
Daniele Ceraolo Spurio authored
Quite a few of the call points have already switched to the version working directly on the runtime_pm structure, so let's switch over the rest and kill the i915-based asserts. v2: rebase Signed-off-by:
-
Daniele Ceraolo Spurio authored
As a first step towards updating the code to work on the runtime_pm structure instead of i915, rework all the internals to use and pass around that. v2: add comment for kdev (Jani), move rpm init after pdev init for mock_device Signed-off-by:
-
Matt Roper authored
This chicken bit should be set before enabling FBC to avoid screen corruption when the plane size has odd vertical and horizontal dimensions. It is safe to leave the bit set even when FBC is disabled. v2: - The bspec's name for this bit on these platforms ("Spare 14") is pretty meaningless. Let's rename the bit definition to something that more accurately reflects what the bit really does. (Clint) v3: - The chicken register was already defined (along with a few other gen9-specific bits) farther down. Just add the new bit definition there. (Clint) Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:Clint Taylor <Clinton.A.Taylor@intel.com>
-
Chris Wilson authored
We already use a mutex to serialise i915_reset() and wedging, so all we need it to link that into i915_request_wait() and we have our lock cycle detection. v2.5: Take error mutex for selftests Signed-off-by:
-
Chris Wilson authored
If we enter i915_request_wait() with an already completed request, but unsignaled dma-fence, signal the fence before returning. This allows us to execute any of the signal callbacks at the earliest opportunity. v2: Also signal after busyspin success Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614111053.25615-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since commit a679f58d ("drm/i915: Flush pages on acquisition"), we flush objects on acquire their pages and as such when we create an object for the purpose of writing into it, we do not need to manually flush. Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614111053.25615-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
refcount_t is our first line of defence against use-after-free, so let's enable it for debugging. Signed-off-by:
-
- 13 Jun, 2019 1 commit
-
-
Chris Wilson authored
As the fence registers only apply to regions inside the GGTT is makes more sense that we track these as part of the i915_ggtt and not the general mm. In the next patch, we will then pull the register locking underneath the i915_ggtt.mutex. Signed-off-by:
-
- 12 Jun, 2019 14 commits
-
-
Chris Wilson authored
drivers/gpu/drm/i915//gem/i915_gem_shrinker.c:142: warning: Function parameter or member 'shrink' not described in 'i915_gem_shrink' drivers/gpu/drm/i915//gem/i915_gem_shrinker.c:142: warning: Excess function parameter 'flags' description in 'i915_gem_shrink' drivers/gpu/drm/i915//intel_display.c:13443: warning: Function parameter or member '_state' not described in 'intel_atomic_check' drivers/gpu/drm/i915//intel_display.c:13443: warning: Excess function parameter 'state' description in 'intel_atomic_check' Signed-off-by:
-
Tvrtko Ursulin authored
Remove call sites in favour of uncore mmio accessors and remove the old macros. Signed-off-by:
-
Tvrtko Ursulin authored
Only a few call sites remain which have been converted to uncore mmio accessors and so the macro can be removed. Signed-off-by:
-
Tvrtko Ursulin authored
Only a few call sites remain which have been converted to uncore mmio accessors and so the macro can be removed. Signed-off-by:
-
Tvrtko Ursulin authored
Only a few call sites remain which have been converted to uncore mmio accessors and so the macro can be removed. ENGINE_POSTING_READ16 is added to replace one engine->mmio_base relative call site. Signed-off-by:
-
Tvrtko Ursulin authored
Only a few call sites remain which have been converted to uncore mmio accessors and so the macro can be removed. Signed-off-by:
-
Tvrtko Ursulin authored
Only a few call sites remain which have been converted to uncore mmio accessors and so the macro can be removed. Signed-off-by:
-
Chris Wilson authored
With async binding, we don't want to manage a bound/unbound list as we may end up running before we even acquire the pages. All that is required is keeping track of shrinkable objects, so reduce it to the minimum list. Fixes: 6951e589 ("drm/i915: Move GEM object domain management from struct_mutex to local") Signed-off-by:
-
Ville Syrjälä authored
All AML parts are either KBL ULX or CFL ULX so there is no point in keeping INTEL_SUBPLATFORM_AML around. As these are the only CFL ULX parts (normal CFL didn't have Y SKUs) so we'll just replace IS_AML_ULX with IS_CFL_ULX (it was already paired with IS_KBL_ULX which accounts for the other half of the AML parts). Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Add a comma after the final entry to make diffs less obnoxious if we have to add further entries past the last one. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Ville Syrjälä authored
On non-ULT HSW the "special" WRPLL reference clock select actually means non-SSC. Take that into account when reading out the WRPLL state. Also the non-SSC reference may be either 24MHz or 135MHz, which we can read out from FUSE_STRAP3. The BDW docs actually say: "also indicates whether the CPU and PCH are in a single package or separate packages", so it may be that this is not actually required and we could just assume 135 MHz (just like the code already did). But it doesn't really hurt to read this out as the HSW docs aren't quite so clear. Signed-off-by:
-
Ville Syrjälä authored
Only the non-SSC reference is truly supported for the LCPLL. Assert that it is indeed selected. Signed-off-by:
-
Ville Syrjälä authored
Get rid of the pointless LC_FREQ define. Signed-off-by:
-
Ville Syrjälä authored
Give the PLL control register bits better names on HSW/BDW. v2: Fix the copy paste fails in SPLL_REF defines (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
