- 02 Dec, 2019 21 commits
-
-
José Roberto de Souza authored
MST topology needs to be suspended so we don't have any calls to fbdev after it's finalized. MST will be destroyed later as part of drm_mode_config_cleanup(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127021609.162700-1-jose.souza@intel.com
-
José Roberto de Souza authored
From VBT 228+ this is block that PSR and other power saving features configuration should be read from. v3: Using DRRS from this new block v4: Using BIT() Fixing DRRS comment in parse_power_conservation_features() Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
José Roberto de Souza authored
eDP specification states that sink can have its PSR capability changed, I have never found any panel doing that but lets add that for completeness. For now it is not reading back the PSR capabilities and if possible re-enabling PSR, this will be added if a panel is found using this feature. v4: Cleaning DP_PSR_CAPS_CHANGE Reviewed-by:
-
José Roberto de Souza authored
When this error happens sink link is not stable after the required FW_EXIT_LATENCY period so it will miss the selective update. As the other PSR errors, for now we are not trying to recover from it. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
José Roberto de Souza authored
eDP spec states that when sink enconters a problem that prevents it to keep PSR running it should set PSR status to internal error and set the reason why it happen to PSR_ERROR_STATUS but it is not how it was implemented. But also I don't want to change this behavior, who knows if there is a panel out there that only set the PSR_ERROR_STATUS. So here refactoring the code a bit to make more easy to read what was state above as more checks will be added to this function. v2: returning a int instead of a bool in psr_get_status_and_error_status() Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
José Roberto de Souza authored
PSR2 HW only support a limited number of bits per pixel, if mode has more than supported PSR2 should not be enabled. BSpec: 50422 BSpec: 7713 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Lucas De Marchi authored
The "err" label is not really "err", but rather "out" since the return path is shared between error condition and normal path. This broke when commit 03cea610 ("drm/i915/dsb: fix extra warning on error path handling") added a "dsb->cmd_buf = NULL;" there, making DSB to stop working since now all writes would pass-through via mmio. Remove the set to NULL since it's actually not needed: we only set it if all steps are successful. While at it, rename the label so this confusion doesn't happen again. Fixes: 03cea610 ("drm/i915/dsb: fix extra warning on error path handling") Resolves: https://gitlab.freedesktop.org/drm/intel/issues/8Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127221119.384754-1-lucas.demarchi@intel.com
-
Ville Syrjälä authored
Migrate away from the legacy encoder->crtc and connector->encoder links in the debugfs display_info code. Other users still remain so can't kill these off yet. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-10-ville.syrjala@linux.intel.comReviewed-by:
Ramalingam C <ramalingam.c@intel.com>
-
Ville Syrjälä authored
Let's make the display info more useful by dumping both the uapi and hw states for each crtc/plane. Signed-off-by:
-
Ville Syrjälä authored
Use the canonical "[CRTC:%d:%s]" format for the obj id/name in the debugfs display_info dump. Everyone should already be familiar with the format since it's used in the debug logs extensively. Signed-off-by:
-
Ville Syrjälä authored
Make out life easier by just grabbing all modeset locks around the display_info dump. Signed-off-by:
-
Ville Syrjälä authored
No point in repeating the crtc mode for each cloned encoder. Just print it once, and avoid using multiple lines for it. And while at let's polish the fixed mode print to fit on one line as well. Signed-off-by:
-
Ville Syrjälä authored
Pull the crtc dumping stuff into a nice function so the loop over the crtcs doesn't look like crap. Signed-off-by:
-
Ville Syrjälä authored
Eliminate the special cases for the primary and cursor planes and just dump all the information consistently for all the planes. Signed-off-by:
-
Ville Syrjälä authored
Switch to using intel_ types in the debugfs display_info code. Should make it easier to handle bigjoiner etc. in the future. Signed-off-by:
-
Ville Syrjälä authored
Use DRM_RECT_FMT & co. to simpify the code. Signed-off-by:
-
Ville Syrjälä authored
It's hard to see what is going on when the function mixes drm_ and intel_ types. Switch to intel_ types. v2: Deal with another use of 'intel_crtc' being introduced Signed-off-by:
-
Matt Roper authored
The bspec tells us 'Program SHPD_FILTER_CNT with the "500 microseconds adjusted" value before enabling hotplug detection' on CNP+. We haven't been touching this register at all thus far, but we should probably follow the bspec's guidance. The register also exists on LPT and SPT, but there isn't any specific guidance I can find on how we should be programming it there so let's leave it be for now. Bspec: 4342 Bspec: 31297 Bspec: 8407 Bspec: 49305 Bspec: 50473 Signed-off-by:
-
Matt Roper authored
When looking at SDEISR to determine the connection status of combo outputs, we should use the phy index rather than the port index. Although they're usually the same thing, EHL's DDI-D (port D) is attached to PHY-A and SDEISR doesn't even have bits for a "D" output. It's also possible that future platforms may map DDIs (the internal display engine programming units) to PHYs (the output handling on the IO side) in ways where port!=phy, so let's look at the PHY index by default. v2: Rename to intel_combo_phy_connected. (Lucas) Fixes: 719d2400 ("drm/i915/ehl: Enable DDI-D") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
The South Display is part of the PCH so we should technically be basing our port detection logic off the PCH in use rather than the platform generation. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Ville Syrjälä authored
LPT/WPT only have PCH transcoder A. Make sure we poke at its chicken register instead of some non-existent register when FDI is being driven by pipe B or C. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
- 01 Dec, 2019 1 commit
-
-
Chris Wilson authored
As the gen6 page directory is written on binding and after every update, the code ended up duplicated. Refactor the code into a single routine to share the locking and serialisation. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191201140916.2128905-1-chris@chris-wilson.co.uk
-
- 30 Nov, 2019 4 commits
-
-
Chris Wilson authored
Now that many threads may try to use the same mmio to flush the global buffers after updating the PTE, serialise access to the mmio to prevent concurrent access on gen7. Signed-off-by:
-
Chris Wilson authored
Move our "wait for the PD load to complete" paranoia before the MI_SET_CONTEXT just in case the context restore tries to access local addresses. Signed-off-by:
-
Chris Wilson authored
After much hair pulling, resort to preallocating the ppGTT entries on init to circumvent the apparent lack of PD invalidate following the write to PP_DCLV upon switching mm between contexts (and here the same context after binding new objects). However, the details of that PP_DCLV invalidate are still unknown, and it appears we need to reload the mm twice to cover over a timing issue. Worrying. Fixes: 3dc007fe ("drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgtt") Signed-off-by:
-
Chris Wilson authored
Keep the engine awake and so avoid frequent cycling in and out of powersaving mode to eliminate the unnecessary overhead and speed up the testing. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191129222702.1456292-1-chris@chris-wilson.co.uk
-
- 29 Nov, 2019 8 commits
-
-
Chris Wilson authored
As we only cancel the timers asynchronously, they may still be running on another CPU as we shutdown, raising one last softirq. So be safe and make sure the tasklet is flushed before destroying the engine's memory. Signed-off-by:
-
Chris Wilson authored
Though the context is closed and so no more requests can be added to the timeline, retirement can still be removing requests. It can even be removing the very request we are inspecting and so cause us to wander into dead links. Serialise with the retirement by taking the timeline->mutex used for guarding the timeline->requests list. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112404 Fixes: 4a317415 ("drm/i915/gem: Refine occupancy test in kill_context()") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191129151845.1092933-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
skl_commit_modeset_enables() straight up compares dirty_pipes with a bitmask of already committed pipes. If we set bits in dirty_pipes for non-existent pipes that comparison will never work right. So let's limit ourselves to bits that exist. And we'll do the same for the active_pipes_changed bitmask. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Chris Wilson authored
Since commit c45e788d ("drm/i915/tgl: Suspend pre-parser across GTT invalidations"), we now disable the advanced preparser on Tigerlake for the invalidation phase at the start of the batch, we no longer need to emit the GPU relocations from a second context as they are now flushed inlined. References: 8a9a9827 ("drm/i915: use a separate context for gpu relocs") References: c45e788d ("drm/i915/tgl: Suspend pre-parser across GTT invalidations") Signed-off-by:
-
Chris Wilson authored
Wait on only the last request on the kernel_context after emitting a barrier so that we do not wait for everything in general and by doing so cause an accidental emission of the barrier! Bugzilla; https://bugs.freedesktop.org/show_bug.cgi?id=112405Signed-off-by:
-
Chris Wilson authored
Be paranoid and make sure the drm_mm is locked whenever we insert/remove our own nodes. Signed-off-by:
-
Chris Wilson authored
Use the normal sgt_iter to walk the pages scatterlist on free so that we handle the error path correctly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112225Signed-off-by:
-
Michel Thierry authored
Implement Wa_1604555607 (set the DS pairing timer to 128 cycles). FF_MODE2 is part of the register state context, that's why it is implemented here. At TGL A0 stepping, FF_MODE2 register read back is broken, hence disabling the WA verification. v2: Rebased on top of the WA refactoring (Oscar) v3: Correctly add to ctx_workarounds_init (Michel) v4: uncore read is used [Tvrtko] Macros as used for MASK definition [Chris] v5: Skip the Wa_1604555607 verification [Ram] i915 ptr retrieved from engine. [Tvrtko] v6: Added wa_add as a wrapper for __wa_add [Chris] wa_add is directly called instead of new wrapper [tvrtko] BSpec: 19363 HSDES: 1604555607 Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Ramalingam C <ramlingam.c@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [v5] Reviewed-by:
-
- 28 Nov, 2019 4 commits
-
-
Chris Wilson authored
After obtaining a local reference to the vm from the context, remember to drop it before it goes out of scope! Signed-off-by:
-
Chris Wilson authored
Don't rely on the RUNTIME_INFO() when we loop over a particular context and only run on a filtered set of engines. Signed-off-by:
-
Chris Wilson authored
We have a case of a mysteriously absent pulse, so dump the engine details to see if we can find out what happened to it. References: https://bugs.freedesktop.org/show_bug.cgi?id=112405Signed-off-by:
-
Chris Wilson authored
One does not lightly add a new hidden struct_mutex dependency deep within the execbuf bowels! The immediate suspicion in seeing the whitelist cached on the context, is that it is intended to be preserved between batches, as the kernel is quite adept at caching small allocations itself. But no, it's sole purpose is to serialise command submission in order to save a kmalloc on a slow, slow path! By removing the whitelist dependency from the context, our freedom to chop the big struct_mutex is greatly augmented. v2: s/set_bit/__set_bit/ as the whitelist shall never be accessed concurrently. Signed-off-by:
-
- 27 Nov, 2019 2 commits
-
-
Chris Wilson authored
The design of our interrupt handlers is that we ack the receipt of the interrupt first, inside the critical section where the master interrupt control is off and other cpus cannot start processing the next interrupt; and then process the interrupt events afterwards. However, Icelake introduced a whole new set of banked GT_IIR that are inherently serialised and slow to retrieve the IIR and must be processed within the critical section. We can still push our breadcrumbs out of this critical section by using our irq_worker. On bdw+, this should not make too much of a difference as we only slightly defer the breadcrumbs, but on icl+ this should make a big difference to our throughput of interrupts from concurrently executing engines. Signed-off-by:
-
Chris Wilson authored
The expected downside to commit 58b4c1a0 ("drm/i915: Reduce nested prepare_remote_context() to a trylock") was that it would need to return -EAGAIN to userspace in order to resolve potential mutex inversion. Such an unsightly round trip is unnecessary if we could atomically insert a barrier into the i915_active_fence, so make it happen. Currently, we use the timeline->mutex (or some other named outer lock) to order insertion into the i915_active_fence (and so individual nodes of i915_active). Inside __i915_active_fence_set, we only need then serialise with the interrupt handler in order to claim the timeline for ourselves. However, if we remove the outer lock, we need to ensure the order is intact between not only multiple threads trying to insert themselves into the timeline, but also with the interrupt handler completing the previous occupant. We use xchg() on insert so that we have an ordered sequence of insertions (and each caller knows the previous fence on which to wait, preserving the chain of all fences in the timeline), but we then have to cmpxchg() in the interrupt handler to avoid overwriting the new occupant. The only nasty side-effect is having to temporarily strip off the RCU-annotations to apply the atomic operations, otherwise the rules are much more conventional! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112402 Fixes: 58b4c1a0 ("drm/i915: Reduce nested prepare_remote_context() to a trylock") Signed-off-by:
-
