drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.
This fixes the following KASAN splash on module reload:
[ 145.136327] ==================================================================
[ 145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915]
[ 145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134
Lucas De Marchi [Mon, 13 Jul 2020 18:23:21 +0000 (11:23 -0700)]
drm/i915/dg1: Add fake PCH
DG1 has the south engine display on the same PCI device. Ideally we
could use HAS_PCH_SPLIT(), but that macro is misused all across the
code base to rather signify a range of gens. So add a fake one for DG1
to be used where needed.
Add the PCI ID for DG1, but keep it out of the table we use to register
the driver. At this point we can't consider the driver ready to bind to
the device since we basically miss support for everything. When more
support is merged we can enable it to work partially for example as a
display-only driver.
v2: remove DG1 from the pci table and reword commit message (Lucas)
Bspec: 44463
Cc: Matthew Auld <matthew.auld@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> # v1 Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200713182321.12390-3-lucas.demarchi@intel.com
v2: s/intel_dg1_info/dg1_info/ as done for other platforms before and
try to shut up compiler about ununsed variable that we know
shouldn't be used (Lucas)
v3: replace explicit attribute with __maybe_unused (Lucas)
Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Vanshidhar Konda <vanshidhar.r.konda@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713182321.12390-2-lucas.demarchi@intel.com
Ville Syrjälä [Thu, 9 Jul 2020 14:58:45 +0000 (17:58 +0300)]
drm/i915: WARN if max vswing/pre-emphasis violates the DP spec
According to the DP spec a DPTX must support vswing/pre-emphasis
up to and including level 2. Level 3 is optional (actually DP 1.4a
seems to make even level 3 mandatory for HBR2/3, while leaving it
optional for RBR/HBR1).
WARN if out encoders' .voltage_max()/.preemph_max() return
an illegal value.
Lee Shawn C [Mon, 13 Jul 2020 17:07:46 +0000 (13:07 -0400)]
drm/i915/mst: filter out the display mode exceed sink's capability
So far, max dot clock rate for MST mode rely on physcial
bandwidth limitation. It would caused compatibility issue
if source display resolution exceed MST hub output ability.
For example, source DUT had DP 1.2 output capability.
And MST docking just support HDMI 1.4 spec. When a HDMI 2.0
monitor connected. Source would retrieve EDID from external
and get max resolution 4k@60fps. DP 1.2 can support 4K@60fps
because it did not surpass DP physical bandwidth limitation.
Do modeset to 4k@60fps, source output display data but MST
docking can't output HDMI properly due to this resolution
already over HDMI 1.4 spec.
Refer to commit <fcf463807596> ("drm/dp_mst: Use full_pbn
instead of available_pbn for bandwidth checks").
Source driver should refer to full_pbn to evaluate sink
output capability. And filter out the resolution surpass
sink output limitation.
Changes since v1:
* Using mgr->base.lock to protect full_pbn.
Changes since v2:
* Add ctx lock.
Changes since v3:
* s/intel_dp_mst_mode_clock_exceed_pbn_bandwidth/
intel_dp_mst_mode_clock_exceeds_pbn_bw/
* Use the new drm_connector_helper_funcs.mode_valid_ctx to properly pipe
down the drm_modeset_acquire_ctx that the probe helpers are using, so
we can safely grab &mgr->base.lock without deadlocking
Changes since v4:
* Move drm_dp_calc_pbn_mode(mode->clock, bpp, false) > port->full_pbn
check
* Fix the bpp we use in drm_dp_calc_pbn_mode()
* Drop leftover (!mgr) check
* Don't check for if full_pbn is unset. To be clear - it _can_ be unset,
but if it is then it's certainly a bug in DRM or a non-compliant sink
as full_pbn should always be populated by the time we call
->mode_valid_ctx.
We should workaround non-compliant sinks with full_pbn=0, but that
should happen in the DP MST helpers so we can estimate the full_pbn
value as best we can.
Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Co-developed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713170746.254388-3-lyude@redhat.com
This is just an atomic version of mode_valid, which is intended to be
used for situations where a driver might need to check the atomic state
of objects other than the connector itself. One such example is with
MST, where the maximum possible bandwidth on a connector can change
dynamically irregardless of the display configuration.
Changes since v1:
* Use new drm logging functions
* Make some corrections in the mode_valid_ctx kdoc
* Return error codes or 0 from ->mode_valid_ctx() on fail, and store the
drm_mode_status in an additional function parameter
Changes since v2:
* Don't accidentally assign ret to mode->status on success, or we'll
squash legitimate mode validation results
* Don't forget to assign MODE_OK to status in drm_connector_mode_valid()
if we have no callbacks
* Drop leftover hunk in drm_modes.h around enum drm_mode_status
Changes since v3:
* s/return ret/return 0/ in drm_mode_validate_pipeline()
* Minor cleanup in drm_connector_mode_valid()
Chris Wilson [Mon, 13 Jul 2020 14:16:36 +0000 (15:16 +0100)]
drm/i915: Skip signaling a signaled request
Preempt-to-busy introduces various fascinating complications in that the
requests may complete as we are unsubmitting them from HW. As they may
then signal after unsubmission, we may find ourselves having to cleanup
the signaling request from within the signaling callback. This causes us
to recurse onto the same i915_request.lock.
However, if the request is already signaled (as it will be before we
enter the signal callbacks), we know we can skip the signaling of that
request during submission, neatly evading the spinlock recursion.
unsubmit(ve.rq0) # timeslice expiration or other preemption
-> virtual_submit_request(ve.rq0)
dma_fence_signal(ve.rq0) # request completed before preemption ack
-> submit_notify(ve.rq1)
-> virtual_submit_request(ve.rq1) # sees that we have completed ve.rq0
-> __i915_request_submit(ve.rq0)
Chris Wilson [Mon, 13 Jul 2020 16:05:49 +0000 (17:05 +0100)]
drm/i915/gt: Only swap to a random sibling once upon creation
The danger in switching at random upon intel_context_pin is that the
context may still actually be inflight, as it will not be scheduled out
until a context switch after it is complete -- that may be a long time
after we do a final intel_context_unpin.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2118 Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713160549.17344-1-chris@chris-wilson.co.uk
Colin Ian King [Mon, 13 Jul 2020 14:25:51 +0000 (15:25 +0100)]
drm/i915/selftest: fix an error return path where err is not being set
There is an error condition where err is not being set and an uninitialized
garbage value in err is being returned. Fix this by assigning err to an
appropriate error return value before taking the error exit path.
Addresses-Coverity: ("Uninitialized scalar value") Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across noa_wait") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200713142551.423649-1-colin.king@canonical.com
Chris Wilson [Sat, 11 Jul 2020 20:32:36 +0000 (21:32 +0100)]
drm/i915/gt: Ignore irq enabling on the virtual engines
We do not use the virtual engines for interrupts (they have physical
components), but we do use them to decouple the fence signaling during
submission. Currently, when we submit a completed request, we try to
enable the interrupt handler for the virtual engine, but we never disarm
it. A quick fix is then to mark the irq as enabled, and it will then
remain enabled -- and this prevents us from waking the device and never
letting it sleep again.
Fixes: f8db4d051b5e ("drm/i915: Initialise breadcrumb lists on the virtual engine") 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> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711203236.12330-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 11 Jul 2020 09:13:49 +0000 (10:13 +0100)]
drm/i915/gt: Always reset the engine, even if inactive, on execlists failure
If something has gone awry with the CSB processing, we need to pause,
unwind and restart the request submission and event processing. However,
currently we skip the engine reset if we raise an error but discover no
active context, in the mistaken belief that it was merely a glitch in
the matrix. The glitches are real enough, and we do need to unwind even
if the engine appears idle (as it has gone permanently idle!) The
simplest way to unwind and recover is simply do the engine reset, which
should be very fast and _safe_ as nothing is active.
Chris Wilson [Fri, 10 Jul 2020 19:32:39 +0000 (20:32 +0100)]
drm/i915: Pull printing GT capabilities on error to err_print_gt
We try not to assume that we captured any information, and so have to
check that error->gt exists before reporting. This check was missed in
err_print_capabilities, so lets break up the capability info and push it
into the GT dump.
We are still a long way from yamlifying this output!
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 792592e72aba ("drm/i915: Move the engine mask to intel_gt_info") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200710193239.5419-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 10 Jul 2020 13:31:25 +0000 (14:31 +0100)]
drm/i915/gt: Be defensive in the face of false CS events
If the HW throws a curve ball and reports either en event before it is
possible, or just a completely impossible event, we have to grin and
bear it. The first few events, we will likely not notice as we would be
expecting some event, but as soon as we stop expecting an event and yet
they still keep coming, then we enter into undefined state territory.
In which case, bail out, stop processing the events, and reset the
engine and our set of queued requests to recover.
The sporadic hangs and warnings will continue to plague CI, but at least
system stability should not be compromised.
v2: Commentary and force the reset-on-error.
v3: Customised user facing message for forced resets from internal errors.
Chris Wilson [Thu, 9 Jul 2020 22:45:04 +0000 (23:45 +0100)]
drm/i915/selftest: Check that GPR are restored across noa_wait
Perf implements a GPU delay (noa_wait) by looping until the CS timestamp
has passed a certain point. This use MI_MATH and the general purpose
registers of the user's context, and since it is clobbering the user
state it must carefully save and restore the user's data around the
noa_wait. We can verify this by loading some values in the GPR that we
know will be clobbered by the noa_wait, and then inspecting the GPR after
the noa_wait completes and confirming that they have been restored.
drm/i915/perf: Use GTT when saving/restoring engine GPR
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
translation to use when saving restoring the engine general purpose
registers to and from the GT scratch. Since GT scratch is mapped to
ggtt, we need to set an additional bit in the command to use GTT.
Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa configurations") Suggested-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200709224504.11345-1-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Thu, 9 Jul 2020 19:01:11 +0000 (20:01 +0100)]
drm/i915/gt: Optimise aliasing-ppgtt allocations
Since the aliasing-ppgtt remains the default for gen6/gen7, it is worth
optimising the ppgtt allocation for it. In this case, we do not need to
flush the GGTT page directories entries as they are fixed during setup.
drm/i915/selftests: Fix compare functions provided for sorting
Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value
at those pointers. This will result in incorrect/unsorted list. Fix it
by deferencing the pointers before comparison.
Fixes: 4ba74e53ada3 ("drm/i915/selftests: Verify frequency scaling with RPS") Fixes: 8757797ff9c9 ("drm/i915/selftests: Repeat the rps clock frequency measurement") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200709154931.23310-1-sudeep.holla@arm.com
As today those 2 WAs have different implementation between TGL and DG1
WA pages but checking the HSD it is clear that DG1 implementation
should be used for both, also to do so is easier as we just need to
extend WA 1407928979 to B* stepping.
Both WAs are need to fix some possible render corruptions.
DG1 initial patches were not merged yet, as soon it is this WAs should
be applied to DG1 as well.
Ville Syrjälä [Wed, 8 Jul 2020 13:12:20 +0000 (16:12 +0300)]
drm/i915: Move all FBC w/as to .init_clock_gating()
Some platforms apply the FBC w/as in .init_clock_gating(), some
in fbc_activate(). Move them all to .init_clock_gating() for
consistentce. Also safer since we don't have to worry about the
RMWs clashing with any other runtime use of the same registers.
Ville Syrjälä [Wed, 8 Jan 2020 18:12:42 +0000 (20:12 +0200)]
drm/i915/dvo: Make .get_modes() return the number of modes
.get_modes() is supposed to return the number of modes added to the
probed_modes list (not that anyone actually checks for anything
except zero vs. not zero). Let's do that.
Ville Syrjälä [Wed, 8 Jan 2020 18:12:41 +0000 (20:12 +0200)]
drm/i915/sdvo: Make .get_modes() return the number of modes
.get_modes() is supposed to return the number of modes added to the
probed_modes list (not that anyone actually checks for anything
except zero vs. not zero). Let's do that. Also switch over to using
intel_connector_update_modes() instead of hand rolling it.
Ville Syrjälä [Wed, 8 Jan 2020 18:12:40 +0000 (20:12 +0200)]
drm/i915/sdvo: Make SDVO deal with HDMI pixel repeat
With SDVO the pipe config pixel_multiplier only concerns itself with the
data on the SDVO bus. Any HDMI specific pixel repeat must be handled by
the SDVO device itself. To do that simply configure the SDVO pixel
replication factor appropriately. We already set up the infoframe PRB
values correctly via the infoframe helpers.
There is no cap we can check for this. The spec says that 1X,2X,4X are
mandatory, anything else is optional. 1X and 2X are all we need so
we should be able to assume they work.
Ville Syrjälä [Wed, 8 Jan 2020 18:12:39 +0000 (20:12 +0200)]
drm/i915: Reject DRM_MODE_FLAG_DBLCLK with DVI sinks
The code assumes that DRM_MODE_FLAG_DBLCLK means that we enable the
pixel repeat feature. That only works with HDMI since it requires
AVI infoframe to signal the information to the sink. Hence even if
the mode dotclock would be valid we cannot currently assume that
we can just ignore the DBLCLK flag. Reject it for DVI sinks.
Ville Syrjälä [Wed, 8 Jan 2020 18:12:38 +0000 (20:12 +0200)]
drm/i915/sdvo: Implement limited color range for SDVO HDMI properly
The SDVO/HDMI port register limited color range bit can only be used
with TMDS encoding and not SDVO encoding, ie. to be used only when
using the port as a HDMI port as opposed to a SDVO port. The SDVO
spec does have a note that some GMCHs might allow that, but gen4
bspec vehemently disagrees. I suppose on ILK+ it might work since
the color range handling is on the CPU side rather than on the PCH
side, so there is no clear linkage between the TMDS vs. SDVO
encoding and color range. Alas, I have no hardware to test that
theory.
To implement limited color range support for SDVO->HDMI we need to
ask the SDVO device to do the range compression. Do so, but first
check if the device even supports the colorimetry selection.
Chris Wilson [Wed, 8 Jul 2020 17:37:47 +0000 (18:37 +0100)]
drm/i915: Release shortlived maps of longlived objects
Some objects we map once during their construction, and then never
access their mappings again, even if they are kept around for the
duration of the driver. Keeping those pages mapped, often vmapped, is
therefore wasteful and we should release the maps as soon as we no
longer need them.
As we have a pin_map interface, that knows how to flush the data to the
device, use it. The only downside is that we keep the kmap around, as
once acquired we keep the mapping cached until the object's backing
store is released.
Chris Wilson [Wed, 8 Jul 2020 17:37:45 +0000 (18:37 +0100)]
drm/i915/gem: Unpin idle contexts from kswapd reclaim
We removed retiring requests from the shrinker in order to decouple the
mutexes from reclaim in preparation for unravelling the struct_mutex.
The impact of not retiring is that we are much less agressive in making
global objects available for shrinking, as such objects remain pinned
until they are flushed by a heartbeat pulse following the last retired
request along their timeline. In order to ensure that pulse occurs in
time for memory reclamation, we should kick it from kswapd.
The catch is that we have added some flush_work() into the retirement
phase (to ensure that we reach a global idle in a timely manner), but
these flush_work() are not eligible (i.e do not belong to WQ_MEM_RELCAIM)
for use from inside kswapd. To avoid flushing those workqueues, we teach
the retirer not to do so unless we are actually waiting, and only do the
plain retire from inside the shrinker.
Note that for execlists, we already retire completed contexts as they
are scheduled out, so it should not be keeping global state
unnecessarily pinned. The legacy ringbuffer however...
In line with what happened for other gt-related features, move the sseu
debugfs files under gt/.
The sseu_status debugfs has also been kept at the top level as we do
have tests that use it; it will be removed once we teach the tests to
look into the new path.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200708003952.21831-10-daniele.ceraolospurio@intel.com
We already call 2 gt-related init_mmio functions in driver_mmio_probe
and a 3rd one will be added by a follow-up patch, so pre-emptively
introduce a gt_init_mmio function to group them.
Since the engines belong to the GT, move the runtime-updated list of
available engines to the intel_gt struct. The original mask has been
renamed to indicate it contains the maximum engine list that can be
found on a matching device.
In preparation for other info being moved to the gt in follow up patches
(sseu), introduce an intel_gt_info structure to group all gt-related
runtime info.
drm/i915: Move engine-related mmio init to engines_init_mmio
All the info we read in intel_device_info_init_mmio are engine-related
and since we already have an engine_init_mmio function we can just
perform the operations from there.
v2: clarify comment about forcewake requirements and pruning (Chris)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200708003952.21831-4-daniele.ceraolospurio@intel.com
drm/i915/dp: Helper to check for DDI BUF status to get active
Based on the platform, Bspec expects us to wait or poll with
timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active
after enabling DDI_BUF_CTL.
v2:
* Based on platform, fixed delay or poll (Ville)
* Use a helper to do this (Imre, Ville)
v3:
* Add a new function _active for DDI BUF CTL to be non idle (Ville)
v4:
* Use the timeout for GLK (Ville)
v5:
* Add bspec quote, change timeout to 500us (Ville)
drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status
Modify the helper to add a fixed delay or poll with timeout
based on platform specification to check for either Idle bit
set (DDI_BUF_CTL is idle for disable case)
v2:
* Use 2 separate functions or idle and active (Ville)
v3:
* Change the timeout to 16usecs (Ville)
v4:
* Change the timeout 8, follow spec (Ville)
drm/i915/huc: Adjust HuC state accordingly after GuC fetch error
Firmware "Selected" state is a transient state - we don't expect to see
it after finishing driver probe, we even have asserts sprinkled over
i915 to confirm whether that's the case.
Unfortunately - we don't handle the transition out of "Selected" in case
of GuC fetch error, leading those asserts to fire when calling
"intel_huc_is_used()".
v2: Add dbg print when moving HuC into error state (Daniele)
Reported-by: Marcin Bernatowicz <marcin.bernatowicz@intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Marcin Bernatowicz <marcin.bernatowicz@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200708100843.297655-2-michal@hardline.pl
drm/i915/uc: Extract uc usage details into separate debugfs
It has been pointed out that information about HuC usage doesn't belong
in guc_info debugfs. Let's move "supported/used/wanted" matrix to a
separate debugfs file, keeping guc_info strictly about GuC.
Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lukasz Fiedorowicz <lukasz.fiedorowicz@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200708100843.297655-1-michal@hardline.pl
Anshuman Gupta [Tue, 30 Jun 2020 08:20:48 +0000 (13:50 +0530)]
drm/i915/hdcp: Update CP as per the kernel internal state
Content Protection property should be updated as per the kernel
internal state. Let's say if Content protection is disabled
by userspace, CP property should be set to UNDESIRED so that
reauthentication will not happen until userspace request it again,
but when kernel disables the HDCP due to any DDI disabling sequences
like modeset/DPMS operation, kernel should set the property to
DESIRED, so that when opportunity arises, kernel will start the
HDCP authentication on its own.
Somewhere in the line, state machine to set content protection to
DESIRED from kernel was broken and IGT coverage was missing for it.
This patch fixes it.
v2:
- Fixing hdcp CP state in connector atomic check function
intel_hdcp_atomic_check(). [Maarten]
This will require to check hdcp->value in intel_hdcp_update_pipe()
in order to avoid enabling hdcp, if it was already enabled.
Chris Wilson [Mon, 6 Jul 2020 22:43:08 +0000 (23:43 +0100)]
drm/i915: Update dma-attributes for our sg DMA
Looking through the attributes for DMA mappings, it appears that by
default dma_map_sg will try and create a kernel accessible map of the
page. We never access this, as we either have a struct page already or
an iomap, so we can request that the dma mapper does not create one.
Without a kernel map in place, one presumes the rest of the memory
control attributes do not apply. We also explicitly control the caches
around the mappings, so we can ask it not to bother synchronising itself.
Chris Wilson [Mon, 6 Jul 2020 17:01:38 +0000 (18:01 +0100)]
drm/i915/gt: Pin the rings before marking active
On eviction, we acquire the vm->mutex and then wait on the vma->active.
Therefore when binding and pinning the vma, we must follow the same
sequence, lock/pin the vma then mark it active. Otherwise, we mark the
vma as active, then wait for the vm->mutex, and meanwhile the evictor
holding the mutex waits upon us to complete our activity.
It is not really unexpected to hit wedge on init this way.
We're already downgrading error printk when running with fault injection,
let's use the same approach for CI tainting.
v2: Don't check fault inject in trace dump (Chris)
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Petri Latvala <petri.latvala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200706144107.204821-3-michal@hardline.pl
We can add taint from multiple places, printing the caller allows us to
have a better overview of what exactly caused us to do the tainting.
v2: Tweak format and print the device (Chris)
v3: Move things around (Chris)
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Petri Latvala <petri.latvala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200706144107.204821-2-michal@hardline.pl
drm/i915: Reboot CI if we get wedged during driver init
Getting wedged device on driver init is pretty much unrecoverable.
Since we're running various scenarios that may potentially hit this in
CI (module reload / selftests / hotunplug), and if it happens, it means
that we can't trust any subsequent CI results, we should just apply the
taint to let the CI know that it should reboot (CI checks taint between
test runs).
v2: Comment that WEDGED_ON_INIT is non-recoverable, distinguish
WEDGED_ON_INIT from WEDGED_ON_FINI (Chris)
v3: Appease checkpatch, fixup search-replace logic expression mindbomb
in assert (Chris)
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Petri Latvala <petri.latvala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200706144107.204821-1-michal@hardline.pl
Chris Wilson [Fri, 3 Jul 2020 10:25:19 +0000 (11:25 +0100)]
drm/i915: Export ppgtt_bind_vma
Reuse the ppgtt_bind_vma() for aliasing_ppgtt_bind_vma() so we can
reduce some code near-duplication. The catch is that we need to then
pass along the i915_address_space and not rely on vma->vm, as they
differ with the aliasing-ppgtt.
Ville Syrjälä [Thu, 2 Jul 2020 15:37:23 +0000 (18:37 +0300)]
drm/i915/fbc: Allow FBC to recompress after a 3D workload on i85x/i865
Normally i85x/i865 3D activity will block FBC until a 2D blit
occurs. I suppose this was meant to avoid recompression while
3D activity is still going on but the frame hasn't yet been
presented. Unfortunately that also means that a page flipped
3D workload will permanently block FBC even if it only renders
a single frame and then does nothing.
Since we are using software render tracking anyway we might as
well flip the chicken bit so that 3D does not block FBC. This
will avoid the permament FBC blockage in the aforemention use
case, but thanks to the software tracking the compressor will
not disturb 3D rendering activity.
Ville Syrjälä [Thu, 2 Jul 2020 15:37:21 +0000 (18:37 +0300)]
drm/i915/fbc: Fix nuke for pre-snb platforms
The MSG_FBC_REND_STATE register only exists on snb+. For older
platforms (would also work for snb+) we can simply rewite DSPSURF
to trigger a flip nuke.
While generally RMW is considered harmful we'll use it here for
simplicity. And since FBC doesn't exist in i830 we don't have to
worry about the DSPSURF double buffering hardware fails present
on that platform.
Ville Syrjälä [Thu, 2 Jul 2020 15:37:20 +0000 (18:37 +0300)]
drm/i915/fbc: Use the correct plane stride
Consult the actual plane stride instead of the fb stride. The two
will disagree when we remap the gtt. The plane stride is what the
hw will be fed so that's what we should look at for the FBC
retrictions/cfb allocation.
Since we no longer require a fence we are going to attempt using
FBC with remapping, and so we should look at correct stride.
With 90/270 degree rotation the plane stride is stored in units
of pixels, so we need to conver it to bytes for the purposes
of calculating the cfb stride. Not entirely sure if this matches
the hw behaviour though. Need to reverse engineer that at some
point...
We also need to reorder the pixel format check vs. stride check
to avoid triggering a spurious WARN(stride & 63) with cpp==1 and
plane stride==32.
v2: Try to deal with rotated stride and related WARN
drm/i915/tgl: Clamp min_cdclk to max_cdclk_freq to unblock 8K
We still need "Bump up CDCLK" workaround otherwise getting
underruns - however currently it blocks 8K as CDCLK = Pixel rate,
in 8K case would require CDCLK to be around 1 Ghz which is not
possible.
v2: - Convert to expression(max(min_cdclk, min(pixel_rate, max_cdclk))
(Ville Syrjälä)
- Use type specific min_t, max_t(Ville Syrjälä)
drm/i915/guc: Expand guc_info debugfs with more information
The information about platform/driver/user view of GuC firmware usage
currently requires user to either go through kernel log or parse the
combination of "enable_guc" modparam and various debugfs entries.
Let's keep things simple and add a "supported/used/wanted" matrix
(already used internally by i915) in guc_info debugfs.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lukasz Fiedorowicz <lukasz.fiedorowicz@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lukasz Fiedorowicz <lukasz.fiedorowicz@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200701142752.419878-1-michal@hardline.pl
Chris Wilson [Fri, 3 Jul 2020 00:43:06 +0000 (01:43 +0100)]
drm/i915/gem: Split the context's obj:vma lut into its own mutex
Rather than reuse the common ctx->mutex for locking the execbuffer LUT,
split it into its own lock to avoid being taken [as part of ctx->mutex]
at inappropriate times. In particular to avoid the inversion from taking
the timeline->mutex for the whole execbuf submission in the next patch.
Chris Wilson [Thu, 2 Jul 2020 21:10:15 +0000 (22:10 +0100)]
drm/i915: Also drop vm.ref along error paths for vma construction
Not only do we need to release the vm.ref we acquired for the vma on the
duplicate insert branch, but also for the normal error paths, so roll
them all into one.
Reported-by: Andi Shyti <andi.shyti@intel.com> Suggested-by: Andi Shyti <andi.shyti@intel.com> Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702211015.29604-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 2 Jul 2020 08:32:05 +0000 (09:32 +0100)]
drm/i915/gem: Drop forced struct_mutex from shrinker_taints_mutex
Since we no longer always take struct_mutex around everything, and want
the freedom to create GEM objects, actually taking struct_mutex inside
the lock creation ends up pulling the mutex inside other looks. Since we
don't use generally use struct_mutex, we can relax the tainting.
Chris Wilson [Thu, 2 Jul 2020 16:36:23 +0000 (17:36 +0100)]
drm/i915/gem: Only revoke mmap handlers if active
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more freedom of workqueue ordering
during shutdown.
v2: Pull the release_mmap() into its single user in freeing the objects,
where there can not be any race with a concurrent user of the freed
object. Or so one hopes!
Chris Wilson [Thu, 2 Jul 2020 16:36:22 +0000 (17:36 +0100)]
drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes
Only a GGTT mmapping will use the aperture detiling registers, so on a
tiling change for an object, we only need to revoke those mmappings and
not the CPU mmappings (which are always linear irrespective of the tiling).
Chris Wilson [Thu, 2 Jul 2020 08:32:03 +0000 (09:32 +0100)]
drm/i915: Drop vm.ref for duplicate vma on construction
As we allow for parallel threads to create the same vma instance
concurrently, and we only filter out the duplicates upon reacquiring the
spinlock for the rbtree, we have to free the loser of the constructors'
race. When freeing, we should also drop any resource references acquired
for the redundant vma.
Chris Wilson [Thu, 2 Jul 2020 09:52:19 +0000 (10:52 +0100)]
drm/i915/gt: Move the heartbeat into the high priority system wq
As we ensure that the heartbeat is reasonably fast (and should not
block), move the heartbeat work into the system_highpri_wq to avoid
having this essential task be blocked behind other slow work, such as
our own retire_work_handler.
Chris Wilson [Thu, 2 Jul 2020 09:52:18 +0000 (10:52 +0100)]
drm/i915/gt: Harden the heartbeat against a stuck driver
If the driver gets stuck holding the kernel timeline, we cannot issue a
heartbeat and so fail to discover that the driver is indeed stuck and do
not issue a GPU reset (which would hopefully unstick the driver!).
Switch to using a trylock so that we can query if the heartbeat's
timeline mutex is locked elsewhere, and then use the timer to probe if it
remains stuck at the same spot for consecutive heartbeats, indicating
that the mutex has not been released and the engine has not progressed.
Matt Atwood [Tue, 30 Jun 2020 23:33:10 +0000 (16:33 -0700)]
drm/i915/dp: Correctly advertise HBR3 for GEN11+
intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
use before encoder_type is set. This caused GEN11+ to incorrectly strip
HBR3 from source rates for edp. Move intel_dp_set_source_rates() to
after encoder_type is set. Add comment to intel_dp_is_edp() describing
unsafe usages.
v2: Alter intel_dp_set_source_rates final position (Ville/Manasi).
Remove outdated comment (Ville).
Slight optimization of control flow in intel_dp_init_connector.
Slight rewording in commit message.
To simplify things, call the combo PHY/TBT PLL calculation functions
directly from the corresponding combo/TypeC PLL get functions, instead of
calling the same calculation functions after having to recheck if the
given PHY is combo or TypeC.
Imre Deak [Mon, 29 Jun 2020 18:58:47 +0000 (21:58 +0300)]
drm/i915/tgl+: Fix TBT DPLL fractional divider for 38.4MHz ref clock
When the reference clock is 38.4MHz, using the current TBT PLL
fractional divider value results in a slightly off TBT link frequency.
This causes an endless loop of link training success followed by a bad
link signaling and retraining at least on a Dell WD19TB TBT dock. The
workaround provided by the HW team is to divide the fractional divider
value by two. This fixed the link training problem on the ThinkPad dock.
The same workaround is needed on some EHL platforms and for combo PHY
PLLs, these will be addressed in a follow-up.
Chris Wilson [Wed, 1 Jul 2020 08:44:39 +0000 (09:44 +0100)]
drm/i915/gem: Move obj->lut_list under its own lock
The obj->lut_list is traversed when the object is closed as the file
table is destroyed during process termination. As this occurs before we
kill any outstanding context if, due to some bug or another, the closure
is blocked, then we fail to shootdown any inflight operations
potentially leaving the GPU spinning forever. As we only need to guard
the list against concurrent closures and insertions, the hold is short
and merits being treated as a simple spinlock.
This registers will be used to implement PSR2 manual tracking/selective
fetch.
v2:
- Fixed typo in _PLANE_SEL_FETCH_BASE
- Renamed PSR2_MAN_TRK_CTL bits to better match spec names
- Renamed _PLANE_SEL_FETCH_* to better match spec names
Future patches will bring PSR2 selective fetch configuration
validation but most of the configuration checks will be used for HW
tracking and selective fetch so the reoder was necessary.
Chris Wilson [Fri, 19 Jun 2020 19:40:38 +0000 (20:40 +0100)]
drm/i915/gem: Avoid kmalloc under i915->mm_lock
Rearrange the allocation of the mm_struct registration to avoid
allocating underneath the i915->mm_lock, so that we avoid tainting the
lock (and in turn many other locks that may be held as i915->mm_lock is
taken, and those locks we may want on the free [shrinker] paths). In
doing so, we convert the lookup to be RCU protected by courtesy of
converting the free-worker to be an rcu_work.
v2: Remember to use hash_rcu variants to protect the list iteration from
concurrent add/del.
Ville Syrjälä [Wed, 29 Apr 2020 10:10:34 +0000 (13:10 +0300)]
drm/i915: Suppress spurious underruns on gen2
Often we seem to detect an underrun right after modeset on gen2.
It seems to be a spurious detection (potentially the pipe is still
in a wonky state when we enable the planes). An extra vblank wait
seems to cure it.
Ville Syrjälä [Wed, 29 Apr 2020 10:10:32 +0000 (13:10 +0300)]
drm/i915/fbc: Reduce fbc1 compression interval to 1 second
The default fbc1 compression interval we use is 500 frames. That
translates to over 8 seconds typically. That's rather excessive
so let's drop it to 1 second.
The hardware will not attempt recompression unless at least one
line has been modified, so a shorter compression interval should
not cause extra bandwidth use in the purely idle scenario. Of
course in the mostly idle case we are possibly going to recompress
a bit more.
Should really try to find some kind of sweet spot to minimize
the energy usage...
Ville Syrjälä [Wed, 29 Apr 2020 10:10:25 +0000 (13:10 +0300)]
drm/i915/fbc: Fix fence_y_offset handling
The current fence_y_offset calculation is broken. I think it more or
less used to do the right thing, but then I changed the plane code
to put the final x/y source offsets back into the src rectangle so
now it's just subtraacting the same value from itself. The code would
never have worked if we allowed the framebuffer to have a non-zero
offset.
Let's do this in a better way by just calculating the fence_y_offset
from the final plane surface offset. Note that we don't align the
plane surface address to fence rows so with horizontal panning there's
often a horizontal offset from the fence start to the surface address
as well. We have no way to tell the hardware about that so we just
ignore it. Based on some quick tests the invlidation still happens
correctly. I presume due to the invalidation nuking at least the full
line (or a segment of multiple lines).
Chris Wilson [Tue, 30 Jun 2020 15:27:24 +0000 (16:27 +0100)]
drm/i915: Skip stale object handle for debugfs per-file-stats
As we close a handle GEM object, we update the drm_file's idr with an
error^W NULL pointer to indicate the in-progress closure, and finally
removing it. If we read the idr directly, we may then see an invalid
object pointer, and in our debugfs per_file_stats() we therefore need
to protect against the entry being invalid.
Colin Ian King [Tue, 16 Jun 2020 11:42:21 +0000 (12:42 +0100)]
drm/i915/display: fix missing null check on allocated dsb object
Currently there is no null check for a failed memory allocation
on the dsb object and without this a null pointer dereference
error can occur. Fix this by adding a null check.
Note: added a drm_err message in keeping with the error message style
in the function.
projects / mirror_ubuntu-jammy-kernel.git / log