Chris Wilson [Thu, 19 Dec 2019 12:43:53 +0000 (12:43 +0000)]
drm/i915/gt: Track engine round-trip times
Knowing the round trip time of an engine is useful for tracking the
health of the system as well as providing a metric for the baseline
responsiveness of the engine. We can use the latter metric for
automatically tuning our waits in selftests and when idling so we don't
confuse a slower system with a dead one.
Upon idling the engine, we send one last pulse to switch the context
away from precious user state to the volatile kernel context. We know
the engine is idle at this point, and the pulse is non-preemptible, so
this provides us with a good measurement of the round trip time. It also
provides us with faster engine parking for ringbuffer submission, which
is a welcome bonus (e.g. softer-rc6).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191219105043.4169050-1-chris@chris-wilson.co.uk
Link: https://patchwork.freedesktop.org/patch/msgid/20191219124353.8607-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 19 Dec 2019 12:43:52 +0000 (12:43 +0000)]
drm/i915/gt: Schedule request retirement when signaler idles
Very similar to commit
4f88f8747fa4 ("drm/i915/gt: Schedule request
retirement when timeline idles"), but this time instead of coupling into
the execlists CS event interrupt, we couple into the breadcrumb
interrupt and queue a timeline's retirement when the last signaler is
completed. This should allow us to more rapidly park ringbuffer
submission, and so help reduce power consumption on older systems.
v2: Fixup intel_engine_add_retire() to handle concurrent callers
References:
4f88f8747fa4 ("drm/i915/gt: Schedule request retirement when timeline idles")
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>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191219124353.8607-1-chris@chris-wilson.co.uk
Jani Nikula [Thu, 12 Dec 2019 13:47:28 +0000 (15:47 +0200)]
drm/i915/dsc: fix DSC power domains for DSI
Fix several issues with DSC power domains that did not take DSI
transcoders into account:
- On TGL+ we need to use PW2 for DSC on pipe A, not transcoder A. There
is no longer an eDP transcoder, but there are two DSI transcoders
which may be connected to pipe A.
- On TGL+ we need to use the pipe, not transcoder, power domains for DSC
on pipes other than A. Again, there are DSI transcoders.
- On ICL we need to use PW2 for DSC also for DSI transcoders, not just
for the eDP transcoder.
Using is_pipe_dsc() also adds the warning about ICL pipe A DSC, which
does not exist.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212134728.18432-1-jani.nikula@intel.com
Jani Nikula [Wed, 11 Dec 2019 16:23:47 +0000 (18:23 +0200)]
drm/i915/dsc: clarify DSC support for pipe A on ICL
The check for cpu_transcoder != TRANSCODER_A is more magic than
necessary, and potentially misleading. Before TGL, DSC is supported on
pipe A if, and only if, it's used with eDP or DSI transcoders. No
functional changes.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f00e9d55ce20b256177222588780c660aa587cc3.1576081155.git.jani.nikula@intel.com
Jani Nikula [Wed, 11 Dec 2019 16:23:46 +0000 (18:23 +0200)]
drm/i915/dsc: fix DSC register selection for ICL DSI transcoders
ICL eDP and DSI transcoders have a DSC engine separate from the
pipe. Abstract the register selection and fix it for ICL.
Add a warning for pipe A DSC on ICL; it does not exist.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/01bcddcdf397b1c8eb859ed18ebe023fb64383d9.1576081155.git.jani.nikula@intel.com
Andrzej Pietrasiewicz [Thu, 28 Nov 2019 15:01:30 +0000 (16:01 +0100)]
drm/i915: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128150130.26266-1-andrzej.p@collabora.com
Lucas De Marchi [Tue, 17 Dec 2019 23:05:29 +0000 (15:05 -0800)]
drm/i915/display: fix phy name
Pass the correct variable as argument.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217230529.25092-3-lucas.demarchi@intel.com
Lucas De Marchi [Tue, 17 Dec 2019 23:05:28 +0000 (15:05 -0800)]
drm/i915/display: use clk_off name to avoid double negation
Instead of "ungated" use the same name for the variable as the bitfield,
making it clearer what's the intent of the checks.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217230529.25092-2-lucas.demarchi@intel.com
Lucas De Marchi [Tue, 17 Dec 2019 23:05:27 +0000 (15:05 -0800)]
drm/i915/display: move clk off sanitize to its own function
This allows us to isolate reading and writing to the
ICL_DPCLKA_CFGCR0 during the sanitize phase.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217230529.25092-1-lucas.demarchi@intel.com
Chris Wilson [Wed, 18 Dec 2019 09:40:57 +0000 (09:40 +0000)]
drm/i915: Ratelimit i915_globals_park
When doing our global park, we like to be a good citizen and shrink our
slab caches (of which we have quite a few now), but each
kmem_cache_shrink() incurs a stop_machine() and so ends up being quite
expensive, causing machine-wide stalls. While ideally we would like to
throw away unused pages in our slab caches whenever it appears that we
are idling, doing so will require a much cheaper mechanism. In the
meantime use a delayed worked to impose a rate-limit that means we have
to have been idle for more than 2 seconds before we start shrinking.
References: https://gitlab.freedesktop.org/drm/intel/issues/848
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/20191218094057.3510459-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 17 Dec 2019 09:56:41 +0000 (09:56 +0000)]
drm/i915/gt: Remove direct invocation of breadcrumb signaling
Only signal the breadcrumbs from inside the irq_work, simplifying our
interface and calling conventions. The micro-optimisation here is that
by always using the irq_work interface, we know we are always inside an
irq-off critical section for the breadcrumb signaling and can ellide
save/restore of the irq flags.
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/20191217095642.3124521-7-chris@chris-wilson.co.uk
Tvrtko Ursulin [Tue, 17 Dec 2019 14:20:57 +0000 (14:20 +0000)]
drm/i915/pmu: Ensure monotonic rc6
Avoid rc6 counter going backward in close to 0% RC6 scenarios like:
15.
005477996 114,246,613 ns i915/rc6-residency/
16.
005876662 667,657 ns i915/rc6-residency/
17.
006131417 7,286 ns i915/rc6-residency/
18.
006615031 18,446,744,073,708,914,688 ns i915/rc6-residency/
19.
007158361 18,446,744,073,709,447,168 ns i915/rc6-residency/
20.
007806498 0 ns i915/rc6-residency/
21.
008227495 1,440,403 ns i915/rc6-residency/
There are two aspects to this fix.
First is not assuming rc6 value zero means GT is asleep since that can
also mean GPU is fully busy and we do not want to enter the estimation
path in that case.
Second is ensuring monotonicity on the estimation path itself. I suspect
what is happening is with extremely rapid park/unpark cycles we get no
updates on the real rc6 and therefore have to careful not to
unconditionally trust use last known real rc6 when creating a new
estimation.
v2:
* Simplify logic by not tracking the estimate but last reported value.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes:
16ffe73c186b ("drm/i915/pmu: Use GT parked for estimating RC6 while asleep")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217142057.1000-1-tvrtko.ursulin@linux.intel.com
Ville Syrjälä [Fri, 13 Dec 2019 19:52:17 +0000 (21:52 +0200)]
drm/i915: Move stuff from haswell_crtc_disable() into encoder .post_disable()
Move all of haswell_crtc_disable() into the encoder
.post_disable() hooks. Now we're left with just
calling the .disable() and .post_disable() hooks
back to back.
I chose to move the code into the .post_disable() hook instead
of the .disable() hook as most of the sequence is currently
implemented in the .post_disable() hook.
We should collapse it all down to just one hook and then the
encoders can drive the modeset sequence fully. But that may
need some further refactoring as we currently call the
ddi .post_disable() hook from mst code and we can't just
replace that with a call to the ddi .disable() hook.
Should also follow up with similar treatment for the enable
sequence but let's start here where it's easier.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: 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/20191213195217.15168-5-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Fri, 13 Dec 2019 19:52:16 +0000 (21:52 +0200)]
drm/i915: Pass old crtc state to intel_crtc_vblank_off()
To make life easier in the future let's pass the old crtc state
to intel_crtc_vblank_off() just like we already do for its
counterpart intel_crtc_vblank_on().
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: 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/20191213195217.15168-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Fri, 13 Dec 2019 19:52:15 +0000 (21:52 +0200)]
drm/i915: Pass old crtc state to skylake_scaler_disable()
To make life easier in the future let's pass the old crtc state
to skylake_scaler_disable() just like we already do for
for its ancestor ironlake_pfit_disable().
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: 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/20191213195217.15168-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Fri, 13 Dec 2019 19:52:14 +0000 (21:52 +0200)]
drm/i915: Nuke .post_pll_disable() for DDI platforms
HSW+ platforms call encoder .post_disable() and .post_pll_disable()
back to back. And since we don't even disable the PLL in between
let's just move everything into .post_disable().
intel_dp_mst does forward the .post_disable() call to intel_ddi at
the very end of its own .post_disable() hook, so this time MST
I shouldn't even break MST by accident.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: 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/20191213195217.15168-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Fri, 13 Dec 2019 19:52:13 +0000 (21:52 +0200)]
drm/i915: Call hsw_fdi_link_train() directly()
Remove the pointless vfunc detour for hsw_fdi_link_train()
and just call it directly. Also pass the encoder in so we
can nuke the silly encoder loop within.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: 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/20191213195217.15168-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Thu, 7 Nov 2019 14:24:17 +0000 (16:24 +0200)]
drm/i915: Introduce intel_plane_state_reset()
For the sake of symmetry with the crtc stuff let's add
a helper to reset the plane state to sane default values.
For the moment this only gets caller from the plane init.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107142417.11107-5-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Thu, 7 Nov 2019 14:24:16 +0000 (16:24 +0200)]
drm/i915: Introduce intel_crtc_state_reset()
We have a few places where we want to reset a crtc state to its
default values. Let's add a helper for that. We'll need the new
__drm_atomic_helper_crtc_state_reset() helper for this to allow
us to just reset the state itself without clobbering the
crtc->state pointer.
And while at it let's zero out the whole thing, except a few
choice member which we'll mark as "invalid". And thanks to this
we can now nuke intel_crtc_init_scalers().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107142417.11107-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Thu, 7 Nov 2019 14:24:15 +0000 (16:24 +0200)]
drm/i915: Introduce intel_crtc_{alloc,free}()
We already have alloc/free helpers for planes, add the same for
crtcs. The main benefit is we get to move all the annoying state
initialization out of the main crtc_init() flow.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107142417.11107-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Thu, 7 Nov 2019 14:24:14 +0000 (16:24 +0200)]
drm/i915: s/intel_crtc/crtc/ in intel_crtc_init()
Let's get rid of the redundant intel_ prefix on our variables.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107142417.11107-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Thu, 7 Nov 2019 14:24:13 +0000 (16:24 +0200)]
drm: Add __drm_atomic_helper_crtc_state_reset() & co.
Annoyingly __drm_atomic_helper_crtc_reset() does two
totally separate things:
a) reset the state to defaults values
b) assign the crtc->state pointer
I just want a) without the b) so let's split out part
a) into __drm_atomic_helper_crtc_state_reset(). And
of course we'll do the same thing for planes and connectors.
v2: Fix conn__state vs. conn_state typo (Lucas)
Make code and kerneldoc match for
__drm_atomic_helper_plane_state_reset()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107142417.11107-1-ville.syrjala@linux.intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 18 Dec 2019 09:35:04 +0000 (09:35 +0000)]
drm/i915/gt: Ratelimit display power w/a
For very light workloads that frequently park, acquiring the display
power well (required to prevent the dmc from trashing the system) takes
longer than the execution. A good example is the igt_coherency selftest,
which is slowed down by an order of magnitude in the worst case with
powerwell cycling. To prevent frequent cycling, while keeping our fast
soft-rc6, use a timer to delay release of the display powerwell.
Fixes:
311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles")
References: https://gitlab.freedesktop.org/drm/intel/issues/848
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/20191218093504.3477048-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 18 Dec 2019 10:40:43 +0000 (10:40 +0000)]
drm/i915: Hold reference to intel_frontbuffer as we track activity
Since obj->frontbuffer is no longer protected by the struct_mutex, as we
are processing the execbuf, it may be removed. Mark the
intel_frontbuffer as rcu protected, and so acquire a reference to
the struct as we track activity upon it.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/827
Fixes:
8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: <stable@vger.kernel.org> # v5.4+
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191218104043.3539458-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 18 Dec 2019 00:07:56 +0000 (00:07 +0000)]
drm/i915/pmu: Skip sampling engines if gt is asleep
If the whole GT is asleep, we know that each engine must also be asleep
and so we can quickly return without checking them all.
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/20191218000756.3475668-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 16 Dec 2019 16:17:16 +0000 (16:17 +0000)]
drm/i915: Unpin vma->obj on early error
If we inherit an error along the fence chain, we skip the main work
callback and go straight to the error. In the case of the vma bind
worker, we only dropped the pinned pages from the worker.
In the process, make sure we call the release earlier rather than wait
until the final reference to the fence is dropped (as a reference is
kept while being listened upon).
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/20191216161717.2688274-1-chris@chris-wilson.co.uk
Daniele Ceraolo Spurio [Tue, 17 Dec 2019 01:23:15 +0000 (17:23 -0800)]
drm/i915/guc: Unify notify() functions
The Gen11+ and the legacy function differ in the register and value
written to interrupt the GuC. However, while on older gen the value
matches a bit on the register, on Gen11+ the value is a SW defined
payload that is sent to the FW. Since the FW behaves the same no matter
what value we pass to it, we can just write the same thing on all gens
and get rid of the function pointer by saving the register offset.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217012316.13271-6-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 17 Dec 2019 01:23:14 +0000 (17:23 -0800)]
drm/i915/guc: Remove function pointers for send/receive calls
Since we started using CT buffers on all gens, the function pointers can
only be set to either the _nop() or the _ct() functions. Since the
_nop() case applies to when the CT are disabled, we can just handle that
case in the _ct() functions and call them directly.
v2: keep intel_guc_send() and make the CT send/receive functions work on
intel_guc_ct. (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217012316.13271-5-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 17 Dec 2019 01:23:13 +0000 (17:23 -0800)]
drm/i915/guc/ct: Group request-related variables in a sub-structure
For better isolation of the request tracking from the rest of the
CT-related data.
v2: split to separate patch, move next_fence to substructure (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217012316.13271-4-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 17 Dec 2019 01:23:12 +0000 (17:23 -0800)]
drm/i915/guc/ct: Stop expecting multiple CT channels
The GuC supports having multiple CT buffer pairs and we designed our
implementation with that in mind. However, the different channels are not
processed in parallel within the GuC, so there is very little advantage
in having multiple channels (independent locks?), compared to the
drawbacks (one channel can starve the other if messages keep being
submitted to it). Given this, it is unlikely we'll ever add a second
channel and therefore we can simplify our code by removing the
flexibility.
v2: split substructure grouping to separate patch, improve docs (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217012316.13271-3-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 17 Dec 2019 01:23:11 +0000 (17:23 -0800)]
drm/i915/guc/ct: Drop guards in enable/disable calls
We track the status of the GuC much more closely now and we expect the
enable/disable functions to be correctly called only once. If this isn't
true we do want to flag it as a flow failure (via the BUG_ON in the ctch
functions) and not silently ignore the call.
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217012316.13271-2-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 17 Dec 2019 01:23:10 +0000 (17:23 -0800)]
drm/i915/guc: Merge communication_stop and communication_disable
The only difference from the GuC POV between guc_communication_stop and
guc_communication_disable is that the former can be called after GuC
has been reset. Instead of having two separate paths, we can just skip
the call into GuC in the disabling path and re-use that.
Note that by using the disable() path instead of the stop() one there
are two additional changes in SW side for the stop path:
- interrupts are now disabled before disabling the CT, which is ok
because we do not want interrupts with CT disabled;
- guc_get_mmio_msg() is called in the stop case as well, which is ok
because if there are errors before the reset we do want to record
them.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217012316.13271-1-daniele.ceraolospurio@intel.com
Tvrtko Ursulin [Tue, 17 Dec 2019 17:09:33 +0000 (17:09 +0000)]
drm/i915: Fix pid leak with banned clients
Get_pid_task() needs to be paired with a put_pid or we leak a pid
reference every time a banned client tries to create a context.
v2:
* task_pid_nr helper exists! (Chris)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes:
b083a0870c79 ("drm/i915: Add per client max context ban limit")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@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/20191217170933.8108-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Tue, 17 Dec 2019 01:16:59 +0000 (01:16 +0000)]
drm/i915/gt: Eliminate the trylock for reading a timeline's hwsp
As we stash a pointer to the HWSP cacheline on the request, when reading
it we only need confirm that the cacheline is still valid by checking
that the request and timeline are still intact.
v2: Protect hwsp_cachline with RCU
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/20191217011659.3092130-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 17 Dec 2019 13:47:29 +0000 (13:47 +0000)]
drm/i915/gem: Keep request alive while attaching fences
Since commit
e5dadff4b093 ("drm/i915: Protect request retirement with
timeline->mutex"), the request retirement can happen outside of the
struct_mutex serialised only by the timeline->mutex. We drop the
timeline->mutex on submitting the request (i915_request_add) so after
that point, it is liable to be freed. Make sure our local reference is
kept alive until we have finished attaching it to the signalers. (Note
that this erodes the argument that i915_request_add should consume the
reference, but that is a slightly larger patch!)
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: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217134729.3297818-1-chris@chris-wilson.co.uk
Hans de Goede [Mon, 16 Dec 2019 20:29:06 +0000 (21:29 +0100)]
drm/i915: DSI: select correct PWM controller to use based on the VBT
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped registering the LPSS PWM
controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
present, assuming that in this case the PMIC PWM controller will be used.
On CHT we have been relying on only 1 of the 2 PWM controllers being
enabled in the DSDT at the same time; and always registered the lookup.
So far this has been working, but the correct way to determine which PWM
controller needs to be used is by checking a bit in the VBT table and
recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012
Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.
This commit fixes using the wrong PWM controller on these devices by
calling pwm_get() for the right PWM controller based on the
VBT dsi.config.pwm_blc bit.
Note this is part of a series which contains 2 other patches which renames
the PWM lookup for the 1st SoC/LPSS PWM from "pwm_backlight" to
"pwm_pmic_backlight" and the PWM lookup for the Crystal Cove PMIC PWM
from "pwm_backlight" to "pwm_pmic_backlight".
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-4-hdegoede@redhat.com
Hans de Goede [Mon, 16 Dec 2019 20:29:05 +0000 (21:29 +0100)]
mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped registering the LPSS PWM
controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
present, assuming that in this case the PMIC PWM controller will be used.
On CHT we have been relying on only 1 of the 2 PWM controllers being
enabled in the DSDT at the same time; and always registered the lookup.
So far this has been working, but the correct way to determine which PWM
controller needs to be used is by checking a bit in the VBT table and
recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012
Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.
Since only the i915 driver has access to the VBT, this commit renames
the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM
controller to "pwm_pmic_backlight" so that the i915 driver can do a
pwm_get() for the right controller depending on the VBT bit, instead of
the i915 driver relying on a "pwm_backlight" lookup getting registered
which magically points to the right controller.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-3-hdegoede@redhat.com
Hans de Goede [Mon, 16 Dec 2019 20:29:04 +0000 (21:29 +0100)]
ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc_backlight
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped registering the LPSS PWM
controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
present, assuming that in this case the PMIC PWM controller will be used.
On CHT we have been relying on only 1 of the 2 PWM controllers being
enabled in the DSDT at the same time; and always registered the lookup.
So far this has been working, but the correct way to determine which PWM
controller needs to be used is by checking a bit in the VBT table and
recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012
Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.
Since only the i915 driver has access to the VBT, this commit renames
the "pwm_backlight" lookup entries for the 1st BYT/CHT LPSS PWM controller
to "pwm_soc_backlight" so that the i915 driver can do a pwm_get() for
the right controller depending on the VBT bit, instead of the i915 driver
relying on a "pwm_backlight" lookup getting registered which magically
points to the right controller.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-2-hdegoede@redhat.com
Chris Wilson [Tue, 17 Dec 2019 09:13:28 +0000 (09:13 +0000)]
drm/i915/gt: Avoid multi-LRI on Sandybridge
Sandybridge is the gen that didn't handle multiple registers in a single
LRI packet. Don't forget it!
Fixes:
902eb748e5c3 ("drm/i915/gt: Tidy up full-ppgtt on Ivybridge")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217091328.3093551-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 16 Dec 2019 16:53:17 +0000 (16:53 +0000)]
drm/i915: Eliminate the trylock for awaiting an earlier request
We currently use an error-prone mutex_trylock to grab another timeline
to find an earlier request along it. However, with a bit of a
sleight-of-hand, we can reduce the mutex_trylock to a spin_lock on the
immediate request and careful pointer chasing to acquire a reference on
the previous request.
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/20191216165317.2742896-1-chris@chris-wilson.co.uk
Maya Rashish [Fri, 13 Dec 2019 10:26:30 +0000 (10:26 +0000)]
Correct function name in comment
Signed-off-by: Maya Rashish <coypu@sdf.org>
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/20191213102630.GA24082@SDF.ORG
Chris Wilson [Mon, 16 Dec 2019 14:24:09 +0000 (14:24 +0000)]
drm/i915/gt: Tidy up full-ppgtt on Ivybridge
With a couple more memory barriers dotted around the place we can
significantly reduce the MTBF on Ivybridge. Still doesn't really help
Haswell though.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191216142409.2605211-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 16 Dec 2019 12:26:03 +0000 (12:26 +0000)]
drm/i915/gem: Apply lmem size restriction to get_pages
When creating a handle, it is just that, an abstract handle. The fact
that we cannot currently support a handle larger than the size of the
backing storage is an artifact of our whole-object-at-a-time handling in
get_pages() and being an implementation limitation is best handled at
that point -- similar to shmem, where we only barf when asked to
populate the whole object if larger than RAM. (Pinning the whole object
at a time is major hindrance that we are likely to have to overcome in
the near future.) In the case of the buddy allocator, the late check is
preferable as the request size may often be smaller than the required
size.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191216122603.2598155-1-chris@chris-wilson.co.uk
Venkata Sandeep Dhanalakota [Mon, 16 Dec 2019 18:53:32 +0000 (10:53 -0800)]
drm/i915: Fix typecheck macro in GT_TRACE
typecheck() macro creates an huge stack size causing
issues with static analysis with coverity, addressing
this with creating a local pointer.
Fixes:
639f2f24895f ("drm/i915: Introduce new macros for tracing")
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@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/20191216185332.83289-1-venkata.s.dhanalakota@intel.com
zhengbin [Mon, 16 Dec 2019 03:44:05 +0000 (11:44 +0800)]
drm/i915: Remove unneeded semicolon
Fixes coccicheck warning:
drivers/gpu/drm/i915/gem/i915_gem_region.c:88:2-3: Unneeded semicolon
drivers/gpu/drm/i915/gvt/gtt.c:1285:2-3: Unneeded semicolon
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Acked-by: Zhenyu Wang <zhenyuw@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/1576467845-60920-1-git-send-email-zhengbin13@huawei.com
Vandita Kulkarni [Mon, 16 Dec 2019 08:06:19 +0000 (13:36 +0530)]
drm/i915: Fix WARN_ON condition for cursor plane ddb allocation
In some cases like latency[level]==0, wm[level].res_lines>31,
min_ddb_alloc can be U16_MAX, exclude it from the WARN_ON.
v2: Specify the cases in which we hit U16_MAX, indentation (Ville)
Fixes:
10a7e07b68b9 ("drm/i915: Make sure cursor has enough ddb for the selected wm level")
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191216080619.10945-1-vandita.kulkarni@intel.com
Hans de Goede [Thu, 12 Dec 2019 20:48:28 +0000 (21:48 +0100)]
drm/i915: opregion: set opregion chpd value to indicate the driver handles hotplug
According to both the old acpi_igd_opregion_spec_0.pdf and the newer
skl_opregion_rev0p5.pdf opregion specification documents, if a driver
handles hotplug events itself, it should set the opregion CHPD field to
1 to indicate this and the firmware should respond to this by no longer
sending ACPI 0x00 notification events on e.g. lid-state changes.
Specifically skl_opregion_rev0p5.pdf states thid in the documentation of
the CHPD word: "Re-enumeration trigger logic in System BIOS MUST be
disabled for all the Operating Systems supporting Hot-Plug
(e.g., Windows* Longhorn and above)." Note the MUST in there.
We ignore these notifications, so this should not be a problem but many
recent DSTDs seem to all have the same copy-pasted bug in the GNOT() AML
function which is used to send these notifications. Windows likely does not
hit this bug as it presumably correcty sets CHPD to 1.
Here is an example of the broken GNOT() method:
Method (GNOT, 2, NotSerialized)
{
...
CEVT = Arg0
CSTS = 0x03
If (((CHPD == Zero) && (Arg1 == Zero)))
{
If (((OSYS > 0x07D0) || (OSYS < 0x07D6)))
{
Notify (PCI0, Arg1)
}
Else
{
Notify (GFX0, Arg1)
}
}
...
Notice that the condition for the If is always true I believe that the
|| like needs to be an &&, but there is nothing we can do about this and
in my own DSDT archive 55 of the 93 DSDTs have this issue.
When the if is true the notification gets send to the PCI root instead
of only to the GFX0 device. This causes Linux to re-enumerate PCI devices
whenever the LID opens / closes, leading to unexpected messages in dmesg:
Suspend through lid close:
[ 313.598199] intel_atomisp2_pm 0000:00:03.0: Refused to change power state, currently in D3
[ 313.664453] intel_atomisp2_pm 0000:00:03.0: Refused to change power state, currently in D3
[ 313.737982] pci_bus 0000:01: Allocating resources
[ 313.738036] pcieport 0000:00:1c.0: bridge window [io 0x1000-0x0fff] to [bus 01] add_size 1000
[ 313.738051] pcieport 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000 add_align 100000
[ 313.738111] pcieport 0000:00:1c.0: BAR 15: assigned [mem 0x91000000-0x911fffff 64bit pref]
[ 313.738128] pcieport 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff]
Resume:
[ 813.623894] pci 0000:00:03.0: [8086:22b8] type 00 class 0x048000
[ 813.623955] pci 0000:00:03.0: reg 0x10: [mem 0x00000000-0x003fffff]
[ 813.630477] pci 0000:00:03.0: BAR 0: assigned [mem 0x91c00000-0x91ffffff]
[ 854.579101] intel_atomisp2_pm 0000:00:03.0: Refused to change power state, currently in D3
And more importantly this re-enumeration races with suspend/resume causing
enumeration to not be complete when assert_isp_power_gated() from
drivers/gpu/drm/i915/display/intel_display_power.c runs. This causes
the !pci_dev_present(isp_ids) check in assert_isp_power_gated() to fail
making the condition for the WARN true, leading to:
[ 813.327886] ------------[ cut here ]------------
[ 813.327898] ISP not power gated
[ 813.328028] WARNING: CPU: 2 PID: 2317 at drivers/gpu/drm/i915/display/intel_display_power.c:4870 intel_display_print_error_state+0x2b98/0x3a80 [i915]
...
[ 813.328599] ---[ end trace
f01e81b599596774 ]---
This commit fixes the unwanted ACPI notification on the PCI root device
by setting CHPD to 1, so that the broken if condition in the AML never
gets checked as notifications of type 0x00 are disabled altogether.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212204828.191288-1-hdegoede@redhat.com
Chris Wilson [Fri, 13 Dec 2019 22:31:40 +0000 (22:31 +0000)]
drm/i915/gem: Serialise object before changing cache-level
Wait for the object to be idle before changing its cache-level and
unbinding. This was dropped as supposedly superfluous from commit
8b1c78e06e61 ("drm/i915: Avoid calling i915_gem_object_unbind holding
object lock"), but it turns out to prevent some cache dirt escaping.
Smells like papering over a race...
Closes: https://gitlab.freedesktop.org/drm/intel/issues/820
Fixes:
8b1c78e06e61 ("drm/i915: Avoid calling i915_gem_object_unbind holding object lock")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213223140.1830738-1-chris@chris-wilson.co.uk
Jani Nikula [Wed, 11 Dec 2019 11:08:44 +0000 (13:08 +0200)]
drm/i915/dsi: fix pipe D readout for DSI transcoders
Commit
4d89adc7b56f ("drm/i915/display/dsi: Add support to pipe D")
added pipe D support for DSI, but failed to update the state readout.
Fixes:
4d89adc7b56f ("drm/i915/display/dsi: Add support to pipe D")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191211110844.2996-1-jani.nikula@intel.com
Lucas De Marchi [Fri, 6 Dec 2019 19:05:52 +0000 (11:05 -0800)]
drm/i915/bios: remove extra debug messages
Just like in commit
523e0cc89b83 ("drm/i915/tgl: allow DVI/HDMI on port
A"), the port checks when reading the VBT can easily not match what the
platform really exposes. However here we only have some additional debug
messages that are not adding much value: in the previous debug message
we already print everything we know about the VBT.
Instead of keep fixing the possible port assignments according to the
platform, just nuke the additional messages.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206190552.8818-1-lucas.demarchi@intel.com
Andi Shyti [Fri, 13 Dec 2019 18:37:35 +0000 (20:37 +0200)]
drm/i915/rps: Add frequency translation helpers
Add two helpers that for reading the actual GT's frequency. The
two helpers are:
- intel_rps_read_cagf: reads the frequency and returns it not
normalized
- intel_rps_read_actual_frequency: provides the frequency in Hz.
Use the above helpers in sysfs and debugfs.
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213183736.31992-2-andi@etezian.org
Chris Wilson [Fri, 13 Dec 2019 16:03:47 +0000 (16:03 +0000)]
drm/i915: Use EAGAIN for trylock failures
While not good behaviour, it is, however, established behaviour that we
can punt EAGAIN to userspace if we need to retry the ioctl. When trying
to acquire a mutex, prefer to use EAGAIN to propagate losing the race
so that if it does end up back in userspace, we try again.
Fixes:
c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across submit fences")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/800
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213160347.1789004-1-chris@chris-wilson.co.uk
Venkata Sandeep Dhanalakota [Fri, 13 Dec 2019 15:51:52 +0000 (07:51 -0800)]
drm/i915: Introduce new macros for tracing
New macros ENGINE_TRACE(), CE_TRACE(), RQ_TRACE() and
GT_TRACE() are introduce to tag device name and engine
name with contexts and requests tracing in i915.
Cc: Sudeep Dutt <sudeep.dutt@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@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/20191213155152.69182-2-venkata.s.dhanalakota@intel.com
Venkata Sandeep Dhanalakota [Fri, 13 Dec 2019 15:51:51 +0000 (07:51 -0800)]
drm/i915/perf: Register sysctl path globally
We do not require to register the sysctl paths per instance,
so making registration global.
v2: make sysctl path register and unregister function driver
specific (Tvrtko and Lucas).
Cc: Sudeep Dutt <sudeep.dutt@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@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/20191213155152.69182-1-venkata.s.dhanalakota@intel.com
Matt Roper [Fri, 13 Dec 2019 01:06:00 +0000 (17:06 -0800)]
drm/i915/icl: Cleanup combo PHY aux power well handlers
Now that the combo PHY aux power well handlers are used exclusively on
Icelake, we can drop a bunch of the extra tests.
v2: Don't try to use intel_uncore_rmw for register updates yet; there's
pending display uncore patches that need to land first. (Lucas)
v3: Drop the combo phy assertion. It was backward before, but doesn't
seem terribly necessary. I'm keeping the IS_ICELAKE assertion
though since we often copy/paste/modify the power well tables when
defining new platforms and it's too easy to cargo cult the
ICL-specific handling to new platforms that shouldn't use it.
(Lucas)
v4: Fix build; forgot to commit all the changes. (CI)
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/20191213010600.701315-1-matthew.d.roper@intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Matt Roper [Fri, 13 Dec 2019 00:15:10 +0000 (16:15 -0800)]
drm/i915/tgl: Drop Wa#1178
The TGL workaround database no longer shows Wa #1178 (or anything
similar under different workaround names/numbers) so we should be able
to drop it. In fact Swati just discovered that applying this workaround
is the root cause of some power well enable failures we've been seeing
in CI (gitlab issue 498).
Once we stop applying this WA, TGL no longer utilizes any of the special
handling provided by icl_combo_phy_aux_power_well_ops so we can just
drop back to using the standard hsw-style power well ops instead.
v3: Drop now-unused _TGL_AUX_ANAOVRD1_C definition too. (Lucas)
Closes: https://gitlab.freedesktop.org/drm/intel/issues/498
Fixes:
deea06b47574 ("drm/i915/tgl: apply Display WA #1178 to fix type C dongles")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Swati Sharma <swati2.sharma@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213001511.678070-3-matthew.d.roper@intel.com
Matt Roper [Fri, 13 Dec 2019 00:15:09 +0000 (16:15 -0800)]
drm/i915/ehl: Define EHL powerwells independently of ICL
Outputs C and D on EHL are combo PHY outputs and thus should not be
using the same TC AUX power well handlers as ICL. And even though
icl_combo_phy_aux_power_well_ops works okay for EHL/JSL combo PHYs none
of its special handling is actually necessary for this platform:
* EHL/JSL don't actually need to program PORT_CL_DW12
* Display WA #1178 does not apply to EHL/JSL
Thus we can simply drop back to using our standard "hsw-style" power
well ops for EHL AUX power wells.
Bspec: 4301
Fixes:
f722b8c1e2a2 ("drm/i915/ehl: All EHL ports are combo phys")
Cc: Jose Souza <jose.souza@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: Vivek Kasireddy <vivek.kasireddy@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/20191213001511.678070-2-matthew.d.roper@intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Dan Carpenter [Fri, 13 Dec 2019 10:50:50 +0000 (13:50 +0300)]
drm/i915/selftests: remove a condition
We know that "err" is non-zero so there is no need to check.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.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/20191213105050.y2v5nylsuxvc44jj@kili.mountain
Dan Carpenter [Thu, 12 Dec 2019 09:11:30 +0000 (12:11 +0300)]
drm/i915/bios: fix off by one in parse_generic_dtd()
The "num_dtd" variable is the number of elements in the
generic_dtd->dtd[] array so the > needs to be >= to prevent reading one
element beyond the end of the array.
Fixes:
33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212091130.zf2g53njf5u24wk6@kili.mountain
Ville Syrjälä [Tue, 10 Dec 2019 14:41:02 +0000 (16:41 +0200)]
drm/i915: Streamline skl_commit_modeset_enables()
skl_commit_modeset_enables() is a bit of mess. Let's streamline
it by simply tracking which pipes still need to be updated.
As a bonus we get rid of the state->wm_results.dirty_pipes usage.
v2: Rebase due to port sync
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191210144105.3239-2-ville.syrjala@linux.intel.com
Lee Shawn C [Tue, 10 Dec 2019 15:04:15 +0000 (23:04 +0800)]
drm/i915/cml: Separate U series pci id from origianl list.
U series device need different DDI buffer setup for eDP
and DP. If driver did not recognize ULT id proerply.
The setting for H and S series would be used.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191210150415.10705-2-shawn.c.lee@intel.com
Lee Shawn C [Tue, 10 Dec 2019 15:04:14 +0000 (23:04 +0800)]
drm/i915/cml: Remove unsupport PCI ID
commit '
a7b4deeb02b9 ("drm/i915/cml: Add CML PCI IDS)'
introduced new PCI ID that CML support. But some PCI
IDs were removed in BSpec for CML. This patch is used
to eliminate the unsed ID.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191210150415.10705-1-shawn.c.lee@intel.com
Chris Wilson [Thu, 12 Dec 2019 14:04:33 +0000 (14:04 +0000)]
drm/i915/gt: Mark up ips_mchdev pointer access
drivers/gpu/drm/i915/gt/intel_rps.c:1726:24: error: incompatible types in comparison expression (different address spaces):
drivers/gpu/drm/i915/gt/intel_rps.c:1726:24: struct drm_i915_private [noderef] <asn:4> *
drivers/gpu/drm/i915/gt/intel_rps.c:1726:24: struct drm_i915_private *
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212140459.1307617-7-chris@chris-wilson.co.uk
Chris Wilson [Thu, 12 Dec 2019 15:42:24 +0000 (15:42 +0000)]
drm/i915: Set fence_work.ops before dma_fence_init
Since dma_fence_init may call ops (because of a meaningless
trace_dma_fence), we need to set the worker ops prior to that call.
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Fixes:
8e458fe2ee05 ("drm/i915: Generalise the clflush dma-worker")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212154224.1631531-1-chris@chris-wilson.co.uk
Michal Wajdeczko [Thu, 12 Dec 2019 12:19:03 +0000 (12:19 +0000)]
drm/i915: Improve i915_inject_probe_error macro
On non-debug builds we were not using i915 param and thus
we may cause "unused variable" warning/error if caller was
not using i915 elsewhere. Let compiler see this param.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@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/20191212121903.72524-1-michal.wajdeczko@intel.com
Chris Wilson [Wed, 11 Dec 2019 23:08:57 +0000 (23:08 +0000)]
drm/i915/gem: Asynchronous cmdparser
Execute the cmdparser asynchronously as part of the submission pipeline.
Using our dma-fences, we can schedule execution after an asynchronous
piece of work, so we move the cmdparser out from under the struct_mutex
inside execbuf as run it as part of the submission pipeline. The same
security rules apply, we copy the user batch before validation and
userspace cannot touch the validation shadow. The only caveat is that we
will do request construction before we complete cmdparsing and so we
cannot know the outcome of the validation step until later -- so the
execbuf ioctl does not report -EINVAL directly, but we must cancel
execution of the request and flag the error on the out-fence.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/611
Closes: https://gitlab.freedesktop.org/drm/intel/issues/412
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/20191211230858.599030-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 11 Dec 2019 23:08:56 +0000 (23:08 +0000)]
drm/i915/gem: Prepare gen7 cmdparser for async execution
The gen7 cmdparser is primarily a promotion-based system to allow access
to additional registers beyond the HW validation, and allows fallback to
normal execution of the user batch buffer if valid and requires
chaining. In the next patch, we will do the cmdparser validation in the
pipeline asynchronously and so at the point of request construction we
will not know if we want to execute the privileged and validated batch,
or the original user batch. The solution employed here is to execute
both batches, one with raised privileges and one as normal. This is
because the gen7 MI_BATCH_BUFFER_START command cannot change privilege
level within a batch and must strictly use the current privilege level
(or undefined behaviour kills the GPU). So in order to execute the
original batch, we need a second non-priviledged batch buffer chain from
the ring, i.e. we need to emit two batches for each user batch. Inside
the two batches we determine which one should actually execute, we
provide a conditional trampoline to call the original batch.
Implementation-wise, we create a single buffer and write the shadow and
the trampoline inside it at different offsets; and bind the buffer into
both the kernel GGTT for the privileged execution of the shadow and into
the user ppGTT for the non-privileged execution of the trampoline and
original batch. One buffer, two batches and two vma.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191211230858.599030-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 12 Dec 2019 07:27:37 +0000 (07:27 +0000)]
drm/i915/gt: Only ignore rc6 parking for PCU on byt/bsw
An oversight in that we use rc6->ctl_enable to disable rc6 on gen9 and
so it does not simply indicate indirect control via a PCU. Switch the
rc6->ctl_enable check for a platform-based check.
Fixes:
972745fd5770 ("drm/i915/gt: Disable manual rc6 for Braswell/Baytrail")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212072737.884335-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 11 Dec 2019 11:04:37 +0000 (11:04 +0000)]
drm/i915: Align start for memcpy_from_wc
The movntqda requires 16-byte alignment for the source pointer. Avoid
falling back to clflush if the source pointer is misaligned by doing the
doing a small uncached memcpy to fixup the alignments.
v2: Turn the unaligned copy into a genuine helper
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/20191211110437.4082687-5-chris@chris-wilson.co.uk
Chris Wilson [Wed, 11 Dec 2019 11:04:36 +0000 (11:04 +0000)]
drm/i915/gem: Tidy up error handling for eb_parse()
As the caller no longer uses the i915_vma result, stop returning it and
just return the error code instead.
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/20191211110437.4082687-4-chris@chris-wilson.co.uk
Chris Wilson [Wed, 11 Dec 2019 11:04:35 +0000 (11:04 +0000)]
drm/i915: Simplify error escape from cmdparser
We need to flush the destination buffer, even on error, to maintain
consistent cache state. Thereby removing the jump on error past the
clear, and reducing the loop-escape mechanism to a mere break.
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/20191211110437.4082687-3-chris@chris-wilson.co.uk
Chris Wilson [Wed, 11 Dec 2019 11:04:34 +0000 (11:04 +0000)]
drm/i915: Remove redundant parameters from intel_engine_cmd_parser
Declutter the calling interface by reducing the parameters to the
i915_vma and associated offsets.
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/20191211110437.4082687-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 11 Dec 2019 11:04:33 +0000 (11:04 +0000)]
drm/i915: Fix cmdparser drm.debug
The cmdparser rejection debug is not for driver development, but for the
user, for which we use a plain DRM_DEBUG().
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/20191211110437.4082687-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 10 Dec 2019 18:01:11 +0000 (18:01 +0000)]
drm/i915/gt: Disable manual rc6 for Braswell/Baytrail
The initial investigated showed that while the PCU on Braswell/Baytrail
controlled RC6 itself. setting the software RC6 request made no
difference. Further testing reveals though that it causes a delay in the
PCU on enabling RC6.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/763
Fixes:
730eaeb52426 ("drm/i915/gt: Manual rc6 entry upon parking")
Testcase: igt/perf/rc6-disable
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: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191210180111.3958558-1-chris@chris-wilson.co.uk
Michal Wajdeczko [Wed, 11 Dec 2019 12:45:49 +0000 (12:45 +0000)]
drm/i915/uc: Drop explicit ggtt param in some uc_fw functions
There is no need to pass explicit ggtt since we already have
a trick to get parent gt from uc_fw, we only need to use it.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
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/20191211124549.59516-4-michal.wajdeczko@intel.com
Michal Wajdeczko [Wed, 11 Dec 2019 12:45:48 +0000 (12:45 +0000)]
drm/i915/uc: Drop explicit gt param in some uc_fw functions
There is no need to pass explicit gt since we already have
a trick to get parent gt from uc_fw, we only need to use it.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
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/20191211124549.59516-3-michal.wajdeczko@intel.com
Michal Wajdeczko [Wed, 11 Dec 2019 12:45:47 +0000 (12:45 +0000)]
drm/i915/uc: Drop explicit i915 param in some uc_fw functions
There is no need to pass explicit i915 since we already have
a debug trick to get parent gt from uc_fw, we only need to
make this trick available on non-debug builds.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
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/20191211124549.59516-2-michal.wajdeczko@intel.com
Chris Wilson [Wed, 11 Dec 2019 15:02:04 +0000 (15:02 +0000)]
drm/i915: Use the i915_device name for identifying our request fences
Use the dev_name(i915) to identify the requests for debugging, so we can
tell different device timelines apart.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Reviewed-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191211150204.133471-1-chris@chris-wilson.co.uk
Colin Ian King [Tue, 10 Dec 2019 14:23:49 +0000 (14:23 +0000)]
drm/i915: remove redundant checks for a null fb pointer
A prior check and return when pointer fb is null makes
subsequent null checks on fb redundant. Remove the redundant
null checks.
Addresses-Coverity: ("Logically dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191210142349.333171-1-colin.king@canonical.com
Colin Ian King [Tue, 10 Dec 2019 14:45:35 +0000 (14:45 +0000)]
drm/i915/display: remove duplicated assignment to pointer crtc_state
Pointer crtc_state is being assigned twice, one of these is redundant
and can be removed.
Addresses-Coverity: ("Evaluation order violation")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191210144535.341977-1-colin.king@canonical.com
Ville Syrjälä [Tue, 12 Nov 2019 16:38:12 +0000 (18:38 +0200)]
drm/i915: Pass cpu transcoder to assert_pipe()
In order to eliminate intel_pipe_to_cpu_transcoder() (and its
crtc->config usage) let's pass the cpu transcoder to
assert_pipe() so we don't have to do the pipe->cpu transcoder
lookup on HSW+.
On VLV/CHV this can get called during eDP init, which
happens before crtc->config->cpu_transcoder is even
populated. So currently we're always reading PIPECONF(A)
there even if we're trying to check the state of some
other pipe.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112163812.22075-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Tue, 12 Nov 2019 16:38:11 +0000 (18:38 +0200)]
drm/i915: ELiminate intel_pipe_to_cpu_transcoder() from assert_fdi_tx()
Let's start to eliminate intel_pipe_to_cpu_transcoder() so that
we can get rid of one more crtc->config usage (which we will want
to nuke as well).
In the case of assert_fdi_tx() we know that we're never
dealing with the EDP transcoder so we can simply replace
this with a cast.
v2: Fix poor English in comment
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112163812.22075-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Chris Wilson [Tue, 10 Dec 2019 11:55:02 +0000 (11:55 +0000)]
drm/i915/selftests: Show the i915_active on failure
Print the i915_active state on selftest failure, with a hope it helps
illuminate the cause of the failure.
References: https://gitlab.freedesktop.org/drm/intel/issues/765
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/20191210115502.3767070-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 10 Dec 2019 13:37:19 +0000 (13:37 +0000)]
drm/i915/gem: Wait on unbind barriers when invalidating userptr
When we are told we have to drop all references to userptr, wait for any
barriers required for unbinding.
<4> [2055.808787] WARNING: CPU: 3 PID: 6239 at mm/mmu_notifier.c:472 __mmu_notifier_invalidate_range_start+0x1f2/0x250
<4> [2055.808792] Modules linked in: vgem mei_hdcp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel r8169 lpc_ich realtek i915 snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core pinctrl_broxton snd_pcm pinctrl_intel mei_me intel_lpss_pci mei prime_numbers [last unloaded: vgem]
<4> [2055.808834] CPU: 3 PID: 6239 Comm: gem_userptr_bli Tainted: G U 5.5.0-rc1-CI-CI_DRM_7522+ #1
<4> [2055.808839] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018
<4> [2055.808847] RIP: 0010:__mmu_notifier_invalidate_range_start+0x1f2/0x250
<4> [2055.808853] Code: c2 48 c7 c7 70 17 2e 82 44 89 45 d4 48 8b 70 28 e8 ec 01 ef ff 41 f6 46 20 01 44 8b 45 d4 75 0a 41 83 f8 f5 44 89 7d d4 74 89 <0f> 0b 44 89 45 d4 eb 81 0f 0b 49 8b 46 18 49 8b 76 10 4c 89 ff 48
<4> [2055.808858] RSP: 0018:
ffffc90002937d40 EFLAGS:
00010202
<4> [2055.808865] RAX:
0000000000000061 RBX:
ffff8882703a33e0 RCX:
0000000000000001
<4> [2055.808870] RDX:
0000000000000000 RSI:
ffff888277da8cb8 RDI:
00000000ffffffff
<4> [2055.808874] RBP:
ffffc90002937d70 R08:
00000000fffffff5 R09:
0000000000000000
<4> [2055.808879] R10:
0000000000000000 R11:
0000000000000000 R12:
0000000000000001
<4> [2055.808884] R13:
ffffffff822e1716 R14:
ffffc90002937d80 R15:
00000000fffffff5
<4> [2055.808890] FS:
00007fda75004e40(0000) GS:
ffff888277d80000(0000) knlGS:
0000000000000000
<4> [2055.808895] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4> [2055.808900] CR2:
000055ad72ec3000 CR3:
00000002697b2000 CR4:
00000000003406e0
<4> [2055.808904] Call Trace:
<4> [2055.808920] unmap_vmas+0x13e/0x150
<4> [2055.808937] unmap_region+0xa3/0x100
<4> [2055.808964] __do_munmap+0x26d/0x490
<4> [2055.808980] __vm_munmap+0x66/0xc0
<4> [2055.808994] __x64_sys_munmap+0x12/0x20
<4> [2055.809001] do_syscall_64+0x4f/0x220
Closes: https://gitlab.freedesktop.org/drm/intel/issues/771
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/20191210133719.3874455-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 10 Dec 2019 15:36:20 +0000 (15:36 +0000)]
drm/i915/gt: Check we are the Ironlake IPS provider before deregistering
Check that we own the global pointer before deregistering.
Reported-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191210153620.3929372-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Mon, 9 Dec 2019 12:23:14 +0000 (12:23 +0000)]
drm/i915: Improve execbuf debug
Convert i915_gem_check_execbuffer to return the error code instead of
a boolean so our neat EINVAL debugging trick works within this function.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@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/20191209122314.16289-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Tue, 10 Dec 2019 15:13:32 +0000 (15:13 +0000)]
drm/i915: Copy across scheduler behaviour flags across submit fences
We want the bonded request to have the same scheduler properties as its
master so that it is placed at the same depth in the queue. For example,
consider we have requests A, B and B', where B & B' are a bonded pair to
run in parallel on two engines.
A -> B
\- B'
B will run after A and so may be scheduled on an idle engine and wait on
A using a semaphore. B' sees B being executed and so enters the queue on
the same engine as A. As B' did not inherit the semaphore-chain from B,
it may have higher precedence than A and so preempts execution. However,
B' then sits on a semaphore waiting for B, who is waiting for A, who is
blocked by B.
Ergo B' needs to inherit the scheduler properties from B (i.e. the
semaphore chain) so that it is scheduled with the same priority as B and
will not be executed ahead of Bs dependencies.
Furthermore, to prevent the priorities changing via the expose fence on
B', we need to couple in the dependencies for PI. This requires us to
relax our sanity-checks that dependencies are strictly in order.
v2: Synchronise (B, B') execution on all platforms, regardless of using
a scheduler, any no-op syncs should be elided.
Fixes:
ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/464
Testcase: igt/gem_exec_balancer/bonded-chain
Testcase: igt/gem_exec_balancer/bonded-semaphore
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/20191210151332.3902215-1-chris@chris-wilson.co.uk
Animesh Manna [Thu, 5 Dec 2019 12:35:13 +0000 (18:05 +0530)]
drm/i915/dsb: Fix in mmio offset calculation of DSB instance
As the current usage is restricted to first DSB instance per pipe, so
existing code could not catch the issue to calculate the mmio offset
of different DSB instance per pipe. Corrected the offset calculation.
Fixes:
a6e58d9a2e04 ("drm/i915/dsb: Check DSB engine status.")
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205123513.22603-1-animesh.manna@intel.com
Jani Nikula [Wed, 11 Dec 2019 08:35:37 +0000 (10:35 +0200)]
Merge drm/drm-next into drm-intel-next-queued
Sync up with v5.5-rc1 to get the updated lock_release() API among other
things. Fix the conflict reported by Stephen Rothwell [1].
[1] http://lore.kernel.org/r/
20191210093957.
5120f717@canb.auug.org.au
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Tue, 10 Dec 2019 10:51:00 +0000 (12:51 +0200)]
drm/i915/dsi: add support for DSC
Enable DSC for DSI, if specified in VBT.
This still lacks DSC aware get config implementation, and therefore
state checker will fail. Also mode valid is not there yet.
v5:
- add dsc get config call
v4:
- convert_rgb = true (Vandita)
- ignore max cdclock check (Vandita)
- rename pipe_config to crtc_state
v3:
- take compressed bpp into account
v2:
- Nuke conn_state->max_requested_bpc, it's not used on DSI
Bspec: 49263
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e0136299e03c582238523189f6951eeb08daed98.1575974743.git.jani.nikula@intel.com
Vandita Kulkarni [Tue, 10 Dec 2019 10:50:59 +0000 (12:50 +0200)]
drm/i915/dsi: Fix state mismatch warns for horizontal timings with DSC
When DSC is enabled consider the compression ratio that was used during
horizontal timing calculations.
This may still lead to warns due to rounding errors in the round-trip.
v2 by Jani:
- rebase on top of the more generic dsc state readout
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/c2481aaf67ea396aa4698cd2d8e23d19ec4f4ecf.1575974743.git.jani.nikula@intel.com
Jani Nikula [Tue, 10 Dec 2019 10:50:58 +0000 (12:50 +0200)]
drm/i915/dsi: account for DSC in horizontal timings
When DSC is enabled, we need to adjust the horizontal timings to account
for the compressed (and therefore reduced) link speed.
The compressed frequency ratio simplifies down to the ratio between
compressed and non-compressed bpp.
Bspec: 49263
Suggested-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fecebdc2719dd0c78eaf8f4d3225bb185956d7db.1575974743.git.jani.nikula@intel.com
Jani Nikula [Tue, 10 Dec 2019 10:50:57 +0000 (12:50 +0200)]
drm/i915/dsi: use compressed pixel format with DSC
When compression is enabled, configure the DSI transcoder to use
compressed format.
Suggested-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0e58022ce5425560b3b31062c41de385a736c8b1.1575974743.git.jani.nikula@intel.com
Jani Nikula [Tue, 10 Dec 2019 10:50:56 +0000 (12:50 +0200)]
drm/i915/dsi: take compression into account in afe_clk()
Pass crtc_state to afe_clk() to be able to take compression into account
in the computation. Once we enable compression, that is.
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a698780362b8d6955d115ef8bb6cf1f7aabbee00.1575974743.git.jani.nikula@intel.com
Jani Nikula [Tue, 10 Dec 2019 10:50:55 +0000 (12:50 +0200)]
drm/i915/dsi: use afe_clk() instead of intel_dsi_bitrate()
We'll be expanding afe_clk() to take DSC into account. Switch to using
it where DSC matters. Which is really everywhere that
intel_dsi_bitrate() is currently used in ICL DSI code.
The functional difference is that we round the result closest instead of
down.
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b6c52b320daa8aaa0d79618ce714170f8f04ff67.1575974743.git.jani.nikula@intel.com
Jani Nikula [Tue, 10 Dec 2019 10:50:54 +0000 (12:50 +0200)]
drm/i915/dsi: abstract afe_clk calculation
We'll make more use of it in the future.
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0341fdc13260625150315b0b57a4227eb766c50f.1575974743.git.jani.nikula@intel.com
Jani Nikula [Tue, 10 Dec 2019 10:50:53 +0000 (12:50 +0200)]
drm/i915/dsi: set pipe_bpp on ICL configure config
The ICL DSI pipe_bpp currently comes from
compute_baseline_pipe_bpp(). Fix it.
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/191f5c4fa5f4af29d4bf7e30bb35f45ce05b33f0.1575974743.git.jani.nikula@intel.com
Jani Nikula [Tue, 10 Dec 2019 10:50:52 +0000 (12:50 +0200)]
drm/i915/dsc: add basic hardware state readout support
Add basic hardware state readout for DSC, and check the most relevant
details in the state checker.
v2:
- check for DSC power before reading its state
- check if source supports DSC at all
As a side effect, this should also get the power domains for the enabled
DSC on takeover, and subsequently disable DSC if it's not needed.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3fb018cf9bd9a4c275aab389b6ec0f2a4e938bb9.1575974743.git.jani.nikula@intel.com
Jani Nikula [Tue, 10 Dec 2019 10:50:51 +0000 (12:50 +0200)]
drm/i915/dsc: make DSC source support helper generic
Move intel_dp_source_supports_dsc() from intel_dp.c as
intel_dsc_source_support() in intel_vdsc.c. The DSC source support is
more about DSC than about DP, and will be needed for DP independent
code.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6c9f646090913290fb00efd46a4332421bf95930.1575974743.git.jani.nikula@intel.com
Jani Nikula [Tue, 10 Dec 2019 10:50:50 +0000 (12:50 +0200)]
drm/i915/dsc: add support for computing and writing PPS for DSI encoders
Add DSI specific computation and transmission to display of PPS.
With hopes that this approach will work for both DP and DSI encoders.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/461db10b1f4d76625625a9f2b1e3d932fff42799.1575974743.git.jani.nikula@intel.com