Lionel Landwerlin [Sat, 12 Oct 2019 07:23:07 +0000 (08:23 +0100)]
drm/i915/perf: implement active wait for noa configurations
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should be over the required amount of
time (according to HW architects).
v2: Don't forget to save/restore registers used for the wait (Chris)
v3: Name used CS_GPR registers (Chris)
Fix compile issue due to rebase (Lionel)
v4: Fix save/restore helpers (Umesh)
v5: Move noa_wait from drm_i915_private to i915_perf_stream (Lionel)
v6: Add missing struct declarations in i915_perf.h
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@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/20191012072308.30312-2-chris@chris-wilson.co.uk
Lionel Landwerlin [Sat, 12 Oct 2019 07:23:06 +0000 (08:23 +0100)]
drm/i915/perf: allow for CS OA configs to be created lazily
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particular user batchbuffer be
executed with a given OA configuration.
This mechanism essentially allows the userspace driver to go through
several OA configuration without having to open/close the i915/perf
stream.
v2: No need for locking on object OA config object creation (Chris)
Flush cpu mapping of OA config (Chris)
v3: Properly deal with the perf_metric lock (Chris/Lionel)
v4: Fix oa config unref/put when not found (Lionel)
v5: Allocate BOs for configurations on the stream instead of globally
(Lionel)
v6: Fix 64bit division (Chris)
v7: Store allocated config BOs into the stream (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@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/20191012072308.30312-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 12 Oct 2019 07:01:36 +0000 (08:01 +0100)]
drm/i915: Mark up "sentinel" requests
Sometimes we want to emit a terminator request, a request that flushes
the pipeline and allows no request to come after it. This can be used
for a "preempt-to-idle" to ensure that upon processing the
context-switch to that request, all other active contexts have been
flushed.
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/20191012070136.32058-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 11 Oct 2019 19:03:25 +0000 (20:03 +0100)]
drm/i915/execlists: Prevent merging requests with conflicting flags
We set out-of-bound parameters inside the i915_requests.flags field,
such as disabling preemption or marking the end-of-context. We should
not coalesce consecutive requests if they have differing instructions
as we only inspect the last active request in a context. Thus if we
allow a later request to be merged into the same execution context, it
will mask any of the earlier flags.
References:
2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a request")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011190325.10979-9-chris@chris-wilson.co.uk
Chris Wilson [Fri, 11 Oct 2019 19:03:17 +0000 (20:03 +0100)]
drm/i915/perf: Replace global wakeref tracking with engine-pm
As we now have a specific engine to use OA on, exchange the top-level
runtime-pm wakeref with the engine-pm. This still results in the same
top-level runtime-pm, but with more nuances to keep the engine and its
gt awake.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011190325.10979-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 11 Oct 2019 19:36:20 +0000 (20:36 +0100)]
drm/i915/selftests: Serialise write to scratch with its vma binding
Add the missing serialisation on the request for a write into a vma to
wait until that vma is bound before being executed by the GPU.
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/20191011193620.14026-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 11 Oct 2019 17:38:23 +0000 (18:38 +0100)]
drm/i915: Add an rcu_barrier option to i915_drop_caches
Sometimes a test has to wait for RCU to complete a grace period and
perform its callbacks, for example waiting for a close(fd) to actually
perform the fput(filp) and so trigger all the callbacks such as closing
GEM contexts. There is no trivial means of triggering an RCU barrier
from userspace, so add one for our convenience in
debugfs/i915_drop_caches
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011173823.20432-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 11 Oct 2019 10:33:45 +0000 (11:33 +0100)]
drm/i915/execlists: Only mark incomplete requests as -EIO on cancelling
Only the requests that have not completed do we want to change the
status of to signal the -EIO when cancelling the inflight set of requests
upon wedging.
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
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/20191011103345.26013-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 10 Oct 2019 07:14:26 +0000 (08:14 +0100)]
drm/i915/execlists: Leave tell-tales as to why pending[] is bad
Before we BUG out with bad pending state, leave a telltale as to which
test failed.
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/20191010071434.31195-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 10 Oct 2019 07:14:25 +0000 (08:14 +0100)]
drm/i915: Note the addition of timeslicing to the pretend scheduler
Since writing the comment that the scheduler is entirely passive, we've
added minimal timeslicing which adds the most primitive of active
elements (a timeout and reschedule).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010071434.31195-1-chris@chris-wilson.co.uk
James Ausmus [Wed, 9 Oct 2019 17:23:15 +0000 (10:23 -0700)]
drm/i915/tgl: Read SAGV block time from PCODE
Starting from TGL, we now need to read the SAGV block time via a PCODE
mailbox, rather than having a static value.
BSpec: 49326
v2: Fix up pcode val data type (Ville), tighten variable scope (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004221449.1317-2-james.ausmus@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20191009172315.11004-2-lucas.demarchi@intel.com
James Ausmus [Wed, 9 Oct 2019 17:23:14 +0000 (10:23 -0700)]
drm/i915: Move SAGV block time to dev_priv
In prep for newer platforms having more complicated ways to determine
the SAGV block time, move the variable to dev_priv, and extract the
setting to an initial setup function. While we're at it, update the if
ladder to follow the new gen -> old gen order preference, and warn on
any non-specified gen.
v2: Shorten the function name (Ville), return directly (Ville), move
sagv_block_time_us value to dev_priv (Ville)
v3: Change sagv_block_time_us to u32 (Lucas), Change fallback value to
-1 (Lucas), use intel_has_sagv for setup check rather than hand-rolling
(Lucas)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004221449.1317-1-james.ausmus@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20191009172315.11004-1-lucas.demarchi@intel.com
Chris Wilson [Thu, 10 Oct 2019 15:05:20 +0000 (16:05 +0100)]
drm/i915/perf: Store shortcut to intel_uncore
Now that we have the engine stored in i915_perf, we have a means of
accessing intel_gt should we require it. However, we are currently only
using the intel_gt to find the right intel_uncore, so replace our
i915_perf.gt pointer with the more useful i915_perf.uncore.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010150520.26488-2-chris@chris-wilson.co.uk
Lionel Landwerlin [Thu, 10 Oct 2019 15:05:19 +0000 (16:05 +0100)]
drm/i915/perf: store the associated engine of a stream
We'll use this information later to verify that a client trying to
reconfigure the stream does so on the right engine. For now, we want to
pull the knowledge of which engine we use into a central property.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@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/20191010150520.26488-1-chris@chris-wilson.co.uk
Maarten Lankhorst [Fri, 4 Oct 2019 11:34:54 +0000 (13:34 +0200)]
drm/i915: Remove cursor use of properties for coordinates
We have a src and dect rectangle, use it instead of relying on
the core drm properties.
Because the core by default clips the src/dst properties, after
the drm_atomic_helper_check_plane_state() we manually set the
unclipped src/dst rectangles. We still need the call for
visibility checks, but this way we are able to use the src/dst
rects in the check/commit code.
This removes the special case in the watermark code for cursor w/h.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004113514.17064-5-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[mlankhorst: Clarify commit message to state we use unclipped src/dst
Maarten Lankhorst [Fri, 4 Oct 2019 11:34:56 +0000 (13:34 +0200)]
drm/i915: Remove begin/finish_crtc_commit, v4.
This can all be done from the intel_update_crtc function. Split out the
pipe update into a separate function, just like is done for the planes.
Pull in all the changes done during fastset as well. It makes no sense
for it to still exist as a separate function.
Changes since v1:
- Inline intel_update_pipe_config()
Changes since v2:
- Add comments suggested by matt.
- Reorder commit_pipe_config() to remove all nesting. (Ville, Matt)
- Use intel_set_pipe_src_size((). (Matt)
Changes since v3:
- Move atomic_update_watermarks closer to the plane calls.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004113514.17064-7-maarten.lankhorst@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
[mlankhorst: Replace 8 spaces with tabs in comment]
Maarten Lankhorst [Fri, 4 Oct 2019 11:34:55 +0000 (13:34 +0200)]
drm/i915: Use intel_plane_state in prepare and cleanup plane_fb
We need to look at the hw fb in the plane split, so replace all the places
that use drm_plane_state with intel_plane_state.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004113514.17064-6-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[mlankhorst: Fix line wraps (Matt Roper)]
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Maarten Lankhorst [Fri, 4 Oct 2019 11:34:53 +0000 (13:34 +0200)]
drm/i915: Introduce and use intel_atomic_crtc_state_for_each_plane_state.
Instead of looking at drm_plane_state, look at intel_plane_state directly.
This will allow us to make the watermarks bigjoiner aware, when we make it
work for bigjoiner slave pipes as well.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004113514.17064-4-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Maarten Lankhorst [Fri, 4 Oct 2019 11:34:52 +0000 (13:34 +0200)]
drm/i915: Fix for_each_intel_plane_mask definition
Using for_each_intel_plane_mask() fails because of an extra bracket,
remove the bracket so we can use it in the next commit.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004113514.17064-3-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Chris Wilson [Thu, 10 Oct 2019 11:02:52 +0000 (12:02 +0100)]
drm/i915/selftests: Check that registers are preserved between virtual engines
Make sure that we copy across the registers from one engine to the next,
as we hop around a virtual engine.
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/20191010110252.17289-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 10 Oct 2019 08:32:42 +0000 (09:32 +0100)]
drm/i915/execlists: Mark up expected state during reset
Move the BUG_ON around slightly and add some explanations for each to
try and capture the expected state more carefully. We want to compare
the expected active state of our bookkeeping as compared to the tracked
HW state.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111937
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/20191010083242.1387-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 2 Oct 2019 16:00:34 +0000 (17:00 +0100)]
drm/i915/gt: Warn CI about an unrecoverable wedge
If we have a wedged GPU that we need to recover, but fail, add a taint
for CI to pickup and schedule a reboot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002160034.5121-1-chris@chris-wilson.co.uk
Daniele Ceraolo Spurio [Wed, 9 Oct 2019 23:04:24 +0000 (16:04 -0700)]
drm/i915/tgl: simplify the lrc register list for !RCS
There are small differences between the blitter and the video engines in
the xcs context image (e.g. registers 0x200 and 0x204 only exist on the
blitter). Since we never explicitly set a value for those register and
given that we don't need to update the offsets in the lrc image when we
change engine within the class for virtual engine because the HW can
handle that, instead of having a separate define for the BCS we can
just restrict the programming to the part we're interested in, which is
common across the engines.
Bspec: 45584
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Stuart Summers <stuart.summers@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/20191009230424.6507-2-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Wed, 9 Oct 2019 23:04:23 +0000 (16:04 -0700)]
drm/i915/tgl: the BCS engine supports relative MMIO
The specs don't mention any specific HW limitation on the blitter and
manual inspection shows that the HW does set the relative MMIO bit in
the LRI of the blitter context image, so we can remove our limitations.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.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/20191009230424.6507-1-daniele.ceraolospurio@intel.com
Chris Wilson [Wed, 9 Oct 2019 16:09:06 +0000 (17:09 +0100)]
drm/i915/gt: execlists->active is serialised by the tasklet
The active/pending execlists is no longer protected by the
engine->active.lock, but is serialised by the tasklet instead. Update
the locking around the debug and stats to follow suit.
v2: local_bh_disable() to prevent recursing into the tasklet in case we
trigger a softirq (Tvrtko)
Fixes:
df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock")
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/20191009160906.16195-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 9 Oct 2019 10:09:54 +0000 (11:09 +0100)]
drm/i915/execlists: Protect peeking at execlists->active
Now that we dropped the engine->active.lock serialisation from around
process_csb(), direct submission can run concurrently to the interrupt
handler. As such execlists->active may be advanced as we dequeue,
dropping the reference to the request. We need to employ our RCU request
protection to ensure that the request is not freed too early.
Fixes:
df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock")
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/20191009100955.21477-1-chris@chris-wilson.co.uk
Matt Roper [Tue, 8 Oct 2019 17:29:20 +0000 (10:29 -0700)]
drm/i915: Select DPLL's via mask
This slightly simplifies the EHL DPLL4 handling and also gives us more
flexibility in the future in case we need to skip the use of specific
PLL's (e.g., due to hardware workarounds and such).
v2:
- Replace GENMASK() with or'd BIT()'s to make the specific DPLLs more
explicit. (Ville)
- s/unsigned/unsigned long/. (Lucas)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008172920.11362-1-matthew.d.roper@intel.com
Swati Sharma [Wed, 9 Oct 2019 06:55:40 +0000 (12:25 +0530)]
drm/i915/color: move check of gamma_enable to specific func/platform
Moved common code to check gamma_enable to specific funcs per platform
in bit_precision func. icl doesn't support that and chv has separate
enable knob for CGM LUT.
v2:
-Simplified chv_gamma_precision() [Ville]
Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191009065542.27415-3-swati2.sharma@intel.com
Swati Sharma [Wed, 9 Oct 2019 06:55:39 +0000 (12:25 +0530)]
drm/i915/color: fix broken gamma state-checker during boot
Premature gamma lut prepration and loading which was getting
reflected in first modeset causing different colors on
screen during boot.
Issue: In BIOS, gamma is disabled by default. However, legacy read_luts()
was setting crtc_state->base.gamma_lut and gamma_lut was programmed
with junk values which led to visual artifacts (different
colored screens instead of usual black during boot).
Fix: Calling read_luts() only when gamma is enabled which will happen
after first modeset.
This fix is independent from the revert
1b8588741fdc ("Revert
"drm/i915/color: Extract icl_read_luts()"") and should fix different colors
on screen in legacy platforms too.
v2:
-Added gamma_enable checks inside read_luts() [Ville/Jani N]
-Corrected gamma enable check for CHV [Ville]
v3:
-Added check in ilk_read_luts() [Ville]
-Simplified gamma enable check for CHV [Ville]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111885
Tested-by: Jani Saarinen <jani.saarinen@intel.com>
Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191009065542.27415-2-swati2.sharma@intel.com
Colin Ian King [Wed, 9 Oct 2019 10:00:24 +0000 (11:00 +0100)]
drm/i915/selftests: fix null pointer dereference on pointer data
In the case where data fails to be allocated the error exit path is
via label 'out' where data is dereferenced in a for-loop. Fix this
by exiting via the label 'out_file' instead to avoid the null pointer
dereference.
Addresses-Coverity: ("Dereference after null check")
Fixes:
50d16d44cce4 ("drm/i915/selftests: Exercise context switching in parallel")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191009100024.23077-1-colin.king@canonical.com
Chris Wilson [Wed, 9 Oct 2019 06:17:59 +0000 (07:17 +0100)]
drm/i915/selftests: Hold request reference over waits
Take a reference on the request before submitting it to the HW and then
waiting on it for selftest_workarounds. Once submitted, the request may
be freed by a background worker, unless we take an extra reference for
ourselves.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111926
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/20191009061759.3189-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 8 Oct 2019 18:59:41 +0000 (19:59 +0100)]
drm/i915/gt: Give engine->kernel_context distinct timeline lock classes
Assign a separate lockclass to the perma-pinned timelines of the
kernel_context, such that we can use them from within the user timelines
should we ever need to inject GPU operations to fixup faults during
request construction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008185941.15228-1-chris@chris-wilson.co.uk
Matthew Auld [Tue, 8 Oct 2019 16:01:16 +0000 (17:01 +0100)]
drm/i915/region: support volatile objects
Volatile objects are marked as DONTNEED while pinned, therefore once
unpinned the backing store can be discarded. This is limited to kernel
internal objects.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: CQ Tang <cq.tang@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.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/20191008160116.18379-4-matthew.auld@intel.com
Matthew Auld [Tue, 8 Oct 2019 16:01:15 +0000 (17:01 +0100)]
drm/i915/region: support contiguous allocations
Some kernel internal objects may need to be allocated as a contiguous
block, also thinking ahead the various kernel io_mapping interfaces seem
to expect it, although this is purely a limitation in the kernel
API...so perhaps something to be improved.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Michael J Ruhl <michael.j.ruhl@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/20191008160116.18379-3-matthew.auld@intel.com
Matthew Auld [Tue, 8 Oct 2019 16:01:14 +0000 (17:01 +0100)]
drm/i915: introduce intel_memory_region
Support memory regions, as defined by a given (start, end), and allow
creating GEM objects which are backed by said region. The immediate goal
here is to have something to represent our device memory, but later on
we also want to represent every memory domain with a region, so stolen,
shmem, and of course device. At some point we are probably going to want
use a common struct here, such that we are better aligned with say TTM.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.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/20191008160116.18379-2-matthew.auld@intel.com
Chris Wilson [Tue, 8 Oct 2019 10:56:55 +0000 (11:56 +0100)]
drm/i915/gt: Flush submission tasklet before waiting/retiring
A common bane of ours is arbitrary delays in ksoftirqd processing our
submission tasklet. Give the submission tasklet a kick before we wait to
avoid those delays eating into a tight timeout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008105655.13256-1-chris@chris-wilson.co.uk
Lionel Landwerlin [Tue, 8 Oct 2019 14:01:11 +0000 (15:01 +0100)]
drm/i915/perf: drop list of streams
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and given
the hard time we already have making everything work with the
submission side, there is no real point having this list of 1 element
around.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@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/20191008140111.5437-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 8 Oct 2019 14:50:45 +0000 (15:50 +0100)]
drm/i915/selftests: Assign the intel_runtime_pm pointer for mock_uncore
Couple up our mock_uncore to know about the fake global device and its
runtime powermanagement.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008145045.23157-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 8 Oct 2019 07:11:21 +0000 (08:11 +0100)]
drm/i915/selftests: Assign the mock_engine->uncore shortcut
Set up the engine->uncore shortcut on mock_engine creation.
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/20191008071121.25088-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 8 Oct 2019 07:03:42 +0000 (08:03 +0100)]
drm/i915/execlists: Assign virtual_engine->uncore from first sibling
Copy across the engine->uncore shortcut to the virtual_engine from its
first physical engine, similar to the handling of the engine->gt
backpointer.
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/20191008070342.4045-1-chris@chris-wilson.co.uk
Anshuman Gupta [Thu, 3 Oct 2019 08:17:38 +0000 (13:47 +0530)]
drm/i915/tgl: Add DC3CO counter in i915_dmc_info
Adding DC3CO counter in i915_dmc_info debugfs will be
useful for DC3CO validation.
DMC firmware uses DMC_DEBUG3 register as DC3CO counter
register on TGL, as per B.Specs DMC_DEBUG3 is general
purpose register.
v1: comment modification for DMC_DBUG3.
using GEN >= 12 check instead of IS_TIGERLAKE()
to print DMC_DEBUG3 counter value.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-7-anshuman.gupta@intel.com
Anshuman Gupta [Thu, 3 Oct 2019 08:17:37 +0000 (13:47 +0530)]
drm/i915/tgl: Switch between dc3co and dc5 based on display idleness
DC3CO is useful power state, when DMC detects PSR2 idle frame
while an active video playback, playing 30fps video on 60hz panel
is the classic example of this use case.
B.Specs:49196 has a restriction to enable DC3CO only for Video Playback.
It will be worthy to enable DC3CO after completion of each pageflip
and switch back to DC5 when display is idle because driver doesn't
differentiate between video playback and a normal pageflip.
We will use Frontbuffer flush call tgl_dc3co_flush() to enable DC3CO
state only for ORIGIN_FLIP flush call, because DC3CO state has primarily
targeted for VPB use case. We are not interested here for frontbuffer
invalidates calls because that triggers PSR2 exit, which will
explicitly disable DC3CO.
DC5 and DC6 saves more power, but can't be entered during video
playback because there are not enough idle frames in a row to meet
most PSR2 panel deep sleep entry requirement typically 4 frames.
As PSR2 existing implementation is using minimum 6 idle frames for
deep sleep, it is safer to enable DC5/6 after 6 idle frames
(By scheduling a delayed work of 6 idle frames, once DC3CO has been
enabled after a pageflip).
After manually waiting for 6 idle frames DC5/6 will be enabled and
PSR2 deep sleep idle frames will be restored to 6 idle frames, at this
point DMC will triggers DC5/6 once PSR2 enters to deep sleep after
6 idle frames.
In future when we will enable S/W PSR2 tracking, we can change the
PSR2 required deep sleep idle frames to 1 so DMC can trigger the
DC5/6 immediately after S/W manual waiting of 6 idle frames get
complete.
v2: calculated s/w state to switch over dc3co when there is an
update. [Imre]
Used cancel_delayed_work_sync() in order to avoid any race
with already scheduled delayed work. [Imre]
v3: Cancel_delayed_work_sync() may blocked the commit work.
hence dropping it, dc5_idle_thread() checks the valid wakeref before
putting the reference count, which avoids any chances of dropping
a zero wakeref. [Imre (IRC)]
v4: Used frontbuffer flush mechanism. [Imre]
v5: Used psr.pipe to extract frontbuffer busy bits. [Imre]
Used cancel_delayed_work_sync() in encoder disable path. [Imre]
Used mod_delayed_work() instead of cancelling and scheduling a
delayed work. [Imre]
Used psr.lock in tgl_dc5_idle_thread() to enable psr2 deep
sleep. [Imre]
Removed DC5_REQ_IDLE_FRAMES macro. [Imre]
v6: Used dc3co_exitline check instead of TGL and dc3co allowed_dc_mask
checks, used delayed_work_pending with the psr lock and removed the
psr2_deep_slp_disabled flag. [Imre]
v7: Code refactoring, moved most of functional code to inte_psr.c [Imre]
Using frontbuffer_bits on psr.pipe check instead of
busy_frontbuffer_bits. [Imre]
Calculating dc3co_exit_delay in intel_psr_enable_locked. [Imre]
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-6-anshuman.gupta@intel.com
Anshuman Gupta [Thu, 3 Oct 2019 08:17:36 +0000 (13:47 +0530)]
drm/i915/tgl: Do modeset to enable and configure DC3CO exitline
DC3CO enabling B.Specs sequence requires to enable end configure
exit scanlines to TRANS_EXITLINE register, programming this register
has to be part of modeset sequence as this can't be change when
transcoder or port is enabled.
When system boots with only eDP panel there may not be real
modeset as BIOS has already programmed the necessary registers,
therefore it needs to force a modeset to enable and configure
DC3CO exitline.
v1: Computing dc3co_exitline crtc state from a DP encoder
compute config. [Imre]
Enabling and disabling DC3CO PSR2 transcoder exitline from
encoder pre_enable and post_disable hooks. [Imre]
Computing dc3co_exitline instead of has_dc3co_exitline bool. [Imre]
v2: Code refactoring for symmetry and to avoid exported function. [Imre]
Removing IS_TIGERLAKE check from compute_config, adding PIPE_A
restriction and clearing dc3co_exitline state if crtc is not active
or it is not PSR2 capable in dc3co exitline compute_config. [Imre]
Using GEN >= 12 check in dc3co exitline get_config. [Imre]
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-5-anshuman.gupta@intel.com
Anshuman Gupta [Thu, 3 Oct 2019 08:17:35 +0000 (13:47 +0530)]
drm/i915/tgl: Enable DC3CO state in "DC Off" power well
Add target_dc_state and used by set_target_dc_state API
in order to enable DC3CO state with existing DC states.
target_dc_state will enable/disable the desired DC state in
DC_STATE_EN reg when "DC Off" power well gets disable/enable.
v2: commit log improvement.
v3: Used intel_wait_for_register to wait for DC3CO exit. [Imre]
Used gen9_set_dc_state() to allow/disallow DC3CO. [Imre]
Moved transcoder psr2 exit line enablement from tgl_allow_dc3co()
to a appropriate place haswell_crtc_enable(). [Imre]
Changed the DC3CO power well enabled call back logic as
recommended in review comments. [Imre]
v4: Used wait_for_us() instead of intel_wait_for_reg(). [Imre (IRC)]
v5: using udelay() instead of waiting for DC3CO exit status.
v6: Fixed minor unwanted change.
v7: Removed DC3CO powerwell and POWER_DOMAIN_VIDEO.
v8: Uniform checks by using only target_dc_state instead of allowed_dc_mask
in "DC off" power well callback. [Imre]
Adding "DC off" power well id to older platforms. [Imre]
Removed psr2_deep_sleep flag from tgl_set_target_dc_state. [Imre]
v9: Used switch case for target DC state in
gen9_dc_off_power_well_disable(), checking DC3CO state against
allowed DC mask, using WARN_ON() in
tgl_set_target_dc_state(). [Imre]
v10: Code refactoring and using sanitize_target_dc_state(). [Imre]
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-4-anshuman.gupta@intel.com
Anshuman Gupta [Thu, 3 Oct 2019 08:17:34 +0000 (13:47 +0530)]
drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask
Enable dc3co state in enable_dc module param and add dc3co
enable mask to allowed_dc_mask and gen9_dc_mask.
v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6
independently. [Animesh]
v2: Using a switch statement for cleaner code. [Animesh]
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-3-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 7 Oct 2019 09:46:07 +0000 (15:16 +0530)]
drm/i915/tgl: Add DC3CO required register and bits
Adding following definition to i915_reg.h
1. DC_STATE_EN register DC3CO bit fields and masks.
DC3CO enable bit will be used by driver to make DC3CO
ready for DMC f/w and status bit will be used as DC3CO
entry status.
2. Transcoder EXITLINE register and its bit fields and mask.
Transcoder EXITLINE enable bit represents PSR2 idle frame
reset should be applied at exit line and exitlines mask
represent required number of scanlines at which DC3CO
exit happens.
B.Specs:49196
v1: Use of REG_BIT and using extra space for EXITLINE_ macro
definition. [Animesh]
v2: Grouping EXITLINE reg bits with EXITLINE(trans) define,
no functional change. [Ville]
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191007094607.2111-1-anshuman.gupta@intel.com
Chris Wilson [Mon, 7 Oct 2019 21:09:42 +0000 (22:09 +0100)]
drm/i915/perf: Set the exclusive stream under perf->lock
The BKL struct_mutex is no more, the only serialisation we required for
setting the exclusive stream is already managed by ce->pin_mutex in
gen8_configure_all_contexts(). As such, we can manipulate
i915_perf.exclusive_stream underneath our own (already held) perf->lock.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191007140812.10963-2-chris@chris-wilson.co.uk
Link: https://patchwork.freedesktop.org/patch/msgid/20191007210942.18145-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 7 Oct 2019 21:09:41 +0000 (22:09 +0100)]
drm/i915/perf: Wean ourselves off dev_priv
Use the local uncore accessors for the GT rather than using the [not-so]
magic global dev_priv mmio routines. In the process, we also teach the
perf stream to use backpointers to the i915_perf rather than digging it
out of dev_priv.
v2: Rebase onto i915_perf_types.h
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20191007140812.10963-1-chris@chris-wilson.co.uk
Link: https://patchwork.freedesktop.org/patch/msgid/20191007210942.18145-1-chris@chris-wilson.co.uk
Krzysztof Kozlowski [Mon, 7 Oct 2019 17:33:46 +0000 (19:33 +0200)]
drm/i915: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191007173346.9379-1-krzk@kernel.org
Chris Wilson [Sun, 6 Oct 2019 16:49:54 +0000 (17:49 +0100)]
drm/i915/gt: Treat a busy timeline as 'active' while waiting
If we cannot claim the timeline->mutex while preparing for a wait on it,
we have to skip the timeline. In doing so, treat it as active so that
under a intel_gt_wait_for_idle() loop, we repeat the wait after
scheduling away.
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/20191006165002.30312-4-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 20:31:21 +0000 (21:31 +0100)]
drm/i915/selftests: Appease lockdep
Disable irqs around updating the context image to keep lockdep happy:
<4>[ 673.483340] WARNING: possible irq lock inversion dependency detected
<4>[ 673.483342] 5.4.0-rc1-CI-Trybot_5118+ #1 Tainted: G U
<4>[ 673.483342] --------------------------------------------------------
<4>[ 673.483343] swapper/2/0 just changed the state of lock:
<4>[ 673.483344]
ffff88845db885a0 (&i915_request_get(rq)->submit/1){-...}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915]
<4>[ 673.483387] but this lock took another, HARDIRQ-unsafe lock in the past:
<4>[ 673.483388] (&ce->pin_mutex/2){+...}
<4>[ 673.483389]
and interrupts could create inverse lock ordering between them.
<4>[ 673.483390]
other info that might help us debug this:
<4>[ 673.483390] Chain exists of:
&i915_request_get(rq)->submit/1 --> &engine->active.lock --> &ce->pin_mutex/2
<4>[ 673.483392] Possible interrupt unsafe locking scenario:
<4>[ 673.483392] CPU0 CPU1
<4>[ 673.483393] ---- ----
<4>[ 673.483393] lock(&ce->pin_mutex/2);
<4>[ 673.483394] local_irq_disable();
<4>[ 673.483395] lock(&i915_request_get(rq)->submit/1);
<4>[ 673.483396] lock(&engine->active.lock);
<4>[ 673.483396] <Interrupt>
<4>[ 673.483397] lock(&i915_request_get(rq)->submit/1);
<4>[ 673.483398]
*** DEADLOCK ***
<4>[ 673.483398] 2 locks held by swapper/2/0:
<4>[ 673.483399] #0:
ffff8883f61ac9b0 (&(>->irq_lock)->rlock){-.-.}, at: gen11_gt_irq_handler+0x42/0x280 [i915]
<4>[ 673.483433] #1:
ffff88845db8c418 (&(&rq->lock)->rlock){-.-.}, at: intel_engine_breadcrumbs_irq+0x34a/0x5a0 [i915]
<4>[ 673.483463]
the shortest dependencies between 2nd lock and 1st lock:
<4>[ 673.483466] -> (&ce->pin_mutex/2){+...} ops: 614520 {
<4>[ 673.483468] HARDIRQ-ON-W at:
<4>[ 673.483471] lock_acquire+0xa7/0x1c0
<4>[ 673.483501] live_unlite_restore+0x1d8/0x6c0 [i915]
<4>[ 673.483543] __i915_subtests+0xb8/0x210 [i915]
<4>[ 673.483581] __run_selftests+0x112/0x170 [i915]
<4>[ 673.483615] i915_live_selftests+0x2c/0x60 [i915]
<4>[ 673.483644] i915_pci_probe+0x93/0x1b0 [i915]
<4>[ 673.483646] pci_device_probe+0x9e/0x120
<4>[ 673.483648] really_probe+0xea/0x420
<4>[ 673.483649] driver_probe_device+0x10b/0x120
<4>[ 673.483651] device_driver_attach+0x4a/0x50
<4>[ 673.483652] __driver_attach+0x97/0x130
<4>[ 673.483653] bus_for_each_dev+0x74/0xc0
<4>[ 673.483654] bus_add_driver+0x142/0x220
<4>[ 673.483655] driver_register+0x56/0xf0
<4>[ 673.483657] do_one_initcall+0x58/0x2ff
<4>[ 673.483659] do_init_module+0x56/0x1f8
<4>[ 673.483660] load_module+0x243e/0x29f0
<4>[ 673.483661] __do_sys_finit_module+0xe9/0x110
<4>[ 673.483662] do_syscall_64+0x4f/0x210
<4>[ 673.483665] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 673.483665] INITIAL USE at:
<4>[ 673.483667] lock_acquire+0xa7/0x1c0
<4>[ 673.483698] live_unlite_restore+0x1d8/0x6c0 [i915]
<4>[ 673.483733] __i915_subtests+0xb8/0x210 [i915]
<4>[ 673.483764] __run_selftests+0x112/0x170 [i915]
<4>[ 673.483793] i915_live_selftests+0x2c/0x60 [i915]
<4>[ 673.483821] i915_pci_probe+0x93/0x1b0 [i915]
<4>[ 673.483822] pci_device_probe+0x9e/0x120
<4>[ 673.483824] really_probe+0xea/0x420
<4>[ 673.483825] driver_probe_device+0x10b/0x120
<4>[ 673.483826] device_driver_attach+0x4a/0x50
<4>[ 673.483827] __driver_attach+0x97/0x130
<4>[ 673.483828] bus_for_each_dev+0x74/0xc0
<4>[ 673.483829] bus_add_driver+0x142/0x220
<4>[ 673.483830] driver_register+0x56/0xf0
<4>[ 673.483831] do_one_initcall+0x58/0x2ff
<4>[ 673.483833] do_init_module+0x56/0x1f8
<4>[ 673.483834] load_module+0x243e/0x29f0
<4>[ 673.483835] __do_sys_finit_module+0xe9/0x110
<4>[ 673.483836] do_syscall_64+0x4f/0x210
<4>[ 673.483837] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 673.483838] }
<4>[ 673.483868] ... key at: [<
ffffffffa0a8f132>] __key.70113+0x2/0xffffffffffef2ed0 [i915]
<4>[ 673.483869] ... acquired at:
<4>[ 673.483935] __execlists_reset+0xfb/0xc20 [i915]
<4>[ 673.483965] execlists_reset+0x3d/0x50 [i915]
<4>[ 673.483995] intel_engine_reset+0xdf/0x230 [i915]
<4>[ 673.484022] live_preempt_hang+0x1d7/0x2e0 [i915]
<4>[ 673.484064] __i915_subtests+0xb8/0x210 [i915]
<4>[ 673.484130] __run_selftests+0x112/0x170 [i915]
<4>[ 673.484163] i915_live_selftests+0x2c/0x60 [i915]
<4>[ 673.484193] i915_pci_probe+0x93/0x1b0 [i915]
<4>[ 673.484194] pci_device_probe+0x9e/0x120
<4>[ 673.484195] really_probe+0xea/0x420
<4>[ 673.484196] driver_probe_device+0x10b/0x120
<4>[ 673.484197] device_driver_attach+0x4a/0x50
<4>[ 673.484198] __driver_attach+0x97/0x130
<4>[ 673.484199] bus_for_each_dev+0x74/0xc0
<4>[ 673.484200] bus_add_driver+0x142/0x220
<4>[ 673.484202] driver_register+0x56/0xf0
<4>[ 673.484203] do_one_initcall+0x58/0x2ff
<4>[ 673.484204] do_init_module+0x56/0x1f8
<4>[ 673.484205] load_module+0x243e/0x29f0
<4>[ 673.484206] __do_sys_finit_module+0xe9/0x110
<4>[ 673.484207] do_syscall_64+0x4f/0x210
<4>[ 673.484208] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 673.484209] -> (&engine->active.lock){..-.} ops: 972791 {
<4>[ 673.484211] IN-SOFTIRQ-W at:
<4>[ 673.484213] lock_acquire+0xa7/0x1c0
<4>[ 673.484214] _raw_spin_lock_irqsave+0x33/0x50
<4>[ 673.484244] execlists_submission_tasklet+0xaf/0x100 [i915]
<4>[ 673.484246] tasklet_action_common.isra.18+0x6c/0x1c0
<4>[ 673.484247] __do_softirq+0xdf/0x47f
<4>[ 673.484248] irq_exit+0xba/0xc0
<4>[ 673.484249] do_IRQ+0x83/0x160
<4>[ 673.484250] ret_from_intr+0x0/0x1d
<4>[ 673.484252] cpuidle_enter_state+0xb2/0x450
<4>[ 673.484253] cpuidle_enter+0x24/0x40
<4>[ 673.484254] do_idle+0x1e7/0x250
<4>[ 673.484256] cpu_startup_entry+0x14/0x20
<4>[ 673.484257] start_secondary+0x15f/0x1b0
<4>[ 673.484258] secondary_startup_64+0xa4/0xb0
<4>[ 673.484259] INITIAL USE at:
<4>[ 673.484261] lock_acquire+0xa7/0x1c0
<4>[ 673.484290] intel_engine_init_active+0x7e/0xb0 [i915]
<4>[ 673.484305] intel_engines_setup+0x1cd/0x3b0 [i915]
<4>[ 673.484305] i915_gem_init+0x12d/0x900 [i915]
<4>[ 673.484305] i915_driver_probe+0xb70/0x15d0 [i915]
<4>[ 673.484305] i915_pci_probe+0x43/0x1b0 [i915]
<4>[ 673.484305] pci_device_probe+0x9e/0x120
<4>[ 673.484305] really_probe+0xea/0x420
<4>[ 673.484305] driver_probe_device+0x10b/0x120
<4>[ 673.484305] device_driver_attach+0x4a/0x50
<4>[ 673.484305] __driver_attach+0x97/0x130
<4>[ 673.484305] bus_for_each_dev+0x74/0xc0
<4>[ 673.484305] bus_add_driver+0x142/0x220
<4>[ 673.484305] driver_register+0x56/0xf0
<4>[ 673.484305] do_one_initcall+0x58/0x2ff
<4>[ 673.484305] do_init_module+0x56/0x1f8
<4>[ 673.484305] load_module+0x243e/0x29f0
<4>[ 673.484305] __do_sys_finit_module+0xe9/0x110
<4>[ 673.484305] do_syscall_64+0x4f/0x210
<4>[ 673.484305] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 673.484305] }
<4>[ 673.484305] ... key at: [<
ffffffffa0a8f160>] __key.70307+0x0/0xffffffffffef2ea0 [i915]
<4>[ 673.484305] ... acquired at:
<4>[ 673.484305] _raw_spin_lock_irqsave+0x33/0x50
<4>[ 673.484305] execlists_submit_request+0x2b/0x1e0 [i915]
<4>[ 673.484305] submit_notify+0xa8/0x13c [i915]
<4>[ 673.484305] __i915_sw_fence_complete+0x81/0x250 [i915]
<4>[ 673.484305] i915_sw_fence_wake+0x51/0x70 [i915]
<4>[ 673.484305] __i915_sw_fence_complete+0x1ee/0x250 [i915]
<4>[ 673.484305] dma_i915_sw_fence_wake+0x1b/0x30 [i915]
<4>[ 673.484305] dma_fence_signal_locked+0x9e/0x1b0
<4>[ 673.484305] dma_fence_signal+0x1f/0x40
<4>[ 673.484305] fence_work+0x28/0x80 [i915]
<4>[ 673.484305] process_one_work+0x26a/0x620
<4>[ 673.484305] worker_thread+0x37/0x380
<4>[ 673.484305] kthread+0x119/0x130
<4>[ 673.484305] ret_from_fork+0x24/0x50
<4>[ 673.484305] -> (&i915_request_get(rq)->submit/1){-...} ops: 857694 {
<4>[ 673.484305] IN-HARDIRQ-W at:
<4>[ 673.484305] lock_acquire+0xa7/0x1c0
<4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50
<4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915]
<4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915]
<4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915]
<4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915]
<4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915]
<4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0
<4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70
<4>[ 673.484305] handle_irq_event+0x2f/0x50
<4>[ 673.484305] handle_edge_irq+0x99/0x1b0
<4>[ 673.484305] do_IRQ+0x7e/0x160
<4>[ 673.484305] ret_from_intr+0x0/0x1d
<4>[ 673.484305] cpuidle_enter_state+0xb2/0x450
<4>[ 673.484305] cpuidle_enter+0x24/0x40
<4>[ 673.484305] do_idle+0x1e7/0x250
<4>[ 673.484305] cpu_startup_entry+0x14/0x20
<4>[ 673.484305] start_secondary+0x15f/0x1b0
<4>[ 673.484305] secondary_startup_64+0xa4/0xb0
<4>[ 673.484305] INITIAL USE at:
<4>[ 673.484305] lock_acquire+0xa7/0x1c0
<4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50
<4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915]
<4>[ 673.484305] __engine_park+0x233/0x420 [i915]
<4>[ 673.484305] ____intel_wakeref_put_last+0x1c/0x70 [i915]
<4>[ 673.484305] intel_gt_resume+0x202/0x2c0 [i915]
<4>[ 673.484305] i915_gem_init+0x36e/0x900 [i915]
<4>[ 673.484305] i915_driver_probe+0xb70/0x15d0 [i915]
<4>[ 673.484305] i915_pci_probe+0x43/0x1b0 [i915]
<4>[ 673.484305] pci_device_probe+0x9e/0x120
<4>[ 673.484305] really_probe+0xea/0x420
<4>[ 673.484305] driver_probe_device+0x10b/0x120
<4>[ 673.484305] device_driver_attach+0x4a/0x50
<4>[ 673.484305] __driver_attach+0x97/0x130
<4>[ 673.484305] bus_for_each_dev+0x74/0xc0
<4>[ 673.484305] bus_add_driver+0x142/0x220
<4>[ 673.484305] driver_register+0x56/0xf0
<4>[ 673.484305] do_one_initcall+0x58/0x2ff
<4>[ 673.484305] do_init_module+0x56/0x1f8
<4>[ 673.484305] load_module+0x243e/0x29f0
<4>[ 673.484305] __do_sys_finit_module+0xe9/0x110
<4>[ 673.484305] do_syscall_64+0x4f/0x210
<4>[ 673.484305] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 673.484305] }
<4>[ 673.484305] ... key at: [<
ffffffffa0a8f6a1>] __key.80173+0x1/0xffffffffffef2960 [i915]
<4>[ 673.484305] ... acquired at:
<4>[ 673.484305] mark_lock+0x382/0x500
<4>[ 673.484305] __lock_acquire+0x7e1/0x15d0
<4>[ 673.484305] lock_acquire+0xa7/0x1c0
<4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50
<4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915]
<4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915]
<4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915]
<4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915]
<4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915]
<4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0
<4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70
<4>[ 673.484305] handle_irq_event+0x2f/0x50
<4>[ 673.484305] handle_edge_irq+0x99/0x1b0
<4>[ 673.484305] do_IRQ+0x7e/0x160
<4>[ 673.484305] ret_from_intr+0x0/0x1d
<4>[ 673.484305] cpuidle_enter_state+0xb2/0x450
<4>[ 673.484305] cpuidle_enter+0x24/0x40
<4>[ 673.484305] do_idle+0x1e7/0x250
<4>[ 673.484305] cpu_startup_entry+0x14/0x20
<4>[ 673.484305] start_secondary+0x15f/0x1b0
<4>[ 673.484305] secondary_startup_64+0xa4/0xb0
<4>[ 673.484305]
stack backtrace:
<4>[ 673.484305] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G U 5.4.0-rc1-CI-Trybot_5118+ #1
<4>[ 673.484305] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.
1905020411 05/02/2019
<4>[ 673.484305] Call Trace:
<4>[ 673.484305] <IRQ>
<4>[ 673.484305] dump_stack+0x67/0x9b
<4>[ 673.484305] check_usage_forwards+0x13c/0x150
<4>[ 673.484305] ? mark_lock+0x382/0x500
<4>[ 673.484305] mark_lock+0x382/0x500
<4>[ 673.484305] ? check_usage_backwards+0x140/0x140
<4>[ 673.484305] __lock_acquire+0x7e1/0x15d0
<4>[ 673.484305] ? debug_object_deactivate+0x17e/0x190
<4>[ 673.484305] lock_acquire+0xa7/0x1c0
<4>[ 673.484305] ? __i915_sw_fence_complete+0x1b2/0x250 [i915]
<4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50
<4>[ 673.484305] ? __i915_sw_fence_complete+0x1b2/0x250 [i915]
<4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915]
<4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915]
<4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915]
<4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915]
<4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915]
<4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0
<4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70
<4>[ 673.484305] handle_irq_event+0x2f/0x50
<4>[ 673.484305] handle_edge_irq+0x99/0x1b0
<4>[ 673.484305] do_IRQ+0x7e/0x160
<4>[ 673.484305] common_interrupt+0xf/0xf
<4>[ 673.484305] </IRQ>
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/20191004203121.31138-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 19:47:58 +0000 (20:47 +0100)]
drm/i915/execlists: Fix annotation for decoupling virtual request
As we may signal a request and take the engine->active.lock within the
signaler, the engine submission paths have to use a nested annotation on
their requests -- but we guarantee that we can never submit on the same
engine as the signaling fence.
<4>[ 723.763281] WARNING: possible circular locking dependency detected
<4>[ 723.763285] 5.3.0-g80fa0e042cdb-drmtip_379+ #1 Tainted: G U
<4>[ 723.763288] ------------------------------------------------------
<4>[ 723.763291] gem_exec_await/1388 is trying to acquire lock:
<4>[ 723.763294]
ffff93a7b53221d8 (&engine->active.lock){..-.}, at: execlists_submit_request+0x2b/0x1e0 [i915]
<4>[ 723.763378]
but task is already holding lock:
<4>[ 723.763381]
ffff93a7c25f6d20 (&i915_request_get(rq)->submit/1){-.-.}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915]
<4>[ 723.763420]
which lock already depends on the new lock.
<4>[ 723.763423]
the existing dependency chain (in reverse order) is:
<4>[ 723.763427]
-> #2 (&i915_request_get(rq)->submit/1){-.-.}:
<4>[ 723.763434] _raw_spin_lock_irqsave_nested+0x39/0x50
<4>[ 723.763478] __i915_sw_fence_complete+0x1b2/0x250 [i915]
<4>[ 723.763513] intel_engine_breadcrumbs_irq+0x3aa/0x5e0 [i915]
<4>[ 723.763600] cs_irq_handler+0x49/0x50 [i915]
<4>[ 723.763659] gen11_gt_irq_handler+0x17b/0x280 [i915]
<4>[ 723.763690] gen11_irq_handler+0x54/0xf0 [i915]
<4>[ 723.763695] __handle_irq_event_percpu+0x41/0x2d0
<4>[ 723.763699] handle_irq_event_percpu+0x2b/0x70
<4>[ 723.763702] handle_irq_event+0x2f/0x50
<4>[ 723.763706] handle_edge_irq+0xee/0x1a0
<4>[ 723.763709] do_IRQ+0x7e/0x160
<4>[ 723.763712] ret_from_intr+0x0/0x1d
<4>[ 723.763717] __slab_alloc.isra.28.constprop.33+0x4f/0x70
<4>[ 723.763720] kmem_cache_alloc+0x28d/0x2f0
<4>[ 723.763724] vm_area_dup+0x15/0x40
<4>[ 723.763727] dup_mm+0x2dd/0x550
<4>[ 723.763730] copy_process+0xf21/0x1ef0
<4>[ 723.763734] _do_fork+0x71/0x670
<4>[ 723.763737] __se_sys_clone+0x6e/0xa0
<4>[ 723.763741] do_syscall_64+0x4f/0x210
<4>[ 723.763744] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 723.763747]
-> #1 (&(&rq->lock)->rlock#2){-.-.}:
<4>[ 723.763752] _raw_spin_lock+0x2a/0x40
<4>[ 723.763789] __unwind_incomplete_requests+0x3eb/0x450 [i915]
<4>[ 723.763825] __execlists_submission_tasklet+0x9ec/0x1d60 [i915]
<4>[ 723.763864] execlists_submission_tasklet+0x34/0x50 [i915]
<4>[ 723.763874] tasklet_action_common.isra.5+0x47/0xb0
<4>[ 723.763878] __do_softirq+0xd8/0x4ae
<4>[ 723.763881] irq_exit+0xa9/0xc0
<4>[ 723.763883] smp_apic_timer_interrupt+0xb7/0x280
<4>[ 723.763887] apic_timer_interrupt+0xf/0x20
<4>[ 723.763892] cpuidle_enter_state+0xae/0x450
<4>[ 723.763895] cpuidle_enter+0x24/0x40
<4>[ 723.763899] do_idle+0x1e7/0x250
<4>[ 723.763902] cpu_startup_entry+0x14/0x20
<4>[ 723.763905] start_secondary+0x15f/0x1b0
<4>[ 723.763908] secondary_startup_64+0xa4/0xb0
<4>[ 723.763911]
-> #0 (&engine->active.lock){..-.}:
<4>[ 723.763916] __lock_acquire+0x15d8/0x1ea0
<4>[ 723.763919] lock_acquire+0xa6/0x1c0
<4>[ 723.763922] _raw_spin_lock_irqsave+0x33/0x50
<4>[ 723.763956] execlists_submit_request+0x2b/0x1e0 [i915]
<4>[ 723.764002] submit_notify+0xa8/0x13c [i915]
<4>[ 723.764035] __i915_sw_fence_complete+0x81/0x250 [i915]
<4>[ 723.764054] i915_sw_fence_wake+0x51/0x64 [i915]
<4>[ 723.764054] __i915_sw_fence_complete+0x1ee/0x250 [i915]
<4>[ 723.764054] dma_i915_sw_fence_wake_timer+0x14/0x20 [i915]
<4>[ 723.764054] dma_fence_signal_locked+0x9e/0x1c0
<4>[ 723.764054] dma_fence_signal+0x1f/0x40
<4>[ 723.764054] vgem_fence_signal_ioctl+0x67/0xc0 [vgem]
<4>[ 723.764054] drm_ioctl_kernel+0x83/0xf0
<4>[ 723.764054] drm_ioctl+0x2f3/0x3b0
<4>[ 723.764054] do_vfs_ioctl+0xa0/0x6f0
<4>[ 723.764054] ksys_ioctl+0x35/0x60
<4>[ 723.764054] __x64_sys_ioctl+0x11/0x20
<4>[ 723.764054] do_syscall_64+0x4f/0x210
<4>[ 723.764054] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 723.764054]
other info that might help us debug this:
<4>[ 723.764054] Chain exists of:
&engine->active.lock --> &(&rq->lock)->rlock#2 --> &i915_request_get(rq)->submit/1
<4>[ 723.764054] Possible unsafe locking scenario:
<4>[ 723.764054] CPU0 CPU1
<4>[ 723.764054] ---- ----
<4>[ 723.764054] lock(&i915_request_get(rq)->submit/1);
<4>[ 723.764054] lock(&(&rq->lock)->rlock#2);
<4>[ 723.764054] lock(&i915_request_get(rq)->submit/1);
<4>[ 723.764054] lock(&engine->active.lock);
<4>[ 723.764054]
*** DEADLOCK ***
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111862
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/20191004194758.19679-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 7 Oct 2019 15:45:31 +0000 (16:45 +0100)]
drm/i915/gt: Prefer local path to runtime powermanagement
Avoid going to the base i915 device when we already have a path from gt
to the runtime powermanagement interface. The benefit is that it looks a
bit more self-consistent to always be acquiring the gt->uncore->rpm for
use with the gt->uncore.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191007154531.1750-1-chris@chris-wilson.co.uk
Colin Ian King [Mon, 7 Oct 2019 15:41:51 +0000 (16:41 +0100)]
drm/i915: make array hw_engine_mask static, makes object smaller
Don't populate the array hw_engine_mask on the stack but instead make it
static. Makes the object code smaller by 316 bytes.
Before:
text data bss dec hex filename
34004 4388 320 38712 9738 gpu/drm/i915/gt/intel_reset.o
After:
text data bss dec hex filename
33528 4548 320 38396 95fc gpu/drm/i915/gt/intel_reset.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191007154151.23245-1-colin.king@canonical.com
Matt Roper [Wed, 2 Oct 2019 19:22:58 +0000 (12:22 -0700)]
drm/i915/vbt: Child device size remains unchanged through VBT 229
The latest documented version of the VBT is 229, but no further data has
been added to the child device definition in block 2. Update the child
device version test to eliminate the "Expected child device config size
for VBT version XXX not known; assuming 39" debug messages from the
logs.
Bspec: 20124
Bspec: 20157
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002192258.1013-1-matthew.d.roper@intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Lionel Landwerlin [Mon, 9 Sep 2019 09:31:09 +0000 (12:31 +0300)]
drm/i915/perf: move perf types to their own header
Following a pattern used throughout the driver.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190909093116.7747-7-lionel.g.landwerlin@intel.com
Chris Wilson [Sun, 6 Oct 2019 16:49:53 +0000 (17:49 +0100)]
drm/i915/gt: Restore dropped 'interruptible' flag
Lost in the rebasing was Tvrtko's reminder that we need to keep an
uninterruptible wait around for the Ironlake VT-d w/a
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/20191006165002.30312-3-chris@chris-wilson.co.uk
Joonas Lahtinen [Mon, 7 Oct 2019 12:24:47 +0000 (15:24 +0300)]
drm/i915: Update DRIVER_DATE to
20191007
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Jani Nikula [Fri, 4 Oct 2019 12:20:19 +0000 (15:20 +0300)]
drm/i915: move gmbus setup down to intel_modeset_init()
Pair the gmbus setup and teardown in the same layer. This also fixes the
double gmbus teardown on the i915_driver_modeset_probe() error path.
Move the gmbus setup a bit later in the sequence to make the follow-up
refactoring easier, and to pinpoint any unexpected consequences of this
change right here, instead of the later refactoring.
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/20191004122019.12009-3-jani.nikula@intel.com
Jani Nikula [Fri, 4 Oct 2019 12:20:18 +0000 (15:20 +0300)]
drm/i915: split out i915_switcheroo.[ch] from i915_drv.c
Split out code related to vga switcheroo register/unregister and state
handling from i915_drv.c into new i915_switcheroo.[ch] files.
It's a bit difficult to draw the line how much to move to the new file
from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo()
and i915_resume_switcheroo() in place was the cleanest.
No functional changes.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
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/20191004122019.12009-2-jani.nikula@intel.com
Jani Nikula [Fri, 4 Oct 2019 12:20:17 +0000 (15:20 +0300)]
drm/i915/vga: rename intel_vga_msr_write() to intel_vga_reset_io_mem()
Rename the function per Ville's suggestion. No functional changes.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.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/20191004122019.12009-1-jani.nikula@intel.com
CQ Tang [Fri, 4 Oct 2019 17:04:32 +0000 (18:04 +0100)]
drm/i915/stolen: make the object creation interface consistent
Our other backends return an actual error value upon failure. Do the
same for stolen objects, which currently just return NULL on failure.
Signed-off-by: CQ Tang <cq.tang@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@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/20191004170452.15410-2-matthew.auld@intel.com
Ville Syrjälä [Thu, 3 Oct 2019 14:02:31 +0000 (17:02 +0300)]
drm/i915: Implement a better i945gm vblank irq vs. C-states workaround
The current "disable C3+" workaround for the delayed vblank
irqs on i945gm no longer works. I'm not sure what changed, but
now I need to also disable C2. I also got my hands on a i915gm
machine that suffers from the same issue.
After some furious poking of registers I managed to find a
better workaround: The "Do not Turn off Core Render Clock in C
states" bit. With that I no longer have to disable any C-states,
and as a nice bonus the power cost is only ~1/4 of the
"disable C3+" method (which mind you doesn't even work anymore,
and so would have an even higher power cost if we made it work
by also disabling C2).
So let's throw out all the cpuidle/qos crap and just toggle
the magic bit as needed. And we extend the workaround to cover
i915gm as well.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003140231.24408-1-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Fri, 4 Oct 2019 13:40:15 +0000 (14:40 +0100)]
drm/i915: Drop struct_mutex from around GEM initialisation
We no longer need to placate lockdep by holding struct_mutex for our
initialisation, so don't.
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/20191004134015.13204-21-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:14 +0000 (14:40 +0100)]
drm/i915/selftests: Drop vestigal struct_mutex guards
We no longer need struct_mutex to serialise request emission, so remove
it from the gt selftests.
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/20191004134015.13204-20-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:13 +0000 (14:40 +0100)]
drm/i915: Drop struct_mutex from suspend state save/restore
struct_mutex provides no serialisation of the registers and data
structures being saved and restored across suspend/resume. It is
completely superfluous here.
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/20191004134015.13204-19-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:12 +0000 (14:40 +0100)]
drm/i915: Remove struct_mutex guard for debugfs/opregion
Having a struct_mutex around the read of a BIOS blob serves no purpose.
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/20191004134015.13204-18-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:11 +0000 (14:40 +0100)]
drm/i915: Drop struct_mutex guard from debugfs/framebuffer_info
It protects nothing being accessed for the intel_framebuffer, so it's
own locking had better be sufficient.
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/20191004134015.13204-17-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:10 +0000 (14:40 +0100)]
drm/i915/overlay: Drop struct_mutex guard
The overlay uses the modeset mutex to control itself and only required
the struct_mutex for requests, which is now obsolete.
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/20191004134015.13204-16-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:09 +0000 (14:40 +0100)]
drm/i915: Move context management under GEM
Keep track of the GEM contexts underneath i915->gem.contexts and assign
them their own lock for the purposes of list management.
v2: Focus on lock tracking; ctx->vm is protected by ctx->mutex
v3: Correct split with removal of logical HW ID
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/20191004134015.13204-15-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:08 +0000 (14:40 +0100)]
drm/i915: Remove logical HW ID
With the introduction of ctx->engines[] we allow multiple logical
contexts to be used on the same engine (e.g. with virtual engines).
According to bspec, aach logical context requires a unique tag in order
for context-switching to occur correctly between them. [Simple
experiments show that it is not so easy to trick the HW into performing
a lite-restore with matching logical IDs, though my memory from early
Broadwell experiments do suggest that it should be generating
lite-restores.]
We only need to keep a unique tag for the active lifetime of the
context, and for as long as we need to identify that context. The HW
uses the tag to determine if it should use a lite-restore (why not the
LRCA?) and passes the tag back for various status identifies. The only
status we need to track is for OA, so when using perf, we assign the
specific context a unique tag.
v2: Calculate required number of tags to fill ELSP.
Fixes:
976b55f0e1db ("drm/i915: Allow a context to define its set of engines")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111895
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-14-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:07 +0000 (14:40 +0100)]
drm/i915: Move global activity tracking from GEM to GT
As our global unpark/park keep track of the number of active users, we
can simply move the accounting from the GEM layer to the base GT layer.
It was placed originally inside GEM to benefit from the 100ms extra
delay on idleness, but that has been eliminated and now there is no
substantive difference between the layers. In moving it, we move another
piece of the puzzle out from underneath struct_mutex.
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/20191004134015.13204-13-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:06 +0000 (14:40 +0100)]
drm/i915: Move request runtime management onto gt
Requests are run from the gt and are tided into the gt runtime power
management, so pull the runtime request management under gt/
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/20191004134015.13204-12-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:05 +0000 (14:40 +0100)]
drm/i915/gem: Retire directly for mmap-offset shrinking
Now that we can retire without taking struct_mutex, we can do so to
handle shrinking the mmap-offset space after an allocation failure.
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: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-11-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:04 +0000 (14:40 +0100)]
drm/i915: Merge wait_for_timelines with retire_request
wait_for_timelines is essentially the same loop as retiring requests
(with an extra timeout), so merge the two into one routine.
v2: i915_retire_requests_timeout and keep VT'd w/a as !interruptible
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/20191004134015.13204-10-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:03 +0000 (14:40 +0100)]
drm/i915: Remove the GEM idle worker
Nothing inside the idle worker now requires struct_mutex, so we can
remove the indirection of using our own 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/20191004134015.13204-9-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:02 +0000 (14:40 +0100)]
drm/i915: Drop struct_mutex from around i915_retire_requests()
We don't need to hold struct_mutex now for retiring requests, so drop it
from i915_retire_requests() and i915_gem_wait_for_idle(), finally
removing I915_WAIT_LOCKED for good.
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/20191004134015.13204-8-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:01 +0000 (14:40 +0100)]
drm/i915: Move idle barrier cleanup into engine-pm
Now that we now longer need to guarantee that the active callback is
under the struct_mutex, we can lift it out of the i915_gem_park() and
into the engine parking itself.
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/20191004134015.13204-7-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:40:00 +0000 (14:40 +0100)]
drm/i915: Coordinate i915_active with its own mutex
Forgo the struct_mutex serialisation for i915_active, and interpose its
own mutex handling for active/retire.
This is a multi-layered sleight-of-hand. First, we had to ensure that no
active/retire callbacks accidentally inverted the mutex ordering rules,
nor assumed that they were themselves serialised by struct_mutex. More
challenging though, is the rule over updating elements of the active
rbtree. Instead of the whole i915_active now being serialised by
struct_mutex, allocations/rotations of the tree are serialised by the
i915_active.mutex and individual nodes are serialised by the caller
using the i915_timeline.mutex (we need to use nested spinlocks to
interact with the dma_fence callback lists).
The pain point here is that instead of a single mutex around execbuf, we
now have to take a mutex for active tracker (one for each vma, context,
etc) and a couple of spinlocks for each fence update. The improvement in
fine grained locking allowing for multiple concurrent clients
(eventually!) should be worth it in typical loads.
v2: Add some comments that barely elucidate anything :(
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/20191004134015.13204-6-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:39:59 +0000 (14:39 +0100)]
drm/i915: Push the i915_active.retire into a worker
As we need to use a mutex to serialise i915_active activation
(because we want to allow the callback to sleep), we need to push the
i915_active.retire into a worker callback in case we get need to retire
from an atomic context.
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/20191004134015.13204-5-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:39:58 +0000 (14:39 +0100)]
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
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/20191004134015.13204-4-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:39:57 +0000 (14:39 +0100)]
drm/i915: Mark up address spaces that may need to allocate
Since we cannot allocate underneath the vm->mutex (it is used in the
direct-reclaim paths), we need to shift the allocations off into a
mutexless worker with fence recursion prevention. To know when we need
this protection, we mark up the address spaces that do allocate before
insertion. In the future, we may wish to extend the async bind scheme to
more than just allocations.
v2: s/vm->bind_alloc/vm->bind_async_flags/
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/20191004134015.13204-3-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 13:39:56 +0000 (14:39 +0100)]
drm/i915: Only track bound elements of the GTT
The premise here is to simply avoiding having to acquire the vm->mutex
inside vma create/destroy to update the vm->unbound_lists, to avoid some
nasty lock recursions later.
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/20191004134015.13204-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 3 Oct 2019 21:00:58 +0000 (22:00 +0100)]
drm/i915: Use helpers for drm_mm_node booleans
A subset of
71724f708997 ("drm/mm: Use helpers for drm_mm_node booleans")
in order to prepare drm-intel-next-queued for subsequent patches before
we can backmerge
71724f708997 itself.
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/20191004142226.13711-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 4 Oct 2019 10:59:58 +0000 (11:59 +0100)]
drm/i915: Restrict L3 remapping sysfs interface to dwords
The L3 cache remapping is stored as u32 elements, and we should ensure
that the user only supplies complete slice information(u32).
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/20191004105958.1741-1-chris@chris-wilson.co.uk
Kai Vehmanen [Thu, 3 Oct 2019 08:55:31 +0000 (11:55 +0300)]
drm/i915: extend audio CDCLK>=2*BCLK constraint to more platforms
The CDCLK>=2*BCLK constraint applies to all generations since gen10.
Extend the constraint logic in audio get/put_power().
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003085531.30990-2-kai.vehmanen@linux.intel.com
Kai Vehmanen [Thu, 3 Oct 2019 08:55:30 +0000 (11:55 +0300)]
drm/i915: Fix audio power up sequence for gen10+ display
On platfroms with gen10+ display, driver must set the enable bit of
AUDIO_PIN_BUF_CTL register before transactions with the HDA controller
can proceed. Add setting this bit to the audio power up sequence.
Failing to do this resulted in errors during display audio codec probe,
and failures during resume from suspend.
Note: We may also need to disable the bit afterwards, but there are
still unresolved issues with that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111214
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003085531.30990-1-kai.vehmanen@linux.intel.com
Jani Nikula [Wed, 2 Oct 2019 14:41:38 +0000 (17:41 +0300)]
drm/i915/dp: remove static variable for aux last status
Add aux_busy_last_status to intel_dp. Don't bother with initializing to
all ones; the only difference is potentially missing logging for one
error case if the readout is all zeros.
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/20191002144138.7917-1-jani.nikula@intel.com
Chris Wilson [Thu, 3 Oct 2019 21:00:56 +0000 (22:00 +0100)]
drm/i915/execlists: Skip redundant resubmission
If we unwind the active requests, and on resubmission discover that we
intend to preempt the active contexts with themselves, simply skip the
ELSP submission.
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/20191003210100.22250-1-chris@chris-wilson.co.uk
Imre Deak [Wed, 2 Oct 2019 20:41:08 +0000 (23:41 +0300)]
drm/i915/tgl: Add the Thunderbolt PLL divider values
The Thunderbolt PLL divider values on TGL differ from the ICL ones,
update the PLL parameter calculation function accordingly.
Bspec: 49204
v2:
- Remove unused refclk config. (José)
Cc: Jose Souza <jose.souza@intel.com>
Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Mika Westerberg <mika.westerberg@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jose Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002204108.32242-1-imre.deak@intel.com
Jani Nikula [Wed, 2 Oct 2019 14:54:05 +0000 (17:54 +0300)]
drm/i915: use DRM_DEBUG_KMS() instead of drm_dbg(DRM_UT_KMS, ...)
Unify on current common usage to allow repurposing drm_dbg() later. Fix
newlines while at it.
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/20191002145405.27848-2-jani.nikula@intel.com
Jani Nikula [Wed, 2 Oct 2019 14:54:04 +0000 (17:54 +0300)]
drm/i915: use DRM_ERROR() instead of drm_err()
Unify on current common usage to allow repurposing drm_err() later. Fix
newlines while at it.
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/20191002145405.27848-1-jani.nikula@intel.com
Chris Wilson [Wed, 2 Oct 2019 18:34:59 +0000 (19:34 +0100)]
drm/i915/selftests: Exercise potential false lite-restore
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poisoning the ringbuffer of the first context and trying
to trick a simple RING_TAIL update (i.e. lite-restore)
v2: Also check what happens if preempt ce[0] with ce[1] (both instances
on the same engine from the same parent context) [Tvrtko]
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/20191002183459.26614-1-chris@chris-wilson.co.uk
José Roberto de Souza [Tue, 1 Oct 2019 19:37:29 +0000 (12:37 -0700)]
drm/i915/mg: Use tc_port instead of port parameter to MG registers
All the MG registers is based on the tc_port not port, so
MG_PHY_PORT_LN() was subtracting port and PORT_C what is very
fragile.
So replacing port to tc_port in all MG register macros and users
like we have for DKL.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191001193729.123736-1-jose.souza@intel.com
Ville Syrjälä [Mon, 8 Jul 2019 16:20:44 +0000 (19:20 +0300)]
drm/i915: Clean up encoder->crtc_mask setup
Use BIT(pipe) for better legibility when populating the crtc_mask
for encoders.
Also remove the redundant possible_crtcs setup for the TV encoder.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190708162048.4286-11-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 8 Jul 2019 16:20:42 +0000 (19:20 +0300)]
drm/i915: Populate possible_crtcs correctly
Don't advertize non-exisiting crtcs in the encoder possible_crtcs
bitmask.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190708162048.4286-9-ville.syrjala@linux.intel.com
Chris Wilson [Wed, 2 Oct 2019 12:30:14 +0000 (13:30 +0100)]
drm/i915/gem: Refactor tests on obj->ops->flags
We repeat obj->ops->flags in our object checks, so pull that into its
own little helper for clarity.
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/20191002123014.1545-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 2 Oct 2019 12:24:30 +0000 (13:24 +0100)]
drm/i915/selftests: Extract random_offset() for use with a prng
For selftests, we desire repeatability and so prefer using a prng with
known seed over true randomness. Extract random_offset() as a selftest
utility that can take the prng state.
Suggested-by: Matthew Auld <matthew.auld@intel.com>
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/20191002122430.23205-1-chris@chris-wilson.co.uk
Ville Syrjälä [Mon, 30 Sep 2019 18:30:45 +0000 (21:30 +0300)]
drm/i915: Fix g4x sprite scaling stride check with GTT remapping
I forgot to update the g4x sprite scaling stride check when GTT
remapping was introduced. The stride of the original framebuffer
is irrelevant when remapping is used and instead we want to check
the stride of the remapped view.
Also drop the duplicate width_bytes check. We already check that
a few lines earlier.
Fixes:
df79cf441910 ("drm/i915: Store the final plane stride in plane_state")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190930183045.662-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Ville Syrjälä [Tue, 1 Oct 2019 15:46:29 +0000 (18:46 +0300)]
drm/i915: Polish intel_tv_mode_valid()
Drop the tv_mode NULL check since intel_tv_mode_find() never
actually returns NULL, and flip the condition around so that
the MODE_OK case is at the end, which is customary to all
the other .mode_valid() implementations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191001154629.11063-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>