Stanislav Lisovskiy [Thu, 9 Apr 2020 15:47:18 +0000 (18:47 +0300)]
drm/i915: Start passing latency as parameter
We need to start passing memory latency as a
parameter when calculating plane wm levels,
as latency can get changed in different
circumstances(for example with or without SAGV).
So we need to be more flexible on that matter.
v2: Changed latency type from u32 to unsigned int(Ville Syrjälä)
Kai Vehmanen [Mon, 30 Mar 2020 14:44:21 +0000 (17:44 +0300)]
drm/i915: do AUD_FREQ_CNTRL state save on all gen9+ platforms
Replace the TGL/ICL specific platform checks with a more generic check
using INTEL_GEN(). Fixes bug with broken audio after S3 resume on JSL
platforms.
An initial version of state save and restore of AUD_FREQ_CNTRL register
was added for subset of platforms in commit 87c1694533c9
("drm/i915: save AUD_FREQ_CNTRL state at audio domain suspend"). The state
save has proven to work well and it is needed in newer platforms, so needs
to be extended. Although the logic is not in practise needed on GEN9/10
systems, follow the hardware specification and apply state and restore on
all gen9+ platforms.
Chris Wilson [Fri, 10 Apr 2020 08:35:35 +0000 (09:35 +0100)]
agp/intel: Reinforce the barrier after GTT updates
After changing the timing between GTT updates and execution on the GPU,
we started seeing sporadic failures on Ironlake. These were narrowed
down to being an insufficiently strong enough barrier/delay after
updating the GTT and scheduling execution on the GPU. By forcing the
uncached read, and adding the missing barrier for the singular
insert_page (relocation paths), the sporadic failures go away.
Fixes: 983d308cb8f6 ("agp/intel: Serialise after GTT updates") Fixes: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Andi Shyti <andi.shyti@intel.com> Cc: stable@vger.kernel.org # v4.0+ Link: https://patchwork.freedesktop.org/patch/msgid/20200410083535.25464-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 10 Apr 2020 08:16:38 +0000 (09:16 +0100)]
drm/i915/selftests: Check for an already completed timeslice
With timeslice yielding on a semaphore, we may complete timeslices much
faster than we were expecting and already have yielded the stuck
request. Before complaining that timeslicing is not enabled, check that
we haven't already applied the switch.
Colin Ian King [Thu, 9 Apr 2020 13:31:07 +0000 (14:31 +0100)]
drm/i915: remove redundant assignment to variable err
The variable err is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Matthew Auld [Wed, 8 Apr 2020 17:04:56 +0000 (18:04 +0100)]
drm/i915/evict: watch out for unevictable nodes
In an address space there can be sprinkling of I915_COLOR_UNEVICTABLE
nodes, which lack a parent vma. For platforms with cache coloring we
might be very unlucky and abut with such a node thinking we can simply
unbind the vma.
Chris Wilson [Tue, 7 Apr 2020 22:18:32 +0000 (23:18 +0100)]
drm/i915/gt: Mark up racy read of intel_ring.head
The intel_ring.head is updated as the requests are retired, but is
sampled at any time as we submit requests. Furthermore, it tracks
RING_HEAD which is inherently asynchronous.
Chris Wilson [Tue, 7 Apr 2020 22:26:25 +0000 (23:26 +0100)]
drm/i915/selftests: Drop vestigal timeslicing assert
Since the semaphore interrupt may cause us to yield the timeslice
immediately, we may cancel the timer before we notice the submission is
complete. The assertion is no longer valid due to the race with the
interrupt.
Chris Wilson [Tue, 7 Apr 2020 13:08:11 +0000 (14:08 +0100)]
drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only real complication is that the interrupt is only generated for
the start of the semaphore wait, and is asynchronous to our
process_csb() -- that is, we may not have registered the timeslice before
we see the interrupt. To ensure we don't miss a potential semaphore
blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark
the interrupt and apply it to the next timeslice regardless of whether it
was active at the time.
v2: We use semaphores in preempt-to-busy, within the timeslicing
implementation itself! Ergo, when we do insert a preemption due to an
expired timeslice, the new context may start with the missed semaphore
flagged by the retired context and be yielded, ad infinitum. To avoid
this, read the context id at the time of the semaphore interrupt and
only yield if that context is still active.
Chris Wilson [Mon, 6 Apr 2020 15:58:40 +0000 (16:58 +0100)]
drm/i915/gem: Wait until the context is finally retired before releasing engines
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin. So
wait until the intel_context is finally retired before releasing the
engine, so that we can inspect the final context state and pass it on.
Chris Wilson [Mon, 6 Apr 2020 15:58:39 +0000 (16:58 +0100)]
drm/i915: Allow asynchronous waits on the i915_active barriers
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protection as it too
walks the rbtree and so we must be careful that we do not free it as we
iterate.
Chris Wilson [Mon, 6 Apr 2020 15:58:38 +0000 (16:58 +0100)]
drm/i915: Make exclusive awaits on i915_active optional
Later use will require asynchronous waits on the active timelines, but
will not utilize an async wait on the exclusive channel. Make the await
on the exclusive fence explicit in the selection flags.
Imre Deak [Mon, 30 Mar 2020 09:54:25 +0000 (12:54 +0300)]
drm/i915: Extend hotplug detect retry on TypeC connectors to 5 seconds
On TypeC ports if a sink deasserts/reasserts its HPD signal, generating
a hotplug interrupt without the sink getting unplugged/replugged from
the connector, there can be an up to 3 seconds delay until the AUX
channel gets functional. To avoid detection failures this delay causes
retry the detection for 5 seconds.
I noticed this on ICL/TGL RVPs and a DELL XPS 13 7390 ICL laptop.
Imre Deak [Mon, 30 Mar 2020 09:54:24 +0000 (12:54 +0300)]
drm/i915: Add a retry counter for hotplug detect retries
On TypeC connectors we need to retry the detection after hotplug events
for a longer time, so add a retry counter to support this. The next
patch will add detection retries on TypeC ports needing this.
Chris Wilson [Fri, 3 Apr 2020 19:02:09 +0000 (20:02 +0100)]
drm/i915/selftests: Wait until we start timeslicing after a submit
If we submit, we do not start timeslicing until we process the CS event
that marks the start of the context running on HW. So in the selftest,
be sure to wait until we have processed the pending events before
asserting that timeslicing has begun.
Chris Wilson [Fri, 3 Apr 2020 12:01:50 +0000 (13:01 +0100)]
drm/i915: Check current i915_vma.pin_count status first on unbind
Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is
currently pinned, without waiting to see if the inflight operations may
unpin it. We see this problem with the shrinker trying to unbind the
active vma from inside its bind worker:
Ashutosh Dixit [Fri, 3 Apr 2020 01:01:20 +0000 (18:01 -0700)]
drm/i915/perf: Do not clear pollin for small user read buffers
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smaller than the available data.
This change fixes this issue and allows user space to read all OA data
even when using a buffer size smaller than the available data using
multiple non-blocking reads rather than staying blocked in poll till
the next timer interrupt.
v2: Fix ret value for blocking reads (Umesh)
v3: Mistake during patch send (Ashutosh)
v4: Remove -EAGAIN from comment (Umesh)
v5: Improve condition for clearing pollin and return (Lionel)
v6: Improve blocking read loop and other cleanups (Lionel)
v7: Added Cc stable
Testcase: igt/perf/polling-small-buf Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200403010120.3067-1-ashutosh.dixit@intel.com
Ville Syrjälä [Fri, 13 Mar 2020 16:48:30 +0000 (18:48 +0200)]
drm/i915: Pass atomic state to encoder hooks
We're going to want access to the atomic state for iterating
the slave crtcs when enabling the port sync master crtc. Pass
the atomic state all the way down.
The alternative would be yet another encoder hook which we'll
have to call after all the normal modeset stuff is done. Not
really a fan of yet another hook just for this.
Note that during readout state sanitation we are now going
to pass NULL as the atomic state since we don't have one.
We need to change that and then we can also s/crtc_state/crtc/
and s/conn_state/conn/ for the encoder hooks as well.
Ville Syrjälä [Fri, 13 Mar 2020 16:48:29 +0000 (18:48 +0200)]
drm/i915: Do pipe updates after enables for everyone
Currently only port sync pipes do the sequence such that
we first do the modeset part for every pipe and then do
the plane/etc. updates. Let's follow that apporach for
all pipes in skl+ so that we can properly integrate the
port sync into the normal modeset flow.
v2: Remove now stale TODO of port sync slave entries[]
s/oldnew/new/
Ville Syrjälä [Fri, 13 Mar 2020 16:48:26 +0000 (18:48 +0200)]
drm/i915: Implement port sync for SKL+
Transcoder port sync was introduced to the hardware in BDW. We
can trivially enable it for SKL+ since the same codepaths are
already used for ICL+ port sync. The only difference is the actual
location of the bits we need to poke.
We leave BDW out (at least for now) since it uses different modeset
paths that haven't been adapted for port sync, and IIRC using the
feature would involve some extra workarounds we've not implemented.
Pre-BDW hardware does not support port sync so we'd have to tweak
the modeset sequence to start the pipes as close together as possible
and hope for the best. So far no one has seriously tried to implement
that.
Ville Syrjälä [Wed, 18 Mar 2020 17:02:35 +0000 (19:02 +0200)]
drm/i915: Store cpu_transcoder_mask in device info
We have a bunch of code that would like to know which
CPU transcoders are actually present in the hardware. Rather than
use various ad-hoc methods let's just include a full bitmask in
the device info, alongside pipe_mask.
Chris Wilson [Fri, 3 Apr 2020 07:36:57 +0000 (08:36 +0100)]
drm/i915: Avoid setting timer->expires to 0
We use timer->expires == 0 to detect if a timer had been cancelled, but
it's a valid expiration we could set. Just skip using 0 and set the
expiry for the next jiffie.
Chris Wilson [Thu, 2 Apr 2020 18:40:37 +0000 (19:40 +0100)]
drm/i915: Keep a per-engine request pool
Add a tiny per-engine request mempool so that we should always have a
request available for powermanagement allocations from tricky
contexts. This reserve is expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
The main consumer for this reserved request is expected to be engine-pm,
for which we know that there will always be at least the previous pm
request that we can reuse under mempressure (so there should always be
a spare request for engine_park()).
This is an alternative to using a comparatively bulky mempool, which
requires custom handling for both our reserved allocation requirement
and to protect our TYPESAFE_BY_RCU slab cache. The advantage of mempool
would be that it would allow us to keep a larger per-engine request
pool. However, converting over to mempool is straightforward should the
need arise.
Swathi Dhanavanthri [Thu, 26 Mar 2020 23:49:55 +0000 (16:49 -0700)]
drm/i915/tgl: Make Wa_14010229206 permanent
This workaround now applies to all steppings, not just A0.
Wa_1409085225 is a temporary A0-only W/A however it is
identical to Wa_14010229206 and hence the combined workaround
is made permanent.
Bspec: 52890
Chris Wilson [Thu, 2 Apr 2020 12:42:18 +0000 (13:42 +0100)]
drm/i915/gem: Utilize rcu iteration of context engines
Now that we can peek at GEM->engines[] and obtain a reference to them
using RCU, do so for instances where we can safely iterate the
potentially old copy of the engines. For setting, we can do this when we
know the engine properties are copied over before swapping, so we know
the new engines already have the global property and we update the old
before they are discarded. For reading, we only need to be safe; as we
do so on behalf of the user, their races are their own problem.
Chris Wilson [Wed, 1 Apr 2020 11:04:34 +0000 (12:04 +0100)]
drm/i915/execlists: Peek at the next submission for error interrupts
If we receive the error interrupt before the CS interrupt, we may find
ourselves without an active request to reset, skipping the GPU reset.
All because the attempt to reset was too early.
Chris Wilson [Mon, 30 Mar 2020 21:22:54 +0000 (22:22 +0100)]
drm/i915/uc: Cleanup kerneldoc warnings
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:205: warning: Excess function parameter 'supported' description in 'intel_uc_fw_init_early'
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:205: warning: Excess function parameter 'platform' description in 'intel_uc_fw_init_early'
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:205: warning: Excess function parameter 'rev' description in 'intel_uc_fw_init_early'
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c:696: warning: Function parameter or member 'log' not described in 'intel_guc_log_info'
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c:696: warning: Excess function parameter 'guc' description in 'intel_guc_log_info'
Chris Wilson [Wed, 1 Apr 2020 22:39:24 +0000 (23:39 +0100)]
drm/i915/gem: Drop cached obj->bind_count
We cached the number of vma bound to the object in order to speed up
shrinker decisions. This has been superseded by being more proactive in
removing objects we cannot shrink from the shrinker lists, and so we can
drop the clumsy attempt at atomically counting the bind count and
comparing it to the number of pinned mappings of the object. This will
only get more clumsier with asynchronous binding and unbinding.
Chris Wilson [Wed, 1 Apr 2020 21:01:04 +0000 (22:01 +0100)]
drm/i915/gt: Make fence revocation unequivocal
If we must revoke the fence because the VMA is no longer present, or
because the fence no longer applies, ensure that we do and convert it
into an error if we try but cannot.
Chris Wilson [Wed, 1 Apr 2020 21:01:02 +0000 (22:01 +0100)]
drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence
Only GPU activity via the GGTT fence is asynchronous, we know that we
control the CPU access directly, so we only need to wait for the GPU to
stop using the fence before we relinquish it.
Chris Wilson [Wed, 1 Apr 2020 19:41:35 +0000 (20:41 +0100)]
drm/i915/gem: Try allocating va from free space
If the current node/entry location is occupied, and the object is not
pinned, try assigning it some free space. We cannot wait here, so if in
doubt, we unreserve and try to grab all at once.
v2: Use the final pin_flags so that we won't have to move the object if
we find the wrong free space.
Chris Wilson [Tue, 31 Mar 2020 16:21:50 +0000 (17:21 +0100)]
drm/i915/gem: Ignore readonly failures when updating relocs
If the user passes in a readonly reloc[], by the time we notice we have
already committed to modifying the execobjects, or have indeed done so
already. Reporting the failure just compounds the issue as we have no
second pass to fall back to anymore.
"Be damned if you do, and damned if you don't."
Testcase: igt/gem_exec_reloc/readonly Fixes: 7dc8f1143778 ("drm/i915/gem: Drop relocation slowpath")
References: fddcd00a49e9 ("drm/i915: Force the slow path after a user-write error") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200331162150.3635-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 31 Mar 2020 15:23:48 +0000 (16:23 +0100)]
drm/i915/gt: Fill all the unused space in the GGTT
When we allocate space in the GGTT we may have to allocate a larger
region than will be populated by the object to accommodate fencing. Make
sure that this space beyond the end of the buffer points safely into
scratch space, in case the HW tries to access it anyway (e.g. fenced
access to the last tile row).
v2: Preemptively / conservatively guard gen6 ggtt as well.
Reported-by: Imre Deak <imre.deak@intel.com>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1554 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200331152348.26946-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 31 Mar 2020 09:14:57 +0000 (10:14 +0100)]
drm/i915/execlists: Pause CS flow before reset
Since we may be attempting to reset an active engine, we try to freeze
it in place before resetting -- to be on the safe side. We can go one
step further if we are using the CS flow semaphore to prevent the
context switching into the next.
Chris Wilson [Tue, 31 Mar 2020 11:48:52 +0000 (12:48 +0100)]
drm/i915: Defer kicking the tasklet until all rescheduling is complete
Since we may kick more than engine, and may kick each one a couple of
times, coalesce the tasklet execution to the end. This also ensures that
we have the chance to run the tasklet immediately after priority
bumping.
José Roberto de Souza [Mon, 30 Mar 2020 21:00:42 +0000 (14:00 -0700)]
drm/i915/dp: Return the right vswing tables
DDI ports have its encoders initialized with INTEL_OUTPUT_DDI type and
later eDP ports that have the type changed to INTEL_OUTPUT_EDP.
But for all other DDI ports it can drive HDMI or DP depending on what
user connects to the ports.
ehl_get_combo_buf_trans() and tgl_get_combo_buf_trans() was checking
for INTEL_OUTPUT_DP that was never true, causing wrong vswing tables
being used.
So here replacing the INTEL_OUTPUT_DP checks by the valid output types
that this functions receives as parameters. HDMI cases will be
correctly handled as it do not use encoder->type, instead it calls the
functions with INTEL_OUTPUT_HDMI as type parameter and HDMI don't have
retraining.
v2:
changed INTEL_OUTPUT_DDI to INTEL_OUTPUT_EDP and INTEL_OUTPUT_HDMI
Fixes: bd3cf6f7ce20 ("drm/i915/dp/tgl+: Update combo phy vswing tables") Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330210044.130510-1-jose.souza@intel.com
In this sequence, we can see that although we have submitted the next
request [ff84:45156] to HW (via ELSP[]) it has not yet reported the
lite-restore. Instead, we see the completion event of the currently
active request [ff84:45155] but at the time of processing that event,
the breadcrumb has not yet been written. Though by the time we do print
out the debug info, the seqno write of ff84:45156 has landed!
Therefore there is a serialisation problem between the seqno writes and
CS events, not just between the CS buffer and its head/tail pointers as
previously observed on Icelake.
This is not a huge problem, as we don't strictly rely on the breadcrumb
to determine HW activity, but it may indicate that interrupt delivery is
before the seqno write, aka bringing back the plague of missed
interrupts from yesteryear. However, there is no indication of this
wider problem, so let's just flush the seqno read before reporting an
error. If it persists after the fresh read we can worry again.
Chris Wilson [Mon, 30 Mar 2020 12:58:27 +0000 (13:58 +0100)]
drm/i915/execlists: Explicitly reset both reg and context runtime
Upon a GPU reset, we copy the default context image over top of the
guilty image. This will rollback the CTX_TIMESTAMP register to before
our value of ce->runtime.last. Reset both back to 0 so that we do not
encounter an underflow on the next schedule out after resume.
This should not be a huge issue in practice, as hangs should be rare in
correct code.
Chris Wilson [Mon, 30 Mar 2020 13:37:10 +0000 (14:37 +0100)]
drm/i915/gem: Split eb_vma into its own allocation
Use a separate array allocation for the execbuf vma, so that we can
track their lifetime independently from the copy of the user arguments.
With luck, this has a secondary benefit of splitting the malloc size to
within reason and avoid vmalloc. The downside is that we might require
two separate vmallocs -- but much less likely.
In the process, this prevents a memory leak on the ww_mutex error
unwind.
Chris Wilson [Fri, 27 Mar 2020 11:22:12 +0000 (11:22 +0000)]
drm/i915/perf: Schedule oa_config after modifying the contexts
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct context to the state modifications, we need that command packet
to be always last in the queue.
We borrow the i915_active for its ability to track multiple timelines
and the last dma_fence on each; a flexible dma_resv. Keeping track of
each dma_fence is important for us so that we can efficiently schedule
the requests and reprioritise as required.
Chris Wilson [Fri, 27 Mar 2020 11:22:11 +0000 (11:22 +0000)]
drm/i915: Wrap i915_active in a simple kreffed struct
For conveniences of callers that just want to use an i915_active to
track a wide array of concurrent timelines, wrap the base i915_active
struct inside a kref. This i915_active will self-destruct after use.
Chris Wilson [Mon, 30 Mar 2020 12:16:44 +0000 (13:16 +0100)]
drm/i915/selftests: Check timeout before flush and cond checks
Allow a bit of leniency for the CPU scheduler to be distracted while we
flush the tasklet and so ensure that we always check the status of the
request once more before timing out.
v2: Wait until the HW acked the submit, and we do any secondary actions
for the submit (e.g. timeslices)
Michal Wajdeczko [Mon, 30 Mar 2020 11:33:02 +0000 (13:33 +0200)]
drm/i915/huc: Add more errors for I915_PARAM_HUC_STATUS
There might be many reasons why we failed to successfully
load and authenticate HuC firmware, but today we only use
single error in case of no HuC hardware. Add some more
error codes for most common cases (disabled, not installed,
corrupted or mismatched firmware).
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tony Ye <tony.ye@intel.com> Cc: Robert M. Fosha <robert.m.fosha@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/20200330113302.1670-1-michal.wajdeczko@intel.com
Chris Wilson [Fri, 27 Mar 2020 20:14:33 +0000 (20:14 +0000)]
drm/i915/execlists: Workaround switching back to a completed context
In what seems remarkably similar to the w/a required to not reload an
idle context with HEAD==TAIL, it appears we must prevent the HW from
switching to an idle context in ELSP[1], while simultaneously trying to
preempt the HW to run another context and a continuation of the idle
context (which is no longer idle).
We can achieve this by preventing the context from completing while we
reload a new ELSP (by applying ring_set_paused(1) across the whole of
dequeue), except this eventually fails due to a lite-restore into a
waiting semaphore does not generate an ACK. Instead, we try to avoid
making the GPU do anything too challenging and not submit a new ELSP
while the interrupts + CSB events appear to have fallen behind the
completed contexts. We expect it to catch up shortly so we queue another
tasklet execution and hope for the best.
Ville Syrjälä [Fri, 13 Mar 2020 16:48:19 +0000 (18:48 +0200)]
drm/i915/mst: Use .compute_config_late() to compute master transcoder
Use the recently introduced encoder .compute_config_late() hook to
do the MST master transcoder assignment. Avoids having to do it
in a funny way before we know the CPU transcoder of each pipe.
And now we can also properly use hw.active instead of uapi.active
since it too has been calculated earlier for everyone.
Chris Wilson [Thu, 26 Mar 2020 14:27:27 +0000 (14:27 +0000)]
drm/i915: Differentiate between aliasing-ppgtt and ggtt pinning
Userptr causes lockdep to complain when we are using the aliasing-ppgtt
(and ggtt, but for that it is rightfully so to complain about) in that
when we revoke the userptr we take a mutex which we also use to revoke
the mmaps. However, we only revoke mmaps for GGTT bindings and we never
allow userptr to create a GGTT binding so the warning should be false
and is simply caused by our conflation of the aliasing-ppgtt with the
ggtt. So lets try treating the binding into the aliasing-ppgtt as a
separate lockclass from the ggtt. The downside is that we are
deliberately suppressing lockdep;s ability to warn us of cycles.
Ville Syrjälä [Tue, 10 Mar 2020 20:27:52 +0000 (22:27 +0200)]
drm/i915: Get rid of silly void* from MST code
Not sure why this thing is trying to avoid declaring the proper
type for these pointers. But since these are used only once let's
just get rid of the local variable entirely.
Kai Vehmanen [Tue, 24 Mar 2020 15:32:12 +0000 (17:32 +0200)]
drm/i915: use forced codec wake on all gen9+ platforms
Commit 632f3ab95fe2 ("drm/i915/audio: add codec wakeup override
enabled/disable callback"), added logic to toggle Codec Wake on gen9.
This is used by audio driver when it resets the HDA controller.
It seems explicit toggling of the wakeline can help to fix problems
with probe failing on some gen12 platforms. And based on specs, there
is no reason why this programming sequence should not be applied to all
gen9+ platforms. No side-effects are seen on gen10/11. So apply
the wake-logic to all gen9+ platforms.
projects / users / dwmw2 / linux.git / log