- 24 Sep, 2019 2 commits
-
-
Stanislav Lisovskiy authored
Added bandwidth calculation algorithm and checks, similar way as it was done for ICL, some constants were corrected according to BSpec 53998. v2: Start using same icl_get_bw_info function to avoid code duplication. Moved mpagesize to memory info related structure as it is now dependent on memory type. Fixed qi.t_bl field assignment. v3: Removed mpagesize as unused. Duplicate code and redundant blankline fixed. v4: Changed ordering of IS_GEN checks as agreed. Minor commit message fixes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111600Reviewed-by:James Ausmus <james.ausmus@intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920083754.5920-1-stanislav.lisovskiy@intel.com
-
Chris Wilson authored
Since dropping the set-to-gtt-domain in commit a679f58d ("drm/i915: Flush pages on acquisition"), we no longer mark the contents as dirty on a write fault. This has the issue of us then not marking the pages as dirty on releasing the buffer, which means the contents are not written out to the swap device (should we ever pick that buffer as a victim). Notably, this is visible in the dumb buffer interface used for cursors. Having updated the cursor contents via mmap, and swapped away, if the shrinker should evict the old cursor, upon next reuse, the cursor would be invisible. E.g. echo 80 > /proc/sys/kernel/sysrq ; echo f > /proc/sysrq-trigger Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111541 Fixes: a679f58d ("drm/i915: Flush pages on acquisition") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.2+ Reviewed-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920121821.7223-1-chris@chris-wilson.co.uk
-
- 23 Sep, 2019 32 commits
-
-
Chris Wilson authored
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: 8ee36e04 ("drm/i915/execlists: Minimalistic timeslicing") References: ee113690 ("drm/i915/execlists: Virtual engine bonding") Testcase: igt/gem_exec_balancer/bonded-slice Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923152844.8914-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
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: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by:
-
Chris Wilson authored
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: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by:
-
José Roberto de Souza authored
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
-
José Roberto de Souza authored
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:
-
Vandita Kulkarni authored
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:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Clinton A Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
Clinton A Taylor authored
Commit 24a7bfe0 ("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:
-
José Roberto de Souza authored
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:
-
Clinton A Taylor authored
Step 4.b was complete missed because it is only required to TC and TBT. Bspec: 49190 Reviewed-by:
-
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 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:
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 5 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:
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:
-
