OSDN Git Service
Chris Wilson [Sat, 30 Nov 2019 12:05:03 +0000 (12:05 +0000)]
drm/i915/gt: Push the flush_pd before the set-context
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 <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191130120503.1609483-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 20:13:28 +0000 (20:13 +0000)]
drm/i915/gen7: Re-enable full-ppgtt for ivb & hsw
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:
3dc007fe9b2b ("drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgtt")
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/20191129201328.1398583-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 22:27:02 +0000 (22:27 +0000)]
drm/i915/selftests: Keep engine awake during live_coherency
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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129222702.1456292-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 17:25:42 +0000 (17:25 +0000)]
drm/i915/execlists: Ensure the tasklet is decoupled upon shutdown
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 <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129172542.1222810-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 15:18:45 +0000 (15:18 +0000)]
drm/i915/gem: Take timeline->mutex to walk list-of-requests
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:
4a3174152147 ("drm/i915/gem: Refine occupancy test in kill_context()")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-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ä [Fri, 11 Oct 2019 20:09:45 +0000 (23:09 +0300)]
drm/i915: Don't set undefined bits in dirty_pipes
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011200949.7839-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Chris Wilson [Fri, 29 Nov 2019 12:48:46 +0000 (12:48 +0000)]
Revert "drm/i915: use a separate context for gpu relocs"
Since commit
c45e788d95b4 ("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:
8a9a982767b7 ("drm/i915: use a separate context for gpu relocs")
References:
c45e788d95b4 ("drm/i915/tgl: Suspend pre-parser across GTT invalidations")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129124846.949100-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 10:34:55 +0000 (10:34 +0000)]
drm/i915/selftests: Wait only on the expected barrier
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=112405
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129103455.744389-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 09:56:59 +0000 (09:56 +0000)]
drm/i915/selftests: Always lock the drm_mm around insert/remove
Be paranoid and make sure the drm_mm is locked whenever we insert/remove
our own nodes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129095659.665381-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 28 Nov 2019 23:29:46 +0000 (23:29 +0000)]
drm/i915/selftests: Use sgt_iter for huge_pages_free
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=112225
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128232946.546831-1-chris@chris-wilson.co.uk
Michel Thierry [Thu, 28 Nov 2019 02:10:05 +0000 (07:40 +0530)]
drm/i915/tgl: Implement Wa_1604555607
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: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128021005.3350-1-ramalingam.c@intel.com
Chris Wilson [Thu, 28 Nov 2019 18:54:01 +0000 (18:54 +0000)]
drm/i915/selftests: Drop local vm reference!
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 <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128185402.110678-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 27 Nov 2019 22:32:50 +0000 (22:32 +0000)]
drm/i915/selftests: Count the number of engines used
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 <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127223252.3777141-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 28 Nov 2019 10:25:46 +0000 (10:25 +0000)]
drm/i915/selftests: Try to show where the pulse went
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=112405
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128102546.3857140-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 28 Nov 2019 11:34:24 +0000 (11:34 +0000)]
drm/i915/gem: Excise the per-batch whitelist from the context
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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128113424.3885958-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 27 Nov 2019 11:58:13 +0000 (11:58 +0000)]
drm/i915/gt: Defer breadcrumb processing to after the irq handler
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 <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127115813.3345823-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 27 Nov 2019 13:45:27 +0000 (13:45 +0000)]
drm/i915: Serialise i915_active_fence_set() with itself
The expected downside to commit
58b4c1a07ada ("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:
58b4c1a07ada ("drm/i915: Reduce nested prepare_remote_context() to a trylock")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127134527.3438410-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 27 Nov 2019 09:56:57 +0000 (09:56 +0000)]
drm/i915/gt: Manual rc6 entry upon parking
Now that we rapidly park the GT when the GPU idles, we often find
ourselves idling faster than the RC6 promotion timer. Thus if we tell
the GPU to enter RC6 manually as we park, we can do so quicker (by
around 50ms, half an EI on average) and marginally increase our
powersaving across all execlists platforms.
v2: Now with a selftest to check we can enter RC6 manually
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127095657.3209854-1-chris@chris-wilson.co.uk
Clint Taylor [Thu, 21 Nov 2019 20:14:55 +0000 (12:14 -0800)]
drm/i915: Disable display interrupts during display IRQ handler
During the Display Interrupt Service routine the Display Interrupt
Enable bit must be disabled, The interrupts handled, then the
Display Interrupt Enable bit must be set to prevent possible missed
interrupts.
Bspec: 49212
V2: Change Title to remove SDE reference.
V3: Fix TAB spacing.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121201455.2558-1-clinton.a.taylor@intel.com
Kai Vehmanen [Mon, 25 Nov 2019 12:53:12 +0000 (14:53 +0200)]
drm/i915/dp: fix DP audio for PORT_A on gen12+
Starting with gen12, PORT_A can be connected to a transcoder
with audio support. Modify the existing logic that disabled
audio on PORT_A unconditionally.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125125313.17584-1-kai.vehmanen@linux.intel.com
Stanislav Lisovskiy [Mon, 25 Nov 2019 16:08:00 +0000 (18:08 +0200)]
drm/i915: Support more QGV points
According to BSpec 53998, there is a mask of
max 8 SAGV/QGV points we need to support.
Bumping this up to keep the CI happy(currently
preventing tests to run), until all SAGV
changes land.
v2: Fix second plane where QGV points were
hardcoded as well.
v3: Change the naming of I915_NUM_SAGV_POINTS
to be I915_NUM_QGV_POINTS, as more meaningful
(Ville Syrjälä)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112189
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125160800.14740-1-stanislav.lisovskiy@intel.com
[vsyrjala: Add missing braces around else (checkpatch), fix Bugzilla tag]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Chris Wilson [Tue, 26 Nov 2019 06:55:21 +0000 (06:55 +0000)]
drm/i915: Reduce nested prepare_remote_context() to a trylock
On context retiring, we may invoke the kernel_context to unpin this
context. Elsewhere, we may use the kernel_context to modify this
context. This currently leads to an AB-BA lock inversion, so we need to
back-off from the contended lock, and repeat.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111732
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes:
a9877da2d629 ("drm/i915/oa: Reconfigure contexts on the fly")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126065521.2331017-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 25 Nov 2019 16:27:37 +0000 (16:27 +0000)]
drm/i915: Default to a more lenient forced preemption timeout
Based on a sampling of a number of benchmarks across platforms, by
default opt for a much more lenient timeout so that we should not
adversely affect existing "good" clients.
640ms ought to be enough for anyone.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112169
Fixes:
3a7a92aba8fb ("drm/i915/execlists: Force preemption")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125162737.2161069-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 25 Nov 2019 12:48:56 +0000 (12:48 +0000)]
drm/i915/selftests: Move mock_vma to the heap to reduce stack_frame
An i915_vma struct on the stack may push the frame over the limit, if
set conservatively, so move it to the heap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125124856.1761176-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 25 Nov 2019 10:58:58 +0000 (10:58 +0000)]
drm/i915/gt: Schedule request retirement when timeline idles
The major drawback of commit
7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine switched over to the kernel
context. If userspace is idle, this task falls onto our background idle
worker, which only runs roughly once a second, meaning that userspace has
to have been idle for a couple of seconds before we enable RC6 again.
Naturally, this causes us to consume considerably more energy than
before as powersaving is effectively disabled while a display server
(here's looking at you Xorg) is running.
As execlists will get a completion event as each context is completed,
we can use this interrupt to queue a retire worker bound to this engine
to cleanup idle timelines. We will then immediately notice the idle
engine (without userspace intervention or the aid of the background
retire worker) and start parking the GPU. Thus during light workloads,
we will do much more work to idle the GPU faster... Hopefully with
commensurate power saving!
v2: Watch context completions and only look at those local to the engine
when retiring to reduce the amount of excess work we perform.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112315
References:
7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
References:
2248a28384fe ("drm/i915/gen8+: Add RC6 CTX corruption WA")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125105858.1718307-3-chris@chris-wilson.co.uk
Chris Wilson [Mon, 25 Nov 2019 10:58:57 +0000 (10:58 +0000)]
drm/i915/gt: Adapt engine_park synchronisation rules for engine_retire
In the next patch, we will introduce a new asynchronous retirement
worker, fed by execlists CS events. Here we may queue a retirement as
soon as a request is submitted to HW (and completes instantly), and we
also want to process that retirement as early as possible and cannot
afford to postpone (as there may not be another opportunity to retire it
for a few seconds). To allow the new async retirer to run in parallel
with our submission, pull the __i915_request_queue (that passes the
request to HW) inside the timelines spinlock so that the retirement
cannot release the timeline before we have completed the submission.
v2: Actually to play nicely with engine_retire, we have to raise the
timeline.active_lock before releasing the HW. intel_gt_retire_requsts()
is still serialised by the outer lock so they cannot see this
intermediate state, and engine_retire is serialised by HW submission.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125105858.1718307-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 25 Nov 2019 10:58:56 +0000 (10:58 +0000)]
drm/i915: Serialise with engine-pm around requests on the kernel_context
As the engine->kernel_context is used within the engine-pm barrier, we
have to be careful when emitting requests outside of the barrier, as the
strict timeline locking rules do not apply. Instead, we must ensure the
engine_park() cannot be entered as we build the request, which is
simplest by taking an explicit engine-pm wakeref around the request
construction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125105858.1718307-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 25 Nov 2019 11:25:20 +0000 (11:25 +0000)]
drm/i915/execlists: Fixup cancel_port_requests()
I rushed a last minute correction to cancel_port_requests() to prevent
the snooping of *execlists->active as the inflight array was being
updated, without noticing we iterated the inflight array starting from
active! Oops.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112387
Fixes:
331bf9059157 ("drm/i915/gt: Mark the execlists->active as the primary volatile access")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125112520.1760492-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 25 Nov 2019 09:43:18 +0000 (09:43 +0000)]
drm/i915/gt: Mark the execlists->active as the primary volatile access
Since we want to do a lockless read of the current active request, and
that request is written to by process_csb also without serialisation, we
need to instruct gcc to take care in reading the pointer itself.
Otherwise, we have observed execlists_active() to report 0x40.
[ 2400.760381] igt/para-4098 1..s. 2376479300us : process_csb: rcs0 cs-irq head=3, tail=4
[ 2400.760826] igt/para-4098 1..s. 2376479303us : process_csb: rcs0 csb[4]: status=0x00000001:0x00000000
[ 2400.761271] igt/para-4098 1..s. 2376479306us : trace_ports: rcs0: promote { b9c59:2622, b9c55:2624 }
[ 2400.761726] igt/para-4097 0d... 2376479311us : __i915_schedule: rcs0: -
2147483648->3, inflight:
0000000000000040, rq:
ffff888208c1e940
which is impossible!
The answer is that as we keep the existing execlists->active pointing
into the array as we copy over that array, the unserialised read may see
a partial pointer value.
Fixes:
df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125094318.1630806-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 25 Nov 2019 09:14:09 +0000 (09:14 +0000)]
drm/i915: Switch kunmap() to take the page not vaddr
On converting from kunmap_atomic() to kunamp() one must remember the
latter takes the struct page, the former the vaddr.
Fixes:
48715f700174 ("drm/i915: Avoid atomic context for error capture")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125091409.1630385-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 23 Nov 2019 19:15:47 +0000 (19:15 +0000)]
drm/i915/selftests: Include the subsubtest name for live_parallel_engines
Include the name of the failing subsubtest, should it fails.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191123191547.925360-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Fri, 22 Nov 2019 10:41:15 +0000 (10:41 +0000)]
drm/i915/query: Align flavour of engine data lookup
Commit
750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for
engines onto the GT") changed the engine query to iterate over uabi
engines but left the buffer size calculation look at the physical engine
count. Difference has no practical consequence but it is nicer to align
both queries.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes:
750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20191122104115.29610-1-tvrtko.ursulin@linux.intel.com
Juston Li [Fri, 11 Oct 2019 18:19:18 +0000 (11:19 -0700)]
drm/i915: coffeelake supports hdcp2.2
This includes other platforms that utilize the same gen graphics as
CFL: AML, WHL and CML.
Signed-off-by: Juston Li <juston.li@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011181918.29618-1-juston.li@intel.com
Chris Wilson [Fri, 22 Nov 2019 13:24:04 +0000 (13:24 +0000)]
drm/i915/selftests: Flush the active callbacks
Before checking the current i915_active state for the asynchronous work
we submitted, flush any ongoing callback. This ensures that our sampling
is robust and does not sporadically fail due to bad timing as the work
is running on another cpu.
v2: Drop the fence callback sync, retiring under the lock should be good
enough to synchronize with engine_retire() and the
intel_gt_retire_requests() background worker.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191122132404.690440-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 22 Nov 2019 11:21:48 +0000 (11:21 +0000)]
drm/i915/selftests: Force bonded submission to overlap
Bonded request submission is designed to allow requests to execute in
parallel as laid out by the user. If the master request is already
finished before its bonded pair is submitted, the pair were not destined
to run in parallel and we lose the information about the master engine
to dictate selection of the secondary. If the second request was
required to be run on a particular engine in a virtual set, that should
have been specified, rather than left to the whims of a random
unconnected requests!
In the selftest, I made the mistake of not ensuring the master would
overlap with its bonded pairs, meaning that it could indeed complete
before we submitted the bonds. Those bonds were then free to select any
available engine in their virtual set, and not the one expected by the
test.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191122112152.660743-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 22 Nov 2019 09:49:24 +0000 (09:49 +0000)]
drm/i915: Use a ctor for TYPESAFE_BY_RCU i915_request
As we start peeking into requests for longer and longer, e.g.
incorporating use of spinlocks when only protected by an
rcu_read_lock(), we need to be careful in how we reset the request when
recycling and need to preserve any barriers that may still be in use as
the request is reset for reuse.
Quoting Linus Torvalds:
> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
.. because the object can be accessed (by RCU) after the refcount has
gone down to zero, and the thing has been released.
That's the whole and only point of SLAB_TYPESAFE_BY_RCU.
That flag basically says:
"I may end up accessing this object *after* it has been free'd,
because there may be RCU lookups in flight"
This has nothing to do with constructors. It's ok if the object gets
reused as an object of the same type and does *not* get
re-initialized, because we're perfectly fine seeing old stale data.
What it guarantees is that the slab isn't shared with any other kind
of object, _and_ that the underlying pages are free'd after an RCU
quiescent period (so the pages aren't shared with another kind of
object either during an RCU walk).
And it doesn't necessarily have to have a constructor, because the
thing that a RCU walk will care about is
(a) guaranteed to be an object that *has* been on some RCU list (so
it's not a "new" object)
(b) the RCU walk needs to have logic to verify that it's still the
*same* object and hasn't been re-used as something else.
In contrast, a SLAB_TYPESAFE_BY_RCU memory gets free'd and re-used
immediately, but because it gets reused as the same kind of object,
the RCU walker can "know" what parts have meaning for re-use, in a way
it couidn't if the re-use was random.
That said, it *is* subtle, and people should be careful.
> So the re-use might initialize the fields lazily, not necessarily using a ctor.
If you have a well-defined refcount, and use "atomic_inc_not_zero()"
to guard the speculative RCU access section, and use
"atomic_dec_and_test()" in the freeing section, then you should be
safe wrt new allocations.
If you have a completely new allocation that has "random stale
content", you know that it cannot be on the RCU list, so there is no
speculative access that can ever see that random content.
So the only case you need to worry about is a re-use allocation, and
you know that the refcount will start out as zero even if you don't
have a constructor.
So you can think of the refcount itself as always having a zero
constructor, *BUT* you need to be careful with ordering.
In particular, whoever does the allocation needs to then set the
refcount to a non-zero value *after* it has initialized all the other
fields. And in particular, it needs to make sure that it uses the
proper memory ordering to do so.
NOTE! One thing to be very worried about is that re-initializing
whatever RCU lists means that now the RCU walker may be walking on the
wrong list so the walker may do the right thing for this particular
entry, but it may miss walking *other* entries. So then you can get
spurious lookup failures, because the RCU walker never walked all the
way to the end of the right list. That ends up being a much more
subtle bug.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191122094924.629690-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 23:30:21 +0000 (23:30 +0000)]
drm/i915/selftests: Shorten infinite wait for sseu
Use our more regular igt_flush_test() to bind the wait-for-idle and
error out instead of waiting around forever on critical failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121233021.507400-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 07:10:43 +0000 (07:10 +0000)]
drm/i915/selftests: Always hold a reference on a waited upon request
Whenever we wait on a request, make sure we actually hold a reference to
it and that it cannot be retired/freed on another CPU!
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/20191121071044.97798-4-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 13:05:28 +0000 (13:05 +0000)]
drm/i915: Mark intel_wakeref_get() as a sleeper
Assume that intel_wakeref_get() may take the mutex, and perform other
sleeping actions in the course of its callbacks and so use might_sleep()
to ensure that all callers abide. Anything that cannot sleep has to use
e.g. intel_wakeref_get_if_active() to guarantee its avoidance of the
non-atomic paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121130528.309474-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 10:35:46 +0000 (10:35 +0000)]
drm/i915/execlists: Lock the request while validating it during promotion
Since the request is already on the HW as we perform its validation, it
and even its subsequent barrier may be concurrently retired before we
process the assertions. If it is retired already and so off the HW, our
assertions become void and we need to ignore them.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112363
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121103546.146487-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 09:33:26 +0000 (09:33 +0000)]
drm/i915/gt: Hold request reference while waiting for w/a verification
As we wait upon a request, we must be holding a reference to it, and be
wary that i915_request_add() consumes the passed in reference.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121093326.134774-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 07:10:41 +0000 (07:10 +0000)]
drm/i915: Serialise with remote retirement
Since retirement may be running in a worker on another CPU, it may be
skipped in the local intel_gt_wait_for_idle(). To ensure the state is
consistent for our sanity checks upon load, serialise with the remote
retirer by waiting on the timeline->mutex.
Outside of this use case, e.g. on suspend or module unload, we expect the
slack to be picked up by intel_gt_pm_wait_for_idle() and so prefer to
put the special case serialisation with retirement in its single user,
for now at least.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121071044.97798-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 07:10:40 +0000 (07:10 +0000)]
Revert "drm/i915/gt: Wait for new requests in intel_gt_retire_requests()"
From inside an active timeline in the execbuf ioctl, we may try to
reclaim some space in the GGTT. We need GGTT space for all objects on
!full-ppgtt platforms, and for context images everywhere. However, to
free up space in the GGTT we may need to remove some pinned objects
(e.g. context images) that require flushing the idle barriers to remove.
For this we use the big hammer of intel_gt_wait_for_idle()
However, commit
7936a22dd466 ("drm/i915/gt: Wait for new requests in
intel_gt_retire_requests()") will continue spinning on the wait if a
timeline is active but lacks requests, as is the case during execbuf
reservation. Spinning forever is quite time consuming, so revert that
commit and start again.
In practice, the effect commit
7936a22dd466 was trying to achieve is
accomplished by commit
1683d24c1470 ("drm/i915/gt: Move new timelines
to the end of active_list"), so there is no immediate rush to replace
the looping.
Testcase: igt/gem_exec_reloc/basic-range
Fixes:
7936a22dd466 ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()")
References:
1683d24c1470 ("drm/i915/gt: Move new timelines to the end of active_list")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121071044.97798-1-chris@chris-wilson.co.uk
Stuart Summers [Wed, 20 Nov 2019 21:13:21 +0000 (13:13 -0800)]
drm/i915: Use intel_gt_pm_put_async in GuC submission path
GuC submission path can be called from an interrupt context
and so should use a worker to avoid holding a mutex.
References:
07779a76ee1f ("drm/i915: Mark up the calling context for intel_wakeref_put()")
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
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/20191120211321.88021-1-stuart.summers@intel.com
Chris Wilson [Wed, 20 Nov 2019 18:22:09 +0000 (18:22 +0000)]
drm/i915/gt: Fixup config ifdeffery for pm_suspend_target_state
pm_suspend_target_state is declared under CONFIG_PM_SLEEP but only
defined under CONFIG_SUSPEND. Play safe and only use the symbol if it is
both declared and defined.
Reported-by: kbuild-all@lists.01.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes:
a70a9e998e8e ("drm/i915: Defer rc6 shutdown to suspend_late")
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120182209.3967833-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 17:08:58 +0000 (17:08 +0000)]
drm/i915/gt: Declare timeline.lock to be irq-free
Now that we never allow the intel_wakeref callbacks to be invoked from
interrupt context, we do not need the irqsafe spinlock for the timeline.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120170858.3965380-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 16:55:14 +0000 (16:55 +0000)]
drm/i915/gt: Unlock engine-pm after queuing the kernel context switch
In commit
a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap with other users of the engine->kernel_context waking
up and submitting their request before the idle-switch is queued, with
the result that the kernel_context is executed out-of-sequence most
likely upsetting the GPU and certainly ourselves when we try to retire
the out-of-sequence requests.
As such we need to hold onto the effective engine->kernel_context mutex
lock (via the engine pm mutex proxy) until we have finish queuing the
request to the engine.
v2: Serialise against concurrent intel_gt_retire_requests()
v3: Describe the hairy locking scheme with intel_gt_retire_requests()
for future reference.
v4: Combine timeline->lock and engine pm release; it's hairy.
Fixes:
a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend")
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120165514.3955081-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 16:55:13 +0000 (16:55 +0000)]
drm/i915/gt: Close race between engine_park and intel_gt_retire_requests
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_context->timeline could be manipulated under the
global wakeref.mutex.
This was quite solid, as we always manipulated the timeline only while
we held an engine wakeref.
And then we started retiring requests outside of struct_mutex, only
using the timelines.active_list and the timeline->mutex. There we
started manipulating intel_timeline.active_count outside of an engine
wakeref, and so introduced a race between __engine_park() and
intel_gt_retire_requests(), a race that could result in the
engine->kernel_context not being added to the active timelines and so
losing requests, which caused us to keep the system permanently powered
up [and unloadable].
The race would be easy to close if we could take the engine wakeref for
the timeline before we retire -- except timelines are not bound to any
engine and so we would need to keep all active engines awake. The
alternative is to guard intel_timeline_enter/intel_timeline_exit for use
outside of the timeline->mutex.
Fixes:
e5dadff4b093 ("drm/i915: Protect request retirement with timeline->mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120165514.3955081-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 12:54:33 +0000 (12:54 +0000)]
drm/i915: Mark up the calling context for intel_wakeref_put()
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a worker if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normally are in process context,
we can typically use a plain mutex, and only defer to a work when we
know we are being called from an interrupt path.
Fixes:
51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref")
References:
a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in IRQ contexts")
References: https://bugs.freedesktop.org/show_bug.cgi?id=111626
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120125433.3767149-1-chris@chris-wilson.co.uk
Stuart Summers [Wed, 20 Nov 2019 01:10:16 +0000 (17:10 -0800)]
drm/i915: Do not initialize display BW when display not available
When display is not available, finding the memory bandwidth available
for display is not useful. Skip this sequence here.
References: HSDES
1209978255
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120011016.18049-1-stuart.summers@intel.com
Stuart Summers [Wed, 20 Nov 2019 00:45:05 +0000 (16:45 -0800)]
Skip MCHBAR queries when display is not available
Platforms without display do not map the MCHBAR MMIO into the GFX
device BAR. Skip this sequence when display is not available.
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120004505.149516-1-stuart.summers@intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:30 +0000 (18:44 +0200)]
drm/i915: Change .crtc_enable/disable() calling convention
Just pass the atomic state+crtc to the .crtc_enable()
.crtc_disable(). Life is easier when you don't have to think
whether to pass the old or the new crtc state.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-11-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:29 +0000 (18:44 +0200)]
drm/i915: s/pipe_config/new_crtc_state/ in .crtc_enable()
Rename pipe_config to new_crtc_state in the .crtc_enable() hooks.
The 'pipe_config' name is a zombie that we need to finally put down.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-10-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:28 +0000 (18:44 +0200)]
drm/i915: s/intel_crtc/crtc/ in .crtc_enable() and .crtc_disable()
Get rid of the horrible aliasing drm_crtc and intel_crtc variables
in the crtc enable/disable hooks.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-9-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:27 +0000 (18:44 +0200)]
drm/i915: Pass dev_priv to cpt_verify_modeset()
Get rid of the last 'dev' usage in ironlake_crtc_enable() by
passing dev_priv to cpt_verify_modeset().
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-8-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:26 +0000 (18:44 +0200)]
drm/i915: Change watermark hook calling convention
Just pass the atomic_state+crtc to the watermarks hooks. Eeasier
time for the caller when it doesn't have to think what to pass.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-7-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:25 +0000 (18:44 +0200)]
drm/i915: Pass intel_crtc to ironlake_fdi_disable()
Switch to intel_crtc from drm_crtc.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-6-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:24 +0000 (18:44 +0200)]
drm/i915: Move crtc_state to tighter scope
intel_modeset_setup_hw_state() doesn't need the crtc_state at the
top level scope. Move it to where it's needed.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-5-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:23 +0000 (18:44 +0200)]
drm/i915: Move assert_vblank_disabled() into intel_crtc_vblank_on()
Move the assert_vblank_disabled() into intel_crtc_vblank_on()
so that we don't have to inline it all over.
This does mean we now assert_vblank_disabled() during readout as well
but that is totally fine as it happens after drm_crtc_vblank_reset().
One can even argue it's what we want to do anyway to make sure
the reset actually happened.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-4-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:22 +0000 (18:44 +0200)]
drm/i915: Add intel_crtc_vblank_off()
We already have intel_crtc_vblank_on(). Add a counterpart so we
don't have to inline the disable+assert all over.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-3-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:21 +0000 (18:44 +0200)]
drm/i915: Change intel_encoders_<hook>() calling convention
Just pass the atomic state and the crtc to intel_encoders_enable() & co.
Make life simpler when you don't have to think which state (old vs. new)
you have to pass in. Also constify the states while at it.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-2-ville.syrjala@linux.intel.com
Jani Nikula [Wed, 20 Nov 2019 13:54:37 +0000 (15:54 +0200)]
Merge tag 'topic/drm-mipi-dsi-dsc-updates-2019-11-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next-queued
Core Changes:
- Update DSI data type and command definitions
- Add helpers for sending compression mode and PPS packets
Driver Changes:
- Update tiny/st7586 to reflect a definition change
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87tv7a4eq3.fsf@intel.com
Chris Wilson [Wed, 20 Nov 2019 10:27:41 +0000 (10:27 +0000)]
drm/i915/selftests: Take a ref to the request we wait upon
i915_request_add() consumes the passed in reference to the i915_request,
so if the selftest caller wishes to wait upon it afterwards, it needs to
take a reference for itself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120102741.3734346-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 09:33:01 +0000 (09:33 +0000)]
drm/i915/selftests: Be explicit in ERR_PTR handling
When setting up a full GGTT, we expect the next insert to fail with
-ENOSPC. Simplify the use of ERR_PTR to not confuse either the reader or
smatch.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
References:
f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120093302.3723715-8-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 15:47:23 +0000 (15:47 +0000)]
drm/i915/selftests: Exercise rc6 w/a handling
Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
possible rc6 context corruption. Poke at the bear!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Tested-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119154723.3311814-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 18 Nov 2019 23:02:46 +0000 (23:02 +0000)]
drm/i915: Wait until the intel_wakeref idle callback is complete
When waiting for idle, serialise with any ongoing callback so that it
will have completed before completing the wait.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-12-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 10:09:13 +0000 (10:09 +0000)]
drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
Since igt now defaults to not enabling ftrace-on-oops, we need to
manually invoke GEM_TRACE_DUMP() to see the debug log prior to a
GEM_BUG_ON panicking.
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/20191119100929.2628356-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 18 Nov 2019 23:02:50 +0000 (23:02 +0000)]
drm/i915/gt: Flush the requests after wedging on suspend
Retire all requests if we resort to wedged the driver on suspend. They
will now be idle, so we might as we free them before shutting down.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-16-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 16:25:59 +0000 (16:25 +0000)]
drm/i915/gt: Schedule next retirement worker first
As we may park the gt during request retirement, we may cancel the
retirement worker only to then program the delayed worker once more.
If we schedule the next delayed retirement worker first, if we then park
the gt, the work will remain cancelled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119162559.3313003-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 16:25:58 +0000 (16:25 +0000)]
drm/i915/gt: Move new timelines to the end of active_list
When adding a new active timeline, place it at the end of the list. This
allows for intel_gt_retire_requests() to pick up the newcomer more
quickly and hopefully complete the retirement sooner. A miniscule
optimisation.
References:
7936a22dd466 ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119162559.3313003-1-chris@chris-wilson.co.uk
Matthew Auld [Tue, 19 Nov 2019 15:01:54 +0000 (15:01 +0000)]
drm/i915: make pool objects read-only
For our current users we don't expect pool objects to be writable from
the gpu.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes:
4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow buffers")
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/20191119150154.18249-1-matthew.auld@intel.com
Matt Roper [Mon, 18 Nov 2019 18:02:19 +0000 (10:02 -0800)]
drm/i915/tgl: Add DKL PHY vswing table for HDMI
The bspec initially provided a single DKL PHY vswing table for both HDMI
and DP, but was recently updated to include an independent table for
HDMI.
Bspec: 49292
Fixes:
978c3e539be2 ("drm/i915/tgl: Add dkl phy programming sequences")
Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118180219.9309-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Vandita Kulkarni [Tue, 19 Nov 2019 07:20:04 +0000 (12:50 +0530)]
drm/i915/dsi: Do not read the transcoder register.
As per the Bspec, port mapping is fixed for mipi dsi.
v2: Reuse the existing function (Jani)
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119072004.4093-1-vandita.kulkarni@intel.com
Chris Wilson [Tue, 19 Nov 2019 10:09:20 +0000 (10:09 +0000)]
drm/i915/gem: Protect the obj->vma.list during iteration
Take the obj->vma.lock to prevent modifications to the list as we
iterate, to avoid the dreaded NULL pointer.
<1>[ 347.820823] BUG: kernel NULL pointer dereference, address:
0000000000000150
<1>[ 347.820856] #PF: supervisor read access in kernel mode
<1>[ 347.820874] #PF: error_code(0x0000) - not-present page
<6>[ 347.820892] PGD 0 P4D 0
<4>[ 347.820908] Oops: 0000 [#1] PREEMPT SMP NOPTI
<4>[ 347.820926] CPU: 3 PID: 1303 Comm: gem_persistent_ Tainted: G U 5.4.0-rc7-CI-CI_DRM_7352+ #1
<4>[ 347.820956] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018
<4>[ 347.821132] RIP: 0010:i915_gem_object_flush_write_domain+0xd9/0x1d0 [i915]
<4>[ 347.821157] Code: 0f 84 e9 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 75 11 e9 ed 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 74 26 48 8b 83 b0 00 00 00 <48> 8b b8 50 01 00 00 e8 fb 20 fb ff 48 8b 83 30 03 00 00 49 39 c4
<4>[ 347.821210] RSP: 0018:
ffffc90000a1f8f8 EFLAGS:
00010202
<4>[ 347.821229] RAX:
0000000000000000 RBX:
ffffc900008479a0 RCX:
0000000000000018
<4>[ 347.821252] RDX:
0000000000000000 RSI:
000000000000000d RDI:
ffff888275a090b0
<4>[ 347.821274] RBP:
ffff8882673c8040 R08:
ffff88825991b8d0 R09:
0000000000000000
<4>[ 347.821297] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff8882673c8280
<4>[ 347.821319] R13:
ffff8882673c8368 R14:
0000000000000000 R15:
ffff888266a54000
<4>[ 347.821343] FS:
00007f75865f4240(0000) GS:
ffff888277b80000(0000) knlGS:
0000000000000000
<4>[ 347.821368] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4>[ 347.821389] CR2:
0000000000000150 CR3:
000000025aee0000 CR4:
00000000003406e0
<4>[ 347.821411] Call Trace:
<4>[ 347.821555] i915_gem_object_prepare_read+0xea/0x2a0 [i915]
<4>[ 347.821706] intel_engine_cmd_parser+0x5ce/0xe90 [i915]
<4>[ 347.821834] ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
<4>[ 347.821990] i915_gem_do_execbuffer+0xb4c/0x2550 [i915]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119100929.2628356-8-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 10:09:18 +0000 (10:09 +0000)]
drm/i915/gem: Merge GGTT vma flush into a single loop
We only need the one loop to find the dirty vma flush them and their
chipset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119100929.2628356-6-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 11:25:15 +0000 (11:25 +0000)]
drm/i915/gem: Track ggtt writes from userspace on the bound vma
When userspace writes into the GTT itself, it is supposed to call
set-domain to let the kernel keep track and so manage the CPU/GPU
caches. As we track writes on the individual i915_vma, we should also be
sure to mark them as dirty.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119112515.2766748-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 18 Nov 2019 23:02:40 +0000 (23:02 +0000)]
drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint
In order to avoid some nasty mutex inversions, commit
09c5ab384f6f
("drm/i915: Keep rings pinned while the context is active") allowed the
intel_ring unpinning to be run concurrently with the next context
pinning it. Thus each step in intel_ring_unpin() needed to be atomic and
ordered in a nice onion with intel_ring_pin() so that the lifetimes
overlapped and were always safe.
Sadly, a few steps in intel_ring_unpin() were overlooked, such as
closing the read/write pointers of the ring and discarding the
intel_ring.vaddr, as these steps were not serialised with
intel_ring_pin() and so could leave the ring in disarray.
Fixes:
09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active")
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-6-chris@chris-wilson.co.uk
Chris Wilson [Mon, 18 Nov 2019 18:49:33 +0000 (18:49 +0000)]
drm/i915/gt: Only wait for register chipset flush if active
Only serialise with the chipset using an mmio if the chipset is
currently active. We expect that any writes into the chipset range will
simply be forgotten until it wakes up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118184943.2593048-8-chris@chris-wilson.co.uk
Matt Roper [Mon, 18 Nov 2019 16:44:12 +0000 (08:44 -0800)]
drm/i915/ehl: Update voltage level checks
The bspec was recently updated with new cdclk -> voltage level tables to
accommodate the new 324/326.4 cdclk values.
Bspec: 21809
Fixes:
63c9dae71dc5 ("drm/i915/ehl: Add voltage level requirement table")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164412.26216-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Lucas De Marchi [Mon, 11 Nov 2019 20:50:25 +0000 (12:50 -0800)]
drm/i915/dsb: fix extra warning on error path handling
When we call intel_dsb_get(), the dsb initialization may fail for
various reasons. We already log the error message in that path, making
it unnecessary to trigger a warning that refcount == 0 when calling
intel_dsb_put().
So here we simplify the logic and do lazy shutdown: leaving the extra
refcount alive so when we call intel_dsb_put() we end up calling
i915_vma_unpin_and_release().
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111205024.22853-3-lucas.demarchi@intel.com
Lucas De Marchi [Sat, 16 Nov 2019 01:15:39 +0000 (17:15 -0800)]
drm/i915/dsb: remove atomic operations
The current dsb API is not really prepared to handle multithread access.
I was debugging an issue that ended up fixed by commit
a096883dda2c
("drm/i915/dsb: Remove PIN_MAPPABLE from the DSB object VMA") and was
puzzled how these atomic operations were guaranteeing atomicity.
if (atomic_add_return(1, &dsb->refcount) != 1)
return dsb;
Thread A could still be initializing dsb struct (and even fail in the
middle) while thread B would take a reference and use it (even
derefencing a NULL cmd_buf).
I don't think the atomic operations here will help much if this were
to support multithreaded scenario in future, so just remove them to
avoid confusion.
v2: Use refcount++ != 0 instead of ++refcount != 1 (from Ville)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111205024.22853-2-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20191116011539.18230-1-lucas.demarchi@intel.com
José Roberto de Souza [Fri, 15 Nov 2019 20:04:30 +0000 (12:04 -0800)]
drm/i915/mst: Check uapi enable not intel one during mst atomic check
When the connector has VCPI allocated and is being moved to another
pipe it causes drm_dp_atomic_release_vcpi_slots() and
drm_dp_atomic_find_vcpi_slots() to be called in the same atomic check
causing the error bellow.
This happens because at this point Intel's hw.enable(and all other
flags in the same struct) is not set but checking to on the uapi one
it have the expected value.
[ 580.804430] ------------[ cut here ]------------
[ 580.804436] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180
[ 580.804439] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers]
[ 580.804462] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G W 5.4.0-rc7-zeh+ #1226
[ 580.804465] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.
1909250226 09/25/2019
[ 580.804470] Workqueue: events output_poll_execute
[ 580.804476] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180
[ 580.804481] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02
[ 580.804484] RSP: 0018:
ffffc900009b7ab8 EFLAGS:
00010246
[ 580.804488] RAX:
ffff88848c04ef50 RBX:
ffff88848c04ef40 RCX:
0000000000000214
[ 580.804492] RDX:
ffff88848c04f5e0 RSI:
ffff888486eb2c68 RDI:
ffff88848e518800
[ 580.804495] RBP:
ffff88849d339000 R08:
00000000bc4e1092 R09:
0000000000000000
[ 580.804498] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff88848c04e728
[ 580.804501] R13:
0000000000000214 R14:
ffff88848c04e720 R15:
ffff888486eb2c68
[ 580.804504] FS:
0000000000000000(0000) GS:
ffff8884a0000000(0000) knlGS:
0000000000000000
[ 580.804507] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 580.804510] CR2:
00007ff6bf1ba680 CR3:
0000000005210003 CR4:
0000000000760ef0
[ 580.804512] PKRU:
55555554
[ 580.804515] Call Trace:
[ 580.804574] intel_dp_mst_compute_config+0x193/0x2b0 [i915]
[ 580.804636] intel_atomic_check+0x10cc/0x20b0 [i915]
[ 580.804644] ? drm_atomic_print_old_state+0xf1/0x130
[ 580.804655] drm_atomic_check_only+0x56a/0x810
[ 580.804663] drm_atomic_commit+0xe/0x50
[ 580.804668] drm_client_modeset_commit_atomic+0x18b/0x220
[ 580.804680] drm_client_modeset_commit_force+0x4d/0x180
[ 580.804685] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[ 580.804689] drm_fb_helper_set_par+0x27/0x50
[ 580.804692] drm_fb_helper_hotplug_event.part.0+0xa7/0xc0
[ 580.804696] drm_kms_helper_hotplug_event+0x21/0x30
[ 580.804699] output_poll_execute+0x1a4/0x1c0
[ 580.804706] process_one_work+0x25b/0x5b0
[ 580.804713] worker_thread+0x4b/0x3b0
[ 580.804720] kthread+0x100/0x140
[ 580.804723] ? process_one_work+0x5b0/0x5b0
[ 580.804725] ? kthread_park+0x80/0x80
[ 580.804730] ret_from_fork+0x24/0x50
[ 580.804740] irq event stamp: 40988
[ 580.804743] hardirqs last enabled at (40987): [<
ffffffff81128567>] console_unlock+0x437/0x590
[ 580.804746] hardirqs last disabled at (40988): [<
ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20
[ 580.804749] softirqs last enabled at (40972): [<
ffffffff81c00389>] __do_softirq+0x389/0x47f
[ 580.804752] softirqs last disabled at (40959): [<
ffffffff810b6f19>] irq_exit+0xa9/0xc0
[ 580.804754] ---[ end trace
80052e0c60463c67 ]---
[ 580.804758] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:
000000007880692e] in the same state
[ 580.811370] [drm:intel_dp_hpd_pulse [i915]] got esi2 02 00 00
[ 580.817239] [drm:intel_dp_hpd_pulse [i915]] got esi 02 00 00
[ 580.817313] ------------[ cut here ]------------
[ 580.817318] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180
[ 580.817321] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal
[ 580.817412] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on [ENCODER:306:DDI E] - short
[ 580.817413] usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul
[ 580.817490] [drm:intel_dp_hpd_pulse [i915]] is_mst
[ 580.817491] mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers]
[ 580.817498] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G W 5.4.0-rc7-zeh+ #1226
[ 580.817503] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.
1909250226 09/25/2019
[ 580.817506] Workqueue: events output_poll_execute
[ 580.817511] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180
[ 580.817514] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02
[ 580.817516] RSP: 0018:
ffffc900009b7ab8 EFLAGS:
00010246
[ 580.817519] RAX:
ffff88848c04ef50 RBX:
ffff88848c04ef40 RCX:
000000000000018f
[ 580.817521] RDX:
ffff88848c04f5e0 RSI:
ffff888486eb2c68 RDI:
ffff88848e518800
[ 580.817523] RBP:
ffff88849d339000 R08:
00000000bc4e1092 R09:
0000000000000000
[ 580.817525] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff88848c04e728
[ 580.817528] R13:
000000000000018f R14:
ffff88848c04e720 R15:
ffff888486eb2c68
[ 580.817532] FS:
0000000000000000(0000) GS:
ffff8884a0000000(0000) knlGS:
0000000000000000
[ 580.817534] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 580.817535] CR2:
00007ff6bf1ba680 CR3:
0000000005210003 CR4:
0000000000760ef0
[ 580.817537] PKRU:
55555554
[ 580.817538] Call Trace:
[ 580.817620] intel_dp_mst_compute_config+0x193/0x2b0 [i915]
[ 580.817690] intel_atomic_check+0x10cc/0x20b0 [i915]
[ 580.817697] ? drm_atomic_print_old_state+0xf1/0x130
[ 580.817711] drm_atomic_check_only+0x56a/0x810
[ 580.817721] drm_atomic_commit+0xe/0x50
[ 580.817726] drm_client_modeset_commit_atomic+0x18b/0x220
[ 580.817744] drm_client_modeset_commit_force+0x4d/0x180
[ 580.817751] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[ 580.817756] drm_fb_helper_set_par+0x27/0x50
[ 580.817762] drm_fb_helper_hotplug_event.part.0+0xa7/0xc0
[ 580.817767] drm_kms_helper_hotplug_event+0x21/0x30
[ 580.817771] output_poll_execute+0x1a4/0x1c0
[ 580.817780] process_one_work+0x25b/0x5b0
[ 580.817791] worker_thread+0x4b/0x3b0
[ 580.817800] kthread+0x100/0x140
[ 580.817804] ? process_one_work+0x5b0/0x5b0
[ 580.817807] ? kthread_park+0x80/0x80
[ 580.817813] ret_from_fork+0x24/0x50
[ 580.817832] irq event stamp: 41028
[ 580.817838] hardirqs last enabled at (41027): [<
ffffffff81128567>] console_unlock+0x437/0x590
[ 580.817841] hardirqs last disabled at (41028): [<
ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20
[ 580.817846] softirqs last enabled at (41022): [<
ffffffff81c00389>] __do_softirq+0x389/0x47f
[ 580.817851] softirqs last disabled at (41013): [<
ffffffff810b6f19>] irq_exit+0xa9/0xc0
[ 580.817854] ---[ end trace
80052e0c60463c68 ]---
[ 580.817858] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:
000000007880692e] in the same state
[ 580.830767] [drm:intel_dp_mst_compute_config [i915]] failed finding vcpi slots:-22
[ 580.830821] [drm:intel_atomic_check [i915]] Encoder config failure: -22
Cc: Lyude Paul <lyude@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115200430.53146-1-jose.souza@intel.com
Matt Roper [Fri, 15 Nov 2019 16:51:32 +0000 (08:51 -0800)]
drm/i915/vbt: Handle generic DTD block
VBT revision 229 adds a new "Generic DTD" block 58 and deprecates the
old LFP panel mode data in block 42. Let's start parsing this block to
fill in the panel fixed mode on devices with a >=229 VBT.
v2:
* Update according to the recent updates:
- DTD size is now 16 bits instead of 24
- polarity is now just a single bit for hsync and vsync and is
properly documented
* Minor checkpatch fix
v3:
* Now that panel options are parsed separately from the previous patch,
move generic DTD parsing into a function parallel to
parse_lfp_panel_dtd. We'll still fall back to looking at the legacy
LVDS timing block if the generic DTD fails. (Jani)
* Don't forget to actually set lfp_lvds_vbt_mode! (Jani)
* Drop "bdb_" prefix from dtd entry structure. (Jani)
* Follow C99 standard for structure's flexible array member. (Jani)
v4:
* Add "positive" to polarity field names for clarity. (Jani)
* Move VBT version check and fallback to legacy DTD parsing logic to a
helper to keep top-level VBT parsing uncluttered. (Jani)
* Restructure reserved bit packing at end of generic_dtd_entry from
"u32 rsvd:24" to "u8 rsvd[3]" to prevent copy/paste mistakes in the
future. (Jani)
Bspec: 54751
Bspec: 20148
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-3-matthew.d.roper@intel.com
Matt Roper [Fri, 15 Nov 2019 16:51:31 +0000 (08:51 -0800)]
drm/i915/vbt: Parse panel options separately from timing data
Newer VBT versions will add an alternate way to read panel DTD
information, so let's split parsing of the general panel information
from the timing data in preparation.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jesse Barnes <jsbarnes@google.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-2-matthew.d.roper@intel.com
Chris Wilson [Mon, 18 Nov 2019 09:43:42 +0000 (09:43 +0000)]
drm/i915/selftests: Add intel_gt_driver_late_release for mock device
Having called intel_gt_init_early() to setup the mock intel_gt, we need
to call the corresponding intel_gt_driver_late_release() to clean up.
References:
dea397e818b1 ("drm/i915/gt: Flush retire.work timer object on unload")
References:
24635c5152af ("drm/i915: Move intel_gt initialization to a separate file")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118094342.2193485-1-chris@chris-wilson.co.uk
Jani Nikula [Fri, 15 Nov 2019 12:04:40 +0000 (14:04 +0200)]
drm/i915: fix accidental static variable use
It's supposed to be just a const pointer.
Fixes:
074c77e3ec63 ("drm/i915/tgl: Gen-12 display loses Yf tiling and legacy CCS support")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115120440.17883-1-jani.nikula@intel.com
Don Hiatt [Fri, 15 Nov 2019 23:15:38 +0000 (15:15 -0800)]
drm/i915/guc: Skip suspend/resume GuC action on platforms w/o GuC submission
On some platforms (e.g. KBL) that do not support GuC submission, but
the user enabled the GuC communication (e.g for HuC authentication)
calling the GuC EXIT_S_STATE action results in lose of ability to
enter RC6. We can remove the GuC suspend/resume entirely as we do
not need to save the GuC submission status.
Add intel_guc_submission_is_enabled() function to determine if
GuC submission is active.
v2: Do not suspend/resume the GuC on platforms that do not support
Guc Submission.
v3: Fix typo, move suspend logic to remove goto.
v4: Use intel_guc_submission_is_enabled() to check GuC submission
status.
v5: No need to look at engine to determine if submission is enabled.
Squash fix + intel_guc_submission_is_enabled() patch into one.
v6: Move resume check into intel_guc_resume() for symmetry.
Fix commit Fixes tag.
Reported-by: KiteStramuort <kitestramuort@autistici.org>
Reported-by: S. Zharkoff <s.zharkoff@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111623
Fixes:
ffd5ce22faa4 ("drm/i915/guc: Updates for GuC 32.0.3 firmware")
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceralo Spurio <daniele.ceraolospurio@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomas Janousek <tomi@nomi.cz>
Signed-off-by: Don Hiatt <don.hiatt@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/20191115231538.1249-1-don.hiatt@intel.com
Chris Wilson [Fri, 15 Nov 2019 17:08:35 +0000 (17:08 +0000)]
drm/i915/gem: Purge the sudden reappearance of i915_gem_object_pin()
This died many years ago as we now use i915_vma first and foremost.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115170835.1367869-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 15 Nov 2019 12:23:43 +0000 (12:23 +0000)]
drm/i915/gt: Mention which device failed
When telling the user that device power management is disabled, it is
helpful to say which device that was.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115122343.821331-1-chris@chris-wilson.co.uk
Ville Syrjälä [Thu, 24 Oct 2019 12:21:38 +0000 (15:21 +0300)]
drm/i915: Fix frame start delay programming
Currently we're blindly poking at the frame start delay bits
in PIPECONF when trying to sanitize the hardware state. Those
bits decided to move elsewhere on HSW, so on many platforms
we're not doing anything at all here. Also we're forgetting
about the PCH transcoder entirely.
Add all the bit definitions for the various homes these bits
have had throughout the years, and reset them all to zero.
However I'm not entirely sure this is a safe thing to do. If
not I guess we'd want full readout+statecheck for this stuff.
For now let's stick to the current logic and hope for the
best.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024122138.25065-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Chris Wilson [Fri, 15 Nov 2019 15:08:40 +0000 (15:08 +0000)]
drm/i915/selftests: Disable heartbeat around context barrier tests
As the heartbeat has the effect of flushing context barriers, this
interferes with the context barrier tests that are trying to observe
them directly. Disable the heartbeat so that the barriers are as
predictable as the test demands.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115150841.880349-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 14 Nov 2019 22:57:35 +0000 (22:57 +0000)]
drm/i915/selftests: Exercise long preemption chains
Verify that we can execute a long chain of dependent requests from
userspace, each one slightly more important than the last.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114225736.616885-4-chris@chris-wilson.co.uk
Lionel Landwerlin [Thu, 14 Nov 2019 14:02:24 +0000 (16:02 +0200)]
drm/i915/perf: Add preemption check while waiting for OA
While we're waiting for the OA configuration to apply, let's give a
chance to other contexts that might need to run other workloads.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
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/20191114140224.21818-1-lionel.g.landwerlin@intel.com
Chris Wilson [Fri, 15 Nov 2019 15:08:39 +0000 (15:08 +0000)]
drm/i915/gt: Flush retire.work timer object on unload
We need to wait until the timer object is marked as deactivated before
unloading, so follow up our gentle cancel_delayed_work() with the
synchronous variant to ensure it is flushed off a remote cpu before we
mark the memory as freed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111994
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115150841.880349-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 15 Nov 2019 11:48:00 +0000 (11:48 +0000)]
drm/i915/gt: Use gt locals for accessing rc6
RC6 is tracked underneath the intel_gt, so use our local pointers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115114800.725061-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 15 Nov 2019 12:27:55 +0000 (12:27 +0000)]
drm/i915: Simplify NEEDS_WaRsDisableCoarsePowerGating
It applies to all gen9 and gen10 now, so we can use a single test
against the gen bitmask.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115122755.830355-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 14 Nov 2019 22:57:36 +0000 (22:57 +0000)]
drm/i915/gem: Silence sparse for RCU protection inside the constructor
Inside the constructor, while cloning, we need to replace the
dst->engines. Having forgotten that dst->engines is marked as RCU
protected, we need to add the appropriate annotations to make sparse
happy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114225736.616885-5-chris@chris-wilson.co.uk
Chris Wilson [Thu, 14 Nov 2019 22:57:32 +0000 (22:57 +0000)]
drm/i915/gt: Wait for new requests in intel_gt_retire_requests()
Our callers fall into two categories, those passing timeout=0 who just
want to flush request retirements and those passing a timeout that need
to wait for submission completion (e.g. intel_gt_wait_for_idle()).
Currently, we only wait for a snapshot of timelines at the start of the
wait (but there was an expectation that new requests would cause timelines
to appear at the end). However, our callers, such as
intel_gt_wait_for_idle() before suspend, do require us to wait for the
power management requests emitted by retirement as well. If we don't,
then it takes an extra second or two for the background worker to flush
the queue and mark the GT as idle.
Fixes:
7e8057626640 ("drm/i915: Drop struct_mutex from around i915_retire_requests()")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114225736.616885-1-chris@chris-wilson.co.uk
Jani Nikula [Fri, 15 Nov 2019 11:17:39 +0000 (13:17 +0200)]
Merge drm/drm-next into drm-intel-next-queued
Backmerge to get
dfce90259d74 ("Backmerge i915 security patches from
commit '
ea0b163b13ff' into drm-next") and thus
100d46bd72ec ("Merge
Intel Gen8/Gen9 graphics fixes from Jon Bloomfield.").
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Dave Airlie [Fri, 15 Nov 2019 02:34:39 +0000 (12:34 +1000)]
Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next
Two minor cleanups / fixes for -next.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m=20=28VMware=29?=
Link: https://patchwork.freedesktop.org/patch/msgid/20191114131703.8607-1-thomas_os@shipmail.org