summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-09-23drm/i915: Prevent bonded requests from overtaking each other on preemptionChris Wilson
Force bonded requests to run on distinct engines so that they cannot be shuffled onto the same engine where timeslicing will reverse the order. A bonded request will often wait on a semaphore signaled by its master, creating an implicit dependency -- if we ignore that implicit dependency and allow the bonded request to run on the same engine and before its master, we will cause a GPU hang. [Whether it will hang the GPU is debatable, we should keep on timeslicing and each timeslice should be "accidentally" counted as forward progress, in which case it should run but at one-half to one-third speed.] We can prevent this inversion by restricting which engines we allow ourselves to jump to upon preemption, i.e. baking in the arrangement established at first execution. (We should also consider capturing the implicit dependency using i915_sched_add_dependency(), but first we need to think about the constraints that requires on the execution/retirement ordering.) Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing") References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding") Testcase: igt/gem_exec_balancer/bonded-slice Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923152844.8914-3-chris@chris-wilson.co.uk
2019-09-23drm/i915: Fixup preempt-to-busy vs reset of a virtual requestChris Wilson
Due to the nature of preempt-to-busy the execlists active tracking and the schedule queue may become temporarily desync'ed (between resubmission to HW and its ack from HW). This means that we may have unwound a request and passed it back to the virtual engine, but it is still inflight on the HW and may even result in a GPU hang. If we detect that GPU hang and try to reset, the hanging request->engine will no longer match the current engine, which means that the request is not on the execlists active list and we should not try to find an older incomplete request. Given that we have deduced this must be a request on a virtual engine, it is the single active request in the context and so must be guilty (as the context is still inflight, it is prevented from being executed on another engine as we process the reset). Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923152844.8914-2-chris@chris-wilson.co.uk
2019-09-23drm/i915: Fixup preempt-to-busy vs resubmission of a virtual requestChris Wilson
As preempt-to-busy leaves the request on the HW as the resubmission is processed, that request may complete in the background and even cause a second virtual request to enter queue. This second virtual request breaks our "single request in the virtual pipeline" assumptions. Furthermore, as the virtual request may be completed and retired, we lose the reference the virtual engine assumes is held. Normally, just removing the request from the scheduler queue removes it from the engine, but the virtual engine keeps track of its singleton request via its ve->request. This pointer needs protecting with a reference. v2: Drop unnecessary motion of rq->engine = owner Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923152844.8914-1-chris@chris-wilson.co.uk
2019-09-23drm/i915/tgl: Check the UC health of tc controllers after power onJosé Roberto de Souza
New step added for TGL, required for us to check the TC microcontroller health after power on TC aux. BSpec: 49294 Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920205810.211048-7-jose.souza@intel.com
2019-09-23drm/i915/icl: Unify disable and enable phy clock gating functionsJosé Roberto de Souza
Adding a enable parameters allow us to share most of the code between enable and disable functions. v3: Renamed icl_phy_clock_gating() to icl_phy_set_clock_gating() Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920205810.211048-6-jose.souza@intel.com
2019-09-23drm/i915/tgl: Add dkl phy registersVandita Kulkarni
These are the registers needed to program Dekel phy. Some register definitions will be reused from MG PHY definitions, so adding a comment on those. Bspec: 49295 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Clinton A Taylor <clinton.a.taylor@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920205810.211048-5-jose.souza@intel.com
2019-09-23drm/i915/tgl/pll: Set update_active_dpllClinton A Taylor
Commit 24a7bfe0c2d7 ("drm/i915: Keep the TypeC port mode fixed when the port is active") added this new hook while in parallel TGL upstream was happening and this was missed. Without this driver will crash when TC DDI is added and driver is preparing to do a full modeset. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Clinton A Taylor <clinton.a.taylor@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920205810.211048-4-jose.souza@intel.com
2019-09-23drm/i915/tgl: Finish modular FIA support on registersJosé Roberto de Souza
If platform supports and has modular FIA is enabled, the registers bits also change, example: reading TC3 registers with modular FIA enabled, driver should read from FIA2 but with TC1 bits offsets. It is described in BSpec 50231 for DFLEXDPSP, other registers don't have the BSpec description but testing in real hardware have proven that it had moved for all other registers too. v2: - Caching index in tc_phy_fia_idx, instead of calculate it each time v3: - Setting tc_phy_fia and tc_phy_fia_idx in the same function Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920205810.211048-3-jose.souza@intel.com
2019-09-23drm/i915/tgl: Add missing ddi clock select during DP init sequenceClinton A Taylor
Step 4.b was complete missed because it is only required to TC and TBT. Bspec: 49190 Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Clinton A Taylor <clinton.a.taylor@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920205810.211048-2-jose.souza@intel.com
2019-09-23drm/i915/execlists: Refactor -EIO markup of hung requestsChris Wilson
Pull setting -EIO on the hung requests into its own utility function. Having allowed ourselves to short-circuit submission of completed requests, we can now do the mark_eio() prior to submission and avoid some redundant operations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-4-chris@chris-wilson.co.uk
2019-09-23drm/i915: Only enqueue already completed requestsChris Wilson
If we are asked to submit a completed request, just move it onto the active-list without modifying it's payload. If we try to emit the modified payload of a completed request, we risk racing with the ring->head update during retirement which may advance the head past our breadcrumb and so we generate a warning for the emission being behind the RING_HEAD. v2: Commentary for the sneaky, shared responsibility between functions. v3: Spelling mistakes and bonus assertion Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-3-chris@chris-wilson.co.uk
2019-09-23drm/i915/execlists: Drop redundant list_del_init(&rq->sched.link)Chris Wilson
Since amalgamating the queued and active lists in commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a plain list"), performing a i915_request_submit() will remove the request from the execlists priority queue. References: 422d7df4f090 ("drm/i915: Replace engine->timeline with a plain list") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-2-chris@chris-wilson.co.uk
2019-09-23drm/i915/execlists: Relax assertion for a pinned context image on resetChris Wilson
A gpu hang can occur at any time, given a sufficiently angry gpu. An example is when it forgets to perform a context-switch at the end of a request, leaving us with a hanging GPU on a completed request. Here, we may retire the request, only leaving its context alive via the active barrier. When we reset the GPU on a completed request, we do not modify its context image (just updating the ring state) and can safely defer the assertion that we have the image pinned and ready to modify. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111639 Fixes: dffa8feb3084 ("drm/i915/perf: Assert locking for i915_init_oa_perf_state()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-1-chris@chris-wilson.co.uk
2019-09-23drm/i915: pass i915 to intel_modeset_init() and intel_modeset_init_hw()Jani Nikula
In general, prefer struct drm_i915_private * over struct drm_device * when either will do. Rename the local variables to i915. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920185421.17822-6-jani.nikula@intel.com
2019-09-23drm/i915: abstract intel_mode_config_init() from intel_modeset_init()Jani Nikula
The i915 specific mode config init code is too specific and detailed to have open in a high level function. Abstract away. No functional changes. v2: nest drm_mode_config_init() in the function too (Chris) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920185421.17822-5-jani.nikula@intel.com
2019-09-23drm/i915: abstract intel_panel_sanitize_ssc() from intel_modeset_init()Jani Nikula
The code is too specific and detailed to have open in a high level function. Abstract away. As a drive-by improvement switch to using enableddisabled() in logging and git rid of a redundant !!. No functional changes. v2: drop the !! while at it too (Chris) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920185421.17822-4-jani.nikula@intel.com
2019-09-23drm/i915: pass i915 to intel_modeset_driver_remove()Jani Nikula
In general, prefer struct drm_i915_private * over struct drm_device * when either will do. Rename the local variable to i915. Also propagate to intel_hpd_poll_fini(). No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920185421.17822-3-jani.nikula@intel.com
2019-09-23drm/i915: pass i915 to i915_driver_modeset_probe()Jani Nikula
In general, prefer struct drm_i915_private * over struct drm_device * when either will do. Rename the local variable to i915. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920185421.17822-2-jani.nikula@intel.com
2019-09-23drm/i915: add i915_driver_modeset_remove()Jani Nikula
For completeness, add counterpart to i915_driver_modeset_probe() and remove the asymmetry in the probe/remove parts. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920185421.17822-1-jani.nikula@intel.com
2019-09-23drm/i915: save AUD_FREQ_CNTRL state at audio domain suspendKai Vehmanen
When audio power domain is suspended, the display driver must save state of AUD_FREQ_CNTRL on Tiger Lake and Ice Lake systems. The initial value of the register is set by BIOS and is read by driver during the audio component init sequence. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920083918.27057-1-kai.vehmanen@linux.intel.com
2019-09-23drm/i915/dsb: Documentation for DSB.Animesh Manna
Added docbook info regarding Display State Buffer(DSB) which is added from gen12 onwards to batch submit display HW programming. v1: Initial version as RFC. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-11-animesh.manna@intel.com
2019-09-23drm/i915/dsb: Enable DSB for gen12.Animesh Manna
Enabling DSB by setting 1 to has_dsb flag for gen12. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-10-animesh.manna@intel.com
2019-09-23drm/i915/dsb: Enable gamma lut programming using DSB.Animesh Manna
Gamma lut programming can be programmed using DSB where bulk register programming can be done using indexed register write which takes number of data and the mmio offset to be written. Currently enabled for 12-bit gamma LUT which is enabled by default and later 8-bit/10-bit will be enabled in future based on need. v1: Initial version. v2: Directly call dsb-api at callsites. (Jani) v3: - modified the code as per single dsb instance per crtc. (Shashank) - Added dsb get/put call in platform specific load_lut hook. (Jani) - removed dsb pointer from dev_priv. (Jani) v4: simplified code by dropping ref-count implementation. (Shashank) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-9-animesh.manna@intel.com
2019-09-23drm/i915/dsb: function to trigger workload execution of DSB.Animesh Manna
Batch buffer will be created through dsb-reg-write function which can have single/multiple request based on usecase and once the buffer is ready commit function will trigger the execution of the batch buffer. All the registers will be updated simultaneously. v1: Initial version. v2: Optimized code few places. (Chris) v3: USed DRM_ERROR for dsb head/tail programming failure. (Shashank) v4: reset ins_start_offset after commit. (Jani) Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-8-animesh.manna@intel.com
2019-09-23drm/i915/dsb: functions to enable/disable DSB engine.Animesh Manna
DSB will be used for performance improvement for some special scenario. DSB engine will be enabled based on need and after completion of its work will be disabled. Api added for enable/disable operation by using DSB_CTRL register. v1: Initial version. v2: POSTING_READ added after writing control register. (Shashank) v3: cosmetic changes done. (Shashank) Cc: Michel Thierry <michel.thierry@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-7-animesh.manna@intel.com
2019-09-23drm/i915/dsb: Check DSB engine status.Animesh Manna
As per bspec check for DSB status before programming any of its register. Inline function added to check the dsb status. Cc: Michel Thierry <michel.thierry@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-6-animesh.manna@intel.com
2019-09-23drm/i915/dsb: Indexed register write function for DSB.Animesh Manna
DSB can program large set of data through indexed register write (opcode 0x9) in one shot. DSB feature can be used for bulk register programming e.g. gamma lut programming, HDR meta data programming. v1: initial version. v2: simplified code by using ALIGN(). (Chris) v3: ascii table added as code comment. (Shashank) v4: cosmetic changes done. (Shashank) v5: reset ins_start_offset. (Jani) v6: update ins_start_offset in inel_dsb_reg_write. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-5-animesh.manna@intel.com
2019-09-23drm/i915/dsb: single register write function for DSB.Jani Nikula
DSB support single register write through opcode 0x1. Generic api created which accumulate all single register write in a batch buffer and once DSB is triggered, it will program all the registers at the same time. v1: Initial version. v2: Unused macro removed and cosmetic changes done. (Shashank) v3: set free_pos to zero in dsb-put() instead dsb-get() and a cosmetic change. (Shashank) v4: macro of indexed-write is moved. (Shashank) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-4-animesh.manna@intel.com
2019-09-23drm/i915/dsb: DSB context creation.Animesh Manna
This patch adds a function, which will internally get the gem buffer for DSB engine. The GEM buffer is from global GTT, and is mapped into CPU domain, contains the data + opcode to be feed to DSB engine. v1: Initial version. v2: - removed some unwanted code. (Chris) - Used i915_gem_object_create_internal instead of _shmem. (Chris) - cmd_buf_tail removed and can be derived through vma object. (Chris) v3: vma realeased if i915_gem_object_pin_map() failed. (Shashank) v4: for simplification and based on current usage added single dsb object in intel_crtc. (Shashank) v5: seting NULL to cmd_buf moved outside of mutex in dsb-put(). (Shashank) v6: - refcount machanism added. - Used atomic_add_return and atomic_dec_and_test instead of atomic_inc and atomic_dec. (Jani) Cc: Imre Deak <imre.deak@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> [Jani: added #include <linux/types.h> while pushing] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-3-animesh.manna@intel.com
2019-09-23drm/i915/dsb: feature flag added for display state buffer.Animesh Manna
Display State Buffer(DSB) is a new hardware capability, introduced in GEN12 display. DSB allows a driver to batch-program display HW registers. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920115930.27829-2-animesh.manna@intel.com
2019-09-23drm/i915/color: Extract icl_read_luts()Swati Sharma
For icl+, have hw read out to create hw blob of gamma lut values. icl+ platforms supports multi segmented gamma mode by default, add hw lut creation for this mode. This will be used to validate gamma programming using dsb (display state buffer) which is a tgl specific feature. Major change done-removal of readouts of coarse and fine segments because PAL_PREC_DATA register isn't giving propoer values. State checker limited only to "fine segment" v2: -readout code for multisegmented gamma has to come up with some intermediate entries that aren't preserved in hardware (Jani N) -linear interpolation (Ville) -moved common code to check gamma_enable to specific funcs, since icl doesn't support that v3: -use u16 instead of __u16 [Jani N] -used single lut [Jani N] -improved and more readable for loops [Jani N] -read values directly to actual locations and then fill gaps [Jani N] -moved cleaning to patch 1 [Jani N] -renamed icl_read_lut_multi_seg() to icl_read_lut_multi_segment to make it similar to icl_load_luts() -renamed icl_compute_interpolated_gamma_blob() to icl_compute_interpolated_gamma_lut_values() more sensible, I guess v4: -removed interpolated func for creating gamma lut values -removed readouts of fine and coarse segments, failure to read PAL_PREC_DATA correctly Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1569096654-24433-3-git-send-email-swati2.sharma@intel.com
2019-09-23drm/i915/color: Fix formatting issuesSwati Sharma
Fixed few formatting issues in multi-segmented load_lut(). v3: -style nitting [Jani] -balanced parentheses moved from patch 2 to 1 [Jani] -subject prefix change [Jani] -added commit message [Jani] v4: -rearranged INDEX register write in ilk_read_luts() Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1569096654-24433-2-git-send-email-swati2.sharma@intel.com
2019-09-21drm/i915/tgl: s/ss/eu fuse reading supportDaniele Ceraolo Spurio
Gen12 has dual-subslices (DSS), which compared to gen11 subslices have some duplicated resources/paths. Although DSS behave similarly to 2 subslices, instead of splitting this and presenting userspace with bits not directly representative of hardware resources, present userspace with a subslice_mask made up of DSS bits instead. v2: GEM_BUG_ON on mask size (Lionel) Bspec: 29547 Bspec: 12247 Cc: Kelvin Gardiner <kelvin.gardiner@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> CC: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> #v1 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913075137.18476-2-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2019-09-20drm/i915: Add PIPECONF YCbCr 4:4:4 programming for ILK-IVBVille Syrjälä
On ILK-IVB the pipe colorspace is configured via PIPECONF (as opposed to PIPEMISC in BDW+). Let's configure+readout that stuff correctly. Enabling YCbCr 4:4:4 output will now be a simple matter of setting crtc_state->output_format appropriately in the encoder .compute_config(). However, when we do that we must be aware of the fact that YCbCr DP output doesn't seem to work on ILK (resulting image is totally garbled), but on SNB+ it works fine. However HDMI YCbCr output does work correctly even on ILK. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-13-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915: Set up ILK/SNB csc unit properly for YCbCr outputVille Syrjälä
Prepare the pipe csc for YCbCr output on ilk/snb. The main difference to IVB+ is the lack of explicit post offsets, and instead we must configure the CSC info RGB->YUV mode (which takes care of offsetting Cb/Cr properly) and enable the "black screen offset" bit to add the required offset to Y. And while at it throw some comments around the bit defines to document which platforms have which bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-12-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915: Document ILK+ pipe csc matrix betterVille Syrjälä
Add comments to explain the ilk pipe csc operation a bit better. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-11-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915: Add PIPECONF YCbCr 4:4:4 programming for HSWVille Syrjälä
On HSW the pipe colorspace is configured via PIPECONF (as opposed to PIPEMISC in BDW+). Let's configure+readout that stuff correctly. Enabling YCbCr 4:4:4 output will now be a simple matter of setting crtc_state->output_format appropriately in the encoder .compute_config(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-10-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915: Simplify intel_get_crtc_ycbcr_config()Ville Syrjälä
Make intel_get_crtc_ycbcr_config() simpler and rename it to bdw_get_pipemisc_output_format() to better reflect what it does. Also toss in some comments to document that the 4:2:0 PIPECONF bits are glk+ only. They are mbz on earlier platforms so reading them unconditionally is safe however. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-9-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915: Don't look at unrelated PIPECONF bits for interlaced readoutVille Syrjälä
Since HSW the PIPECONF progressive vs. interlaced selection is done with just two bits instead of the earlier three. Let's not look at the extra bit on HSW+. Also gen2 doesn't support interlaced displays at all. This is actually fine as is currently because the extra bit is mbz (as are all three bits on gen2). But just to avoid mishaps in the future if the bits get reused let's only look at what's properly defined. v2: constify crtc_state Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-8-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915: Never set limited_color_range=true for YCbCr outputVille Syrjälä
crtc_state->limited_color_range only applies to RGB output but we're currently setting it even for YCbCr output. That will lead to conflicting MSA and PIPECONF settings which can mess up the image. Let's make sure limited_color_range stays unset with YCbCr output. Also WARN if we end up with such a bogus combination when programming the MSA MISC bits as it's impossible to even indicate quantization rangle for YCbCr via MSA MISC. YCbCr output is simply assumed to be limited range always. Note that VSC SDP does provide a mechanism for full range YCbCr, so in the future we may want to rethink how we compute/store this state. And for good measure we add the same WARN to the HDMI path. v2: s/==/!=/ in the HDMI WARN Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718164523.11738-1-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915: Extract intel_hdmi_limited_color_range()Ville Syrjälä
Pull the code for computing the limited color range setting into a small helper. We'll add a bit more to it later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-5-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915: Fix AVI infoframe quantization range for YCbCr outputVille Syrjälä
We're configuring the AVI infoframe quantization range bits as if we're always transmitting RGB pixels. Let's fix this so that we correctly indicate limited range YCC quantization range when transmitting YCbCr instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-4-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915: Fix HSW+ DP MSA YCbCr colorspace indicationVille Syrjälä
Looks like we're currently setting the MSA to xvYCC BT.709 instead of the YCbCr BT.601 claimed by the comment. But even that comment is wrong since we configure the CSC matrix to BT.709. Let's remove the bogus statement from the comment and fix the MSA to indicate YCbCr BT.709 so that it matches the actual pixel data we're transmitting. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-3-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-20drm/i915/uc: Update HuC firmware naming convention and load latest HuCAnusha Srivatsa
Make both GuC and HuC to use "." as the separator. Hardcode the separator in MAKE_UC_FW_PATH. Remove the usage of "ver" from HuC. The current convention being: <platform>_<g/h>uc_<major>.<minor>.patch.bin Update the versions of HuC being loaded of the platforms. SKL - v2.0.0 BXT - v2.0.0 KBL - v4.0.0 GLK - v4.0.0 CFL - KBL v4.0.0 ICL - v9.0.0 CML - v4.0.0 v2: Remove the separator parameter altogether from __MAKE_UC_FW_PATH.(Daniele) - Squash all firmware update patches (Daniele) v3: s/huc/HuC - Correct the order of platforms - Change REVID of cml to 5(Michal) - Code space changes in huc_def (Daniele) Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919201204.9691-1-daniele.ceraolospurio@intel.com
2019-09-20Revert "drm/i915/tgl: Implement Wa_1406941453"Chris Wilson
Our sanitychecks indicate that while this register is context saved/restore, the HW does not preserve this bit within the register -- it likely doesn't exist, or one of those mythical bits that the architects insist does something despite all appearances to the contrary. For reference, SAMPLER_MODE is already in i915_reg.h as GEN10_SAMPLER_MODE and is being setup in icl_ctx_workarounds_init() as opposed to the chosen location here of rcs_engine_wa_init). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111754 Fixes: 7f0cc34b5349 ("drm/i915/tgl: Implement Wa_1406941453") Testcase: igt/i915_selftest/live_workarounds Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920081254.18389-1-chris@chris-wilson.co.uk
2019-09-20drm/i915: Protect timeline->hwsp dereferencingChris Wilson
As not only is the signal->timeline volatile, so will be acquiring the timeline's HWSP. We must first carefully acquire the timeline from the signaling request and then lock the timeline. With the removal of the struct_mutex serialisation of request construction, we can have multiple timelines active at once, and so we must avoid using the nested mutex lock as it is quite possible for both timelines to be establishing semaphores on the other and so deadlock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-3-chris@chris-wilson.co.uk
2019-09-20drm/i915: Lock signaler timeline while navigatingChris Wilson
As we need to take a walk back along the signaler timeline to find the fence before upon which we want to wait, we need to lock that timeline to prevent it being modified as we walk. Similarly, we also need to acquire a reference to the earlier fence while it still exists! Though we lack the correct locking today, we are saved by the overarching struct_mutex -- but that protection is being removed. v2: Tvrtko made me realise I was being lax and using annotations to ignore the AB-BA deadlock from the timeline overlap. As it would be possible to construct a second request that was using a semaphore from the same timeline as ourselves, we could quite easily end up in a situation where we deadlocked in our mutex waits. Avoid that by using a trylock and falling back to a normal dma-fence await if contended. v3: Eek, the signal->timeline is volatile and must be carefully dereferenced to ensure it is valid. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-2-chris@chris-wilson.co.uk
2019-09-20drm/i915: Mark i915_request.timeline as a volatile, rcu pointerChris Wilson
The request->timeline is only valid until the request is retired (i.e. before it is completed). Upon retiring the request, the context may be unpinned and freed, and along with it the timeline may be freed. We therefore need to be very careful when chasing rq->timeline that the pointer does not disappear beneath us. The vast majority of users are in a protected context, either during request construction or retirement, where the timeline->mutex is held and the timeline cannot disappear. It is those few off the beaten path (where we access a second timeline) that need extra scrutiny -- to be added in the next patch after first adding the warnings about dangerous access. One complication, where we cannot use the timeline->mutex itself, is during request submission onto hardware (under spinlocks). Here, we want to check on the timeline to finalize the breadcrumb, and so we need to impose a second rule to ensure that the request->timeline is indeed valid. As we are submitting the request, it's context and timeline must be pinned, as it will be used by the hardware. Since it is pinned, we know the request->timeline must still be valid, and we cannot submit the idle barrier until after we release the engine->active.lock, ergo while submitting and holding that spinlock, a second thread cannot release the timeline. v2: Don't be lazy inside selftests; hold the timeline->mutex for as long as we need it, and tidy up acquiring the timeline with a bit of refactoring (i915_active_add_request) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-20drm/i915/tgl: Suspend pre-parser across GTT invalidationsChris Wilson
Before we execute a batch, we must first issue any and all TLB invalidations so that batch picks up the new page table entries. Tigerlake's preparser is weakening our post-sync CS_STALL inside the invalidate pipe-control and allowing the loading of the batch buffer before we have setup its page table (and so it loads the wrong page and executes indefinitely). The igt_cs_tlb indicates that this issue can only be observed on rcs, even though the preparser is common to all engines. Alternatively, we could do TLB shootdown via mmio on updating the GTT. By inserting the pre-parser disable inside EMIT_INVALIDATE, we will also accidentally fixup execution that writes into subsequent batches, such as gem_exec_whisper and even relocations performed on the GPU. We should be careful not to allow this disable to become baked into the uABI! The issue is that if userspace relies on our disabling of the HW optimisation, when we are ready to enable that optimisation, userspace will then be broken... Testcase: igt/i915_selftests/live_gtt/igt_cs_tlb Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111753 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919151811.9526-1-chris@chris-wilson.co.uk
2019-09-19drm/i915: Don't advertise modes that exceed the max plane sizeVille Syrjälä
Modern platforms allow the transcoders hdisplay/vdisplay to exceed the planes' max resolution. This has the nasty implication that modes on the connectors' mode list may not be usable when the user asks for a fullscreen plane. Seeing as that is the most common use case it seems prudent to filter out modes that don't allow for fullscreen planes to be enabled. Let's do that in the connetor .mode_valid() hook so that normally such modes are kept hidden but the user is still able to forcibly specify such a mode if they know they don't need fullscreen planes. This is in line with ealier policies regarding certain clock limits. The idea is to prevent the casual user from encountering a mode that would fail under typical conditions, but allow the expert user to force things if they so wish. Maybe in the future we should consider automagically using two planes when one can't cover the entire screen? Wouldn't be a great match for the current uapi with explicit planes though, but I guess no worse than using two pipes (which we apparently have to in the future anyway). Either that or we'd have to teach userspace to do it for us. v2: Fix icl+ max plane heigth (Manasi) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Leho Kraav <leho@kraav.com> Cc: Sean Paul <sean@poorly.run> Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190918150707.32420-1-ville.syrjala@linux.intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 07:16:21 +0000