- 23 Sep, 2019 24 commits
-
-
Clinton A Taylor authored
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
-
Chris Wilson authored
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
-
Chris Wilson authored
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 authored
Since amalgamating the queued and active lists in commit 422d7df4 ("drm/i915: Replace engine->timeline with a plain list"), performing a i915_request_submit() will remove the request from the execlists priority queue. References: 422d7df4 ("drm/i915: Replace engine->timeline with a plain list") Signed-off-by:
-
Chris Wilson authored
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: dffa8feb ("drm/i915/perf: Assert locking for i915_init_oa_perf_state()") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
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:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920185421.17822-6-jani.nikula@intel.com
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
Jani Nikula authored
For completeness, add counterpart to i915_driver_modeset_probe() and remove the asymmetry in the probe/remove parts. No functional changes. Reviewed-by:
-
Kai Vehmanen authored
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:
-
Animesh Manna authored
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:
-
Animesh Manna authored
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:
-
Animesh Manna authored
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 authored
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:
-
Animesh Manna authored
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:
-
Animesh Manna authored
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:
-
Animesh Manna authored
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:
-
Jani Nikula authored
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:
-
Animesh Manna authored
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 authored
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:
-
Swati Sharma authored
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:
-
Swati Sharma authored
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:
-
- 21 Sep, 2019 1 commit
-
-
Daniele Ceraolo Spurio authored
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:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
- 20 Sep, 2019 15 commits
-
-
Ville Syrjälä authored
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.comReviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
-
Ville Syrjälä authored
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ä authored
Add comments to explain the ilk pipe csc operation a bit better. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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:
-
Anusha Srivatsa authored
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:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Chris Wilson authored
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: 7f0cc34b ("drm/i915/tgl: Implement Wa_1406941453") Testcase: igt/i915_selftest/live_workarounds Signed-off-by:
-
Chris Wilson authored
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 authored
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 authored
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:
-
