OSDN Git Service
Chris Wilson [Thu, 21 Nov 2019 13:05:28 +0000 (13:05 +0000)]
drm/i915: Mark intel_wakeref_get() as a sleeper
Assume that intel_wakeref_get() may take the mutex, and perform other
sleeping actions in the course of its callbacks and so use might_sleep()
to ensure that all callers abide. Anything that cannot sleep has to use
e.g. intel_wakeref_get_if_active() to guarantee its avoidance of the
non-atomic paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121130528.309474-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 10:35:46 +0000 (10:35 +0000)]
drm/i915/execlists: Lock the request while validating it during promotion
Since the request is already on the HW as we perform its validation, it
and even its subsequent barrier may be concurrently retired before we
process the assertions. If it is retired already and so off the HW, our
assertions become void and we need to ignore them.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112363
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121103546.146487-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 09:33:26 +0000 (09:33 +0000)]
drm/i915/gt: Hold request reference while waiting for w/a verification
As we wait upon a request, we must be holding a reference to it, and be
wary that i915_request_add() consumes the passed in reference.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121093326.134774-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 07:10:41 +0000 (07:10 +0000)]
drm/i915: Serialise with remote retirement
Since retirement may be running in a worker on another CPU, it may be
skipped in the local intel_gt_wait_for_idle(). To ensure the state is
consistent for our sanity checks upon load, serialise with the remote
retirer by waiting on the timeline->mutex.
Outside of this use case, e.g. on suspend or module unload, we expect the
slack to be picked up by intel_gt_pm_wait_for_idle() and so prefer to
put the special case serialisation with retirement in its single user,
for now at least.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121071044.97798-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 21 Nov 2019 07:10:40 +0000 (07:10 +0000)]
Revert "drm/i915/gt: Wait for new requests in intel_gt_retire_requests()"
From inside an active timeline in the execbuf ioctl, we may try to
reclaim some space in the GGTT. We need GGTT space for all objects on
!full-ppgtt platforms, and for context images everywhere. However, to
free up space in the GGTT we may need to remove some pinned objects
(e.g. context images) that require flushing the idle barriers to remove.
For this we use the big hammer of intel_gt_wait_for_idle()
However, commit
7936a22dd466 ("drm/i915/gt: Wait for new requests in
intel_gt_retire_requests()") will continue spinning on the wait if a
timeline is active but lacks requests, as is the case during execbuf
reservation. Spinning forever is quite time consuming, so revert that
commit and start again.
In practice, the effect commit
7936a22dd466 was trying to achieve is
accomplished by commit
1683d24c1470 ("drm/i915/gt: Move new timelines
to the end of active_list"), so there is no immediate rush to replace
the looping.
Testcase: igt/gem_exec_reloc/basic-range
Fixes:
7936a22dd466 ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()")
References:
1683d24c1470 ("drm/i915/gt: Move new timelines to the end of active_list")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121071044.97798-1-chris@chris-wilson.co.uk
Stuart Summers [Wed, 20 Nov 2019 21:13:21 +0000 (13:13 -0800)]
drm/i915: Use intel_gt_pm_put_async in GuC submission path
GuC submission path can be called from an interrupt context
and so should use a worker to avoid holding a mutex.
References:
07779a76ee1f ("drm/i915: Mark up the calling context for intel_wakeref_put()")
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120211321.88021-1-stuart.summers@intel.com
Chris Wilson [Wed, 20 Nov 2019 18:22:09 +0000 (18:22 +0000)]
drm/i915/gt: Fixup config ifdeffery for pm_suspend_target_state
pm_suspend_target_state is declared under CONFIG_PM_SLEEP but only
defined under CONFIG_SUSPEND. Play safe and only use the symbol if it is
both declared and defined.
Reported-by: kbuild-all@lists.01.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes:
a70a9e998e8e ("drm/i915: Defer rc6 shutdown to suspend_late")
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120182209.3967833-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 17:08:58 +0000 (17:08 +0000)]
drm/i915/gt: Declare timeline.lock to be irq-free
Now that we never allow the intel_wakeref callbacks to be invoked from
interrupt context, we do not need the irqsafe spinlock for the timeline.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120170858.3965380-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 16:55:14 +0000 (16:55 +0000)]
drm/i915/gt: Unlock engine-pm after queuing the kernel context switch
In commit
a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap with other users of the engine->kernel_context waking
up and submitting their request before the idle-switch is queued, with
the result that the kernel_context is executed out-of-sequence most
likely upsetting the GPU and certainly ourselves when we try to retire
the out-of-sequence requests.
As such we need to hold onto the effective engine->kernel_context mutex
lock (via the engine pm mutex proxy) until we have finish queuing the
request to the engine.
v2: Serialise against concurrent intel_gt_retire_requests()
v3: Describe the hairy locking scheme with intel_gt_retire_requests()
for future reference.
v4: Combine timeline->lock and engine pm release; it's hairy.
Fixes:
a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120165514.3955081-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 16:55:13 +0000 (16:55 +0000)]
drm/i915/gt: Close race between engine_park and intel_gt_retire_requests
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_context->timeline could be manipulated under the
global wakeref.mutex.
This was quite solid, as we always manipulated the timeline only while
we held an engine wakeref.
And then we started retiring requests outside of struct_mutex, only
using the timelines.active_list and the timeline->mutex. There we
started manipulating intel_timeline.active_count outside of an engine
wakeref, and so introduced a race between __engine_park() and
intel_gt_retire_requests(), a race that could result in the
engine->kernel_context not being added to the active timelines and so
losing requests, which caused us to keep the system permanently powered
up [and unloadable].
The race would be easy to close if we could take the engine wakeref for
the timeline before we retire -- except timelines are not bound to any
engine and so we would need to keep all active engines awake. The
alternative is to guard intel_timeline_enter/intel_timeline_exit for use
outside of the timeline->mutex.
Fixes:
e5dadff4b093 ("drm/i915: Protect request retirement with timeline->mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120165514.3955081-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 12:54:33 +0000 (12:54 +0000)]
drm/i915: Mark up the calling context for intel_wakeref_put()
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a worker if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normally are in process context,
we can typically use a plain mutex, and only defer to a work when we
know we are being called from an interrupt path.
Fixes:
51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref")
References:
a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in IRQ contexts")
References: https://bugs.freedesktop.org/show_bug.cgi?id=111626
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120125433.3767149-1-chris@chris-wilson.co.uk
Stuart Summers [Wed, 20 Nov 2019 01:10:16 +0000 (17:10 -0800)]
drm/i915: Do not initialize display BW when display not available
When display is not available, finding the memory bandwidth available
for display is not useful. Skip this sequence here.
References: HSDES
1209978255
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120011016.18049-1-stuart.summers@intel.com
Stuart Summers [Wed, 20 Nov 2019 00:45:05 +0000 (16:45 -0800)]
Skip MCHBAR queries when display is not available
Platforms without display do not map the MCHBAR MMIO into the GFX
device BAR. Skip this sequence when display is not available.
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120004505.149516-1-stuart.summers@intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:30 +0000 (18:44 +0200)]
drm/i915: Change .crtc_enable/disable() calling convention
Just pass the atomic state+crtc to the .crtc_enable()
.crtc_disable(). Life is easier when you don't have to think
whether to pass the old or the new crtc state.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-11-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:29 +0000 (18:44 +0200)]
drm/i915: s/pipe_config/new_crtc_state/ in .crtc_enable()
Rename pipe_config to new_crtc_state in the .crtc_enable() hooks.
The 'pipe_config' name is a zombie that we need to finally put down.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-10-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:28 +0000 (18:44 +0200)]
drm/i915: s/intel_crtc/crtc/ in .crtc_enable() and .crtc_disable()
Get rid of the horrible aliasing drm_crtc and intel_crtc variables
in the crtc enable/disable hooks.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-9-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:27 +0000 (18:44 +0200)]
drm/i915: Pass dev_priv to cpt_verify_modeset()
Get rid of the last 'dev' usage in ironlake_crtc_enable() by
passing dev_priv to cpt_verify_modeset().
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-8-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:26 +0000 (18:44 +0200)]
drm/i915: Change watermark hook calling convention
Just pass the atomic_state+crtc to the watermarks hooks. Eeasier
time for the caller when it doesn't have to think what to pass.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-7-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:25 +0000 (18:44 +0200)]
drm/i915: Pass intel_crtc to ironlake_fdi_disable()
Switch to intel_crtc from drm_crtc.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-6-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:24 +0000 (18:44 +0200)]
drm/i915: Move crtc_state to tighter scope
intel_modeset_setup_hw_state() doesn't need the crtc_state at the
top level scope. Move it to where it's needed.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-5-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:23 +0000 (18:44 +0200)]
drm/i915: Move assert_vblank_disabled() into intel_crtc_vblank_on()
Move the assert_vblank_disabled() into intel_crtc_vblank_on()
so that we don't have to inline it all over.
This does mean we now assert_vblank_disabled() during readout as well
but that is totally fine as it happens after drm_crtc_vblank_reset().
One can even argue it's what we want to do anyway to make sure
the reset actually happened.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-4-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:22 +0000 (18:44 +0200)]
drm/i915: Add intel_crtc_vblank_off()
We already have intel_crtc_vblank_on(). Add a counterpart so we
don't have to inline the disable+assert all over.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-3-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Nov 2019 16:44:21 +0000 (18:44 +0200)]
drm/i915: Change intel_encoders_<hook>() calling convention
Just pass the atomic state and the crtc to intel_encoders_enable() & co.
Make life simpler when you don't have to think which state (old vs. new)
you have to pass in. Also constify the states while at it.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164430.27265-2-ville.syrjala@linux.intel.com
Jani Nikula [Wed, 20 Nov 2019 13:54:37 +0000 (15:54 +0200)]
Merge tag 'topic/drm-mipi-dsi-dsc-updates-2019-11-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next-queued
Core Changes:
- Update DSI data type and command definitions
- Add helpers for sending compression mode and PPS packets
Driver Changes:
- Update tiny/st7586 to reflect a definition change
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87tv7a4eq3.fsf@intel.com
Chris Wilson [Wed, 20 Nov 2019 10:27:41 +0000 (10:27 +0000)]
drm/i915/selftests: Take a ref to the request we wait upon
i915_request_add() consumes the passed in reference to the i915_request,
so if the selftest caller wishes to wait upon it afterwards, it needs to
take a reference for itself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120102741.3734346-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 20 Nov 2019 09:33:01 +0000 (09:33 +0000)]
drm/i915/selftests: Be explicit in ERR_PTR handling
When setting up a full GGTT, we expect the next insert to fail with
-ENOSPC. Simplify the use of ERR_PTR to not confuse either the reader or
smatch.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
References:
f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120093302.3723715-8-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 15:47:23 +0000 (15:47 +0000)]
drm/i915/selftests: Exercise rc6 w/a handling
Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
possible rc6 context corruption. Poke at the bear!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Tested-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119154723.3311814-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 18 Nov 2019 23:02:46 +0000 (23:02 +0000)]
drm/i915: Wait until the intel_wakeref idle callback is complete
When waiting for idle, serialise with any ongoing callback so that it
will have completed before completing the wait.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-12-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 10:09:13 +0000 (10:09 +0000)]
drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
Since igt now defaults to not enabling ftrace-on-oops, we need to
manually invoke GEM_TRACE_DUMP() to see the debug log prior to a
GEM_BUG_ON panicking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119100929.2628356-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 18 Nov 2019 23:02:50 +0000 (23:02 +0000)]
drm/i915/gt: Flush the requests after wedging on suspend
Retire all requests if we resort to wedged the driver on suspend. They
will now be idle, so we might as we free them before shutting down.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-16-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 16:25:59 +0000 (16:25 +0000)]
drm/i915/gt: Schedule next retirement worker first
As we may park the gt during request retirement, we may cancel the
retirement worker only to then program the delayed worker once more.
If we schedule the next delayed retirement worker first, if we then park
the gt, the work will remain cancelled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119162559.3313003-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 16:25:58 +0000 (16:25 +0000)]
drm/i915/gt: Move new timelines to the end of active_list
When adding a new active timeline, place it at the end of the list. This
allows for intel_gt_retire_requests() to pick up the newcomer more
quickly and hopefully complete the retirement sooner. A miniscule
optimisation.
References:
7936a22dd466 ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119162559.3313003-1-chris@chris-wilson.co.uk
Matthew Auld [Tue, 19 Nov 2019 15:01:54 +0000 (15:01 +0000)]
drm/i915: make pool objects read-only
For our current users we don't expect pool objects to be writable from
the gpu.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes:
4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow buffers")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119150154.18249-1-matthew.auld@intel.com
Matt Roper [Mon, 18 Nov 2019 18:02:19 +0000 (10:02 -0800)]
drm/i915/tgl: Add DKL PHY vswing table for HDMI
The bspec initially provided a single DKL PHY vswing table for both HDMI
and DP, but was recently updated to include an independent table for
HDMI.
Bspec: 49292
Fixes:
978c3e539be2 ("drm/i915/tgl: Add dkl phy programming sequences")
Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118180219.9309-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Vandita Kulkarni [Tue, 19 Nov 2019 07:20:04 +0000 (12:50 +0530)]
drm/i915/dsi: Do not read the transcoder register.
As per the Bspec, port mapping is fixed for mipi dsi.
v2: Reuse the existing function (Jani)
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119072004.4093-1-vandita.kulkarni@intel.com
Chris Wilson [Tue, 19 Nov 2019 10:09:20 +0000 (10:09 +0000)]
drm/i915/gem: Protect the obj->vma.list during iteration
Take the obj->vma.lock to prevent modifications to the list as we
iterate, to avoid the dreaded NULL pointer.
<1>[ 347.820823] BUG: kernel NULL pointer dereference, address:
0000000000000150
<1>[ 347.820856] #PF: supervisor read access in kernel mode
<1>[ 347.820874] #PF: error_code(0x0000) - not-present page
<6>[ 347.820892] PGD 0 P4D 0
<4>[ 347.820908] Oops: 0000 [#1] PREEMPT SMP NOPTI
<4>[ 347.820926] CPU: 3 PID: 1303 Comm: gem_persistent_ Tainted: G U 5.4.0-rc7-CI-CI_DRM_7352+ #1
<4>[ 347.820956] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018
<4>[ 347.821132] RIP: 0010:i915_gem_object_flush_write_domain+0xd9/0x1d0 [i915]
<4>[ 347.821157] Code: 0f 84 e9 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 75 11 e9 ed 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 74 26 48 8b 83 b0 00 00 00 <48> 8b b8 50 01 00 00 e8 fb 20 fb ff 48 8b 83 30 03 00 00 49 39 c4
<4>[ 347.821210] RSP: 0018:
ffffc90000a1f8f8 EFLAGS:
00010202
<4>[ 347.821229] RAX:
0000000000000000 RBX:
ffffc900008479a0 RCX:
0000000000000018
<4>[ 347.821252] RDX:
0000000000000000 RSI:
000000000000000d RDI:
ffff888275a090b0
<4>[ 347.821274] RBP:
ffff8882673c8040 R08:
ffff88825991b8d0 R09:
0000000000000000
<4>[ 347.821297] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff8882673c8280
<4>[ 347.821319] R13:
ffff8882673c8368 R14:
0000000000000000 R15:
ffff888266a54000
<4>[ 347.821343] FS:
00007f75865f4240(0000) GS:
ffff888277b80000(0000) knlGS:
0000000000000000
<4>[ 347.821368] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4>[ 347.821389] CR2:
0000000000000150 CR3:
000000025aee0000 CR4:
00000000003406e0
<4>[ 347.821411] Call Trace:
<4>[ 347.821555] i915_gem_object_prepare_read+0xea/0x2a0 [i915]
<4>[ 347.821706] intel_engine_cmd_parser+0x5ce/0xe90 [i915]
<4>[ 347.821834] ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
<4>[ 347.821990] i915_gem_do_execbuffer+0xb4c/0x2550 [i915]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119100929.2628356-8-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 10:09:18 +0000 (10:09 +0000)]
drm/i915/gem: Merge GGTT vma flush into a single loop
We only need the one loop to find the dirty vma flush them and their
chipset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119100929.2628356-6-chris@chris-wilson.co.uk
Chris Wilson [Tue, 19 Nov 2019 11:25:15 +0000 (11:25 +0000)]
drm/i915/gem: Track ggtt writes from userspace on the bound vma
When userspace writes into the GTT itself, it is supposed to call
set-domain to let the kernel keep track and so manage the CPU/GPU
caches. As we track writes on the individual i915_vma, we should also be
sure to mark them as dirty.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119112515.2766748-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 18 Nov 2019 23:02:40 +0000 (23:02 +0000)]
drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint
In order to avoid some nasty mutex inversions, commit
09c5ab384f6f
("drm/i915: Keep rings pinned while the context is active") allowed the
intel_ring unpinning to be run concurrently with the next context
pinning it. Thus each step in intel_ring_unpin() needed to be atomic and
ordered in a nice onion with intel_ring_pin() so that the lifetimes
overlapped and were always safe.
Sadly, a few steps in intel_ring_unpin() were overlooked, such as
closing the read/write pointers of the ring and discarding the
intel_ring.vaddr, as these steps were not serialised with
intel_ring_pin() and so could leave the ring in disarray.
Fixes:
09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-6-chris@chris-wilson.co.uk
Chris Wilson [Mon, 18 Nov 2019 18:49:33 +0000 (18:49 +0000)]
drm/i915/gt: Only wait for register chipset flush if active
Only serialise with the chipset using an mmio if the chipset is
currently active. We expect that any writes into the chipset range will
simply be forgotten until it wakes up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118184943.2593048-8-chris@chris-wilson.co.uk
Matt Roper [Mon, 18 Nov 2019 16:44:12 +0000 (08:44 -0800)]
drm/i915/ehl: Update voltage level checks
The bspec was recently updated with new cdclk -> voltage level tables to
accommodate the new 324/326.4 cdclk values.
Bspec: 21809
Fixes:
63c9dae71dc5 ("drm/i915/ehl: Add voltage level requirement table")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164412.26216-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Lucas De Marchi [Mon, 11 Nov 2019 20:50:25 +0000 (12:50 -0800)]
drm/i915/dsb: fix extra warning on error path handling
When we call intel_dsb_get(), the dsb initialization may fail for
various reasons. We already log the error message in that path, making
it unnecessary to trigger a warning that refcount == 0 when calling
intel_dsb_put().
So here we simplify the logic and do lazy shutdown: leaving the extra
refcount alive so when we call intel_dsb_put() we end up calling
i915_vma_unpin_and_release().
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111205024.22853-3-lucas.demarchi@intel.com
Lucas De Marchi [Sat, 16 Nov 2019 01:15:39 +0000 (17:15 -0800)]
drm/i915/dsb: remove atomic operations
The current dsb API is not really prepared to handle multithread access.
I was debugging an issue that ended up fixed by commit
a096883dda2c
("drm/i915/dsb: Remove PIN_MAPPABLE from the DSB object VMA") and was
puzzled how these atomic operations were guaranteeing atomicity.
if (atomic_add_return(1, &dsb->refcount) != 1)
return dsb;
Thread A could still be initializing dsb struct (and even fail in the
middle) while thread B would take a reference and use it (even
derefencing a NULL cmd_buf).
I don't think the atomic operations here will help much if this were
to support multithreaded scenario in future, so just remove them to
avoid confusion.
v2: Use refcount++ != 0 instead of ++refcount != 1 (from Ville)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111205024.22853-2-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20191116011539.18230-1-lucas.demarchi@intel.com
José Roberto de Souza [Fri, 15 Nov 2019 20:04:30 +0000 (12:04 -0800)]
drm/i915/mst: Check uapi enable not intel one during mst atomic check
When the connector has VCPI allocated and is being moved to another
pipe it causes drm_dp_atomic_release_vcpi_slots() and
drm_dp_atomic_find_vcpi_slots() to be called in the same atomic check
causing the error bellow.
This happens because at this point Intel's hw.enable(and all other
flags in the same struct) is not set but checking to on the uapi one
it have the expected value.
[ 580.804430] ------------[ cut here ]------------
[ 580.804436] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180
[ 580.804439] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers]
[ 580.804462] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G W 5.4.0-rc7-zeh+ #1226
[ 580.804465] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.
1909250226 09/25/2019
[ 580.804470] Workqueue: events output_poll_execute
[ 580.804476] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180
[ 580.804481] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02
[ 580.804484] RSP: 0018:
ffffc900009b7ab8 EFLAGS:
00010246
[ 580.804488] RAX:
ffff88848c04ef50 RBX:
ffff88848c04ef40 RCX:
0000000000000214
[ 580.804492] RDX:
ffff88848c04f5e0 RSI:
ffff888486eb2c68 RDI:
ffff88848e518800
[ 580.804495] RBP:
ffff88849d339000 R08:
00000000bc4e1092 R09:
0000000000000000
[ 580.804498] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff88848c04e728
[ 580.804501] R13:
0000000000000214 R14:
ffff88848c04e720 R15:
ffff888486eb2c68
[ 580.804504] FS:
0000000000000000(0000) GS:
ffff8884a0000000(0000) knlGS:
0000000000000000
[ 580.804507] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 580.804510] CR2:
00007ff6bf1ba680 CR3:
0000000005210003 CR4:
0000000000760ef0
[ 580.804512] PKRU:
55555554
[ 580.804515] Call Trace:
[ 580.804574] intel_dp_mst_compute_config+0x193/0x2b0 [i915]
[ 580.804636] intel_atomic_check+0x10cc/0x20b0 [i915]
[ 580.804644] ? drm_atomic_print_old_state+0xf1/0x130
[ 580.804655] drm_atomic_check_only+0x56a/0x810
[ 580.804663] drm_atomic_commit+0xe/0x50
[ 580.804668] drm_client_modeset_commit_atomic+0x18b/0x220
[ 580.804680] drm_client_modeset_commit_force+0x4d/0x180
[ 580.804685] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[ 580.804689] drm_fb_helper_set_par+0x27/0x50
[ 580.804692] drm_fb_helper_hotplug_event.part.0+0xa7/0xc0
[ 580.804696] drm_kms_helper_hotplug_event+0x21/0x30
[ 580.804699] output_poll_execute+0x1a4/0x1c0
[ 580.804706] process_one_work+0x25b/0x5b0
[ 580.804713] worker_thread+0x4b/0x3b0
[ 580.804720] kthread+0x100/0x140
[ 580.804723] ? process_one_work+0x5b0/0x5b0
[ 580.804725] ? kthread_park+0x80/0x80
[ 580.804730] ret_from_fork+0x24/0x50
[ 580.804740] irq event stamp: 40988
[ 580.804743] hardirqs last enabled at (40987): [<
ffffffff81128567>] console_unlock+0x437/0x590
[ 580.804746] hardirqs last disabled at (40988): [<
ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20
[ 580.804749] softirqs last enabled at (40972): [<
ffffffff81c00389>] __do_softirq+0x389/0x47f
[ 580.804752] softirqs last disabled at (40959): [<
ffffffff810b6f19>] irq_exit+0xa9/0xc0
[ 580.804754] ---[ end trace
80052e0c60463c67 ]---
[ 580.804758] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:
000000007880692e] in the same state
[ 580.811370] [drm:intel_dp_hpd_pulse [i915]] got esi2 02 00 00
[ 580.817239] [drm:intel_dp_hpd_pulse [i915]] got esi 02 00 00
[ 580.817313] ------------[ cut here ]------------
[ 580.817318] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180
[ 580.817321] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal
[ 580.817412] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on [ENCODER:306:DDI E] - short
[ 580.817413] usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul
[ 580.817490] [drm:intel_dp_hpd_pulse [i915]] is_mst
[ 580.817491] mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers]
[ 580.817498] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G W 5.4.0-rc7-zeh+ #1226
[ 580.817503] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.
1909250226 09/25/2019
[ 580.817506] Workqueue: events output_poll_execute
[ 580.817511] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180
[ 580.817514] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02
[ 580.817516] RSP: 0018:
ffffc900009b7ab8 EFLAGS:
00010246
[ 580.817519] RAX:
ffff88848c04ef50 RBX:
ffff88848c04ef40 RCX:
000000000000018f
[ 580.817521] RDX:
ffff88848c04f5e0 RSI:
ffff888486eb2c68 RDI:
ffff88848e518800
[ 580.817523] RBP:
ffff88849d339000 R08:
00000000bc4e1092 R09:
0000000000000000
[ 580.817525] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff88848c04e728
[ 580.817528] R13:
000000000000018f R14:
ffff88848c04e720 R15:
ffff888486eb2c68
[ 580.817532] FS:
0000000000000000(0000) GS:
ffff8884a0000000(0000) knlGS:
0000000000000000
[ 580.817534] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 580.817535] CR2:
00007ff6bf1ba680 CR3:
0000000005210003 CR4:
0000000000760ef0
[ 580.817537] PKRU:
55555554
[ 580.817538] Call Trace:
[ 580.817620] intel_dp_mst_compute_config+0x193/0x2b0 [i915]
[ 580.817690] intel_atomic_check+0x10cc/0x20b0 [i915]
[ 580.817697] ? drm_atomic_print_old_state+0xf1/0x130
[ 580.817711] drm_atomic_check_only+0x56a/0x810
[ 580.817721] drm_atomic_commit+0xe/0x50
[ 580.817726] drm_client_modeset_commit_atomic+0x18b/0x220
[ 580.817744] drm_client_modeset_commit_force+0x4d/0x180
[ 580.817751] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[ 580.817756] drm_fb_helper_set_par+0x27/0x50
[ 580.817762] drm_fb_helper_hotplug_event.part.0+0xa7/0xc0
[ 580.817767] drm_kms_helper_hotplug_event+0x21/0x30
[ 580.817771] output_poll_execute+0x1a4/0x1c0
[ 580.817780] process_one_work+0x25b/0x5b0
[ 580.817791] worker_thread+0x4b/0x3b0
[ 580.817800] kthread+0x100/0x140
[ 580.817804] ? process_one_work+0x5b0/0x5b0
[ 580.817807] ? kthread_park+0x80/0x80
[ 580.817813] ret_from_fork+0x24/0x50
[ 580.817832] irq event stamp: 41028
[ 580.817838] hardirqs last enabled at (41027): [<
ffffffff81128567>] console_unlock+0x437/0x590
[ 580.817841] hardirqs last disabled at (41028): [<
ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20
[ 580.817846] softirqs last enabled at (41022): [<
ffffffff81c00389>] __do_softirq+0x389/0x47f
[ 580.817851] softirqs last disabled at (41013): [<
ffffffff810b6f19>] irq_exit+0xa9/0xc0
[ 580.817854] ---[ end trace
80052e0c60463c68 ]---
[ 580.817858] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:
000000007880692e] in the same state
[ 580.830767] [drm:intel_dp_mst_compute_config [i915]] failed finding vcpi slots:-22
[ 580.830821] [drm:intel_atomic_check [i915]] Encoder config failure: -22
Cc: Lyude Paul <lyude@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115200430.53146-1-jose.souza@intel.com
Matt Roper [Fri, 15 Nov 2019 16:51:32 +0000 (08:51 -0800)]
drm/i915/vbt: Handle generic DTD block
VBT revision 229 adds a new "Generic DTD" block 58 and deprecates the
old LFP panel mode data in block 42. Let's start parsing this block to
fill in the panel fixed mode on devices with a >=229 VBT.
v2:
* Update according to the recent updates:
- DTD size is now 16 bits instead of 24
- polarity is now just a single bit for hsync and vsync and is
properly documented
* Minor checkpatch fix
v3:
* Now that panel options are parsed separately from the previous patch,
move generic DTD parsing into a function parallel to
parse_lfp_panel_dtd. We'll still fall back to looking at the legacy
LVDS timing block if the generic DTD fails. (Jani)
* Don't forget to actually set lfp_lvds_vbt_mode! (Jani)
* Drop "bdb_" prefix from dtd entry structure. (Jani)
* Follow C99 standard for structure's flexible array member. (Jani)
v4:
* Add "positive" to polarity field names for clarity. (Jani)
* Move VBT version check and fallback to legacy DTD parsing logic to a
helper to keep top-level VBT parsing uncluttered. (Jani)
* Restructure reserved bit packing at end of generic_dtd_entry from
"u32 rsvd:24" to "u8 rsvd[3]" to prevent copy/paste mistakes in the
future. (Jani)
Bspec: 54751
Bspec: 20148
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-3-matthew.d.roper@intel.com
Matt Roper [Fri, 15 Nov 2019 16:51:31 +0000 (08:51 -0800)]
drm/i915/vbt: Parse panel options separately from timing data
Newer VBT versions will add an alternate way to read panel DTD
information, so let's split parsing of the general panel information
from the timing data in preparation.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jesse Barnes <jsbarnes@google.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-2-matthew.d.roper@intel.com
Chris Wilson [Mon, 18 Nov 2019 09:43:42 +0000 (09:43 +0000)]
drm/i915/selftests: Add intel_gt_driver_late_release for mock device
Having called intel_gt_init_early() to setup the mock intel_gt, we need
to call the corresponding intel_gt_driver_late_release() to clean up.
References:
dea397e818b1 ("drm/i915/gt: Flush retire.work timer object on unload")
References:
24635c5152af ("drm/i915: Move intel_gt initialization to a separate file")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118094342.2193485-1-chris@chris-wilson.co.uk
Jani Nikula [Fri, 15 Nov 2019 12:04:40 +0000 (14:04 +0200)]
drm/i915: fix accidental static variable use
It's supposed to be just a const pointer.
Fixes:
074c77e3ec63 ("drm/i915/tgl: Gen-12 display loses Yf tiling and legacy CCS support")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115120440.17883-1-jani.nikula@intel.com
Don Hiatt [Fri, 15 Nov 2019 23:15:38 +0000 (15:15 -0800)]
drm/i915/guc: Skip suspend/resume GuC action on platforms w/o GuC submission
On some platforms (e.g. KBL) that do not support GuC submission, but
the user enabled the GuC communication (e.g for HuC authentication)
calling the GuC EXIT_S_STATE action results in lose of ability to
enter RC6. We can remove the GuC suspend/resume entirely as we do
not need to save the GuC submission status.
Add intel_guc_submission_is_enabled() function to determine if
GuC submission is active.
v2: Do not suspend/resume the GuC on platforms that do not support
Guc Submission.
v3: Fix typo, move suspend logic to remove goto.
v4: Use intel_guc_submission_is_enabled() to check GuC submission
status.
v5: No need to look at engine to determine if submission is enabled.
Squash fix + intel_guc_submission_is_enabled() patch into one.
v6: Move resume check into intel_guc_resume() for symmetry.
Fix commit Fixes tag.
Reported-by: KiteStramuort <kitestramuort@autistici.org>
Reported-by: S. Zharkoff <s.zharkoff@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111623
Fixes:
ffd5ce22faa4 ("drm/i915/guc: Updates for GuC 32.0.3 firmware")
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceralo Spurio <daniele.ceraolospurio@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomas Janousek <tomi@nomi.cz>
Signed-off-by: Don Hiatt <don.hiatt@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115231538.1249-1-don.hiatt@intel.com
Chris Wilson [Fri, 15 Nov 2019 17:08:35 +0000 (17:08 +0000)]
drm/i915/gem: Purge the sudden reappearance of i915_gem_object_pin()
This died many years ago as we now use i915_vma first and foremost.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115170835.1367869-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 15 Nov 2019 12:23:43 +0000 (12:23 +0000)]
drm/i915/gt: Mention which device failed
When telling the user that device power management is disabled, it is
helpful to say which device that was.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115122343.821331-1-chris@chris-wilson.co.uk
Ville Syrjälä [Thu, 24 Oct 2019 12:21:38 +0000 (15:21 +0300)]
drm/i915: Fix frame start delay programming
Currently we're blindly poking at the frame start delay bits
in PIPECONF when trying to sanitize the hardware state. Those
bits decided to move elsewhere on HSW, so on many platforms
we're not doing anything at all here. Also we're forgetting
about the PCH transcoder entirely.
Add all the bit definitions for the various homes these bits
have had throughout the years, and reset them all to zero.
However I'm not entirely sure this is a safe thing to do. If
not I guess we'd want full readout+statecheck for this stuff.
For now let's stick to the current logic and hope for the
best.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024122138.25065-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Chris Wilson [Fri, 15 Nov 2019 15:08:40 +0000 (15:08 +0000)]
drm/i915/selftests: Disable heartbeat around context barrier tests
As the heartbeat has the effect of flushing context barriers, this
interferes with the context barrier tests that are trying to observe
them directly. Disable the heartbeat so that the barriers are as
predictable as the test demands.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115150841.880349-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 14 Nov 2019 22:57:35 +0000 (22:57 +0000)]
drm/i915/selftests: Exercise long preemption chains
Verify that we can execute a long chain of dependent requests from
userspace, each one slightly more important than the last.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114225736.616885-4-chris@chris-wilson.co.uk
Lionel Landwerlin [Thu, 14 Nov 2019 14:02:24 +0000 (16:02 +0200)]
drm/i915/perf: Add preemption check while waiting for OA
While we're waiting for the OA configuration to apply, let's give a
chance to other contexts that might need to run other workloads.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114140224.21818-1-lionel.g.landwerlin@intel.com
Chris Wilson [Fri, 15 Nov 2019 15:08:39 +0000 (15:08 +0000)]
drm/i915/gt: Flush retire.work timer object on unload
We need to wait until the timer object is marked as deactivated before
unloading, so follow up our gentle cancel_delayed_work() with the
synchronous variant to ensure it is flushed off a remote cpu before we
mark the memory as freed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111994
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115150841.880349-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 15 Nov 2019 11:48:00 +0000 (11:48 +0000)]
drm/i915/gt: Use gt locals for accessing rc6
RC6 is tracked underneath the intel_gt, so use our local pointers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115114800.725061-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 15 Nov 2019 12:27:55 +0000 (12:27 +0000)]
drm/i915: Simplify NEEDS_WaRsDisableCoarsePowerGating
It applies to all gen9 and gen10 now, so we can use a single test
against the gen bitmask.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115122755.830355-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 14 Nov 2019 22:57:36 +0000 (22:57 +0000)]
drm/i915/gem: Silence sparse for RCU protection inside the constructor
Inside the constructor, while cloning, we need to replace the
dst->engines. Having forgotten that dst->engines is marked as RCU
protected, we need to add the appropriate annotations to make sparse
happy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114225736.616885-5-chris@chris-wilson.co.uk
Chris Wilson [Thu, 14 Nov 2019 22:57:32 +0000 (22:57 +0000)]
drm/i915/gt: Wait for new requests in intel_gt_retire_requests()
Our callers fall into two categories, those passing timeout=0 who just
want to flush request retirements and those passing a timeout that need
to wait for submission completion (e.g. intel_gt_wait_for_idle()).
Currently, we only wait for a snapshot of timelines at the start of the
wait (but there was an expectation that new requests would cause timelines
to appear at the end). However, our callers, such as
intel_gt_wait_for_idle() before suspend, do require us to wait for the
power management requests emitted by retirement as well. If we don't,
then it takes an extra second or two for the background worker to flush
the queue and mark the GT as idle.
Fixes:
7e8057626640 ("drm/i915: Drop struct_mutex from around i915_retire_requests()")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114225736.616885-1-chris@chris-wilson.co.uk
Jani Nikula [Fri, 15 Nov 2019 11:17:39 +0000 (13:17 +0200)]
Merge drm/drm-next into drm-intel-next-queued
Backmerge to get
dfce90259d74 ("Backmerge i915 security patches from
commit '
ea0b163b13ff' into drm-next") and thus
100d46bd72ec ("Merge
Intel Gen8/Gen9 graphics fixes from Jon Bloomfield.").
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Dave Airlie [Fri, 15 Nov 2019 02:34:39 +0000 (12:34 +1000)]
Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next
Two minor cleanups / fixes for -next.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m=20=28VMware=29?=
Link: https://patchwork.freedesktop.org/patch/msgid/20191114131703.8607-1-thomas_os@shipmail.org
Dave Airlie [Fri, 15 Nov 2019 02:16:43 +0000 (12:16 +1000)]
Merge tag 'drm-intel-next-fixes-2019-11-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- PMU "Frequency" is reported as accumulated cycles
- Avoid OOPS in dumb_create IOCTL when no CRTCs
- Mitigation for userptr put_pages deadlock with trylock_page
- Fix to avoid freeing heartbeat request too early
- Fix LRC coherency issue
- Fix Bugzilla #112212: Avoid screen corruption on MST
- Error path fix to unlock context on failed context VM SETPARAM
- Always consider holding preemption a privileged op in perf/OA
- Preload LUTs if the hw isn't currently using them to avoid color flash on VLV/CHV
- Protect context while grabbing its name for the request
- Don't resize aliasing ppGTT size
- Smaller fixes picked by tooling
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114085213.GA6440@jlahtine-desk.ger.corp.intel.com
Daniele Ceraolo Spurio [Tue, 5 Nov 2019 22:53:21 +0000 (14:53 -0800)]
drm/i915/guc: Properly capture & release GuC interrupts on Gen11+
With the new interrupt re-partitioning in Gen11, GuC controls by itself
the interrupts it receives, so steering bits and registers have been
defeatured. Being this the case, when the GuC is in control of
submissions we won't know what to do with the ctx switch interrupt
in the driver, so disable it.
v2 (Daniele): replace the gen9 paths instead of keeping gen9 and gen11
functions since we won't support guc submission on any pre-gen11 platform.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191105225321.26642-1-daniele.ceraolospurio@intel.com
Imre Deak [Thu, 14 Nov 2019 15:26:21 +0000 (17:26 +0200)]
drm/i915: Restore GT coarse power gating workaround
The workaround to disable coarse power gating is still needed on SKL
GT3/GT4 machines and since the RC6 context corruption was discovered by
the hardware team also on all GEN9 machines. Restore applying the
workaround.
Fixes:
c113236718e8 ("drm/i915: Extract GT render sleep (rc6) management")
Testcase: igt/intel_gt_pm_late_selftests/live_rc6_ctx
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Signed-off-by: Imre Deak <imre.deak@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/20191114152621.7235-1-imre.deak@intel.com
Ville Syrjälä [Thu, 20 Jun 2019 14:26:39 +0000 (17:26 +0300)]
drm/i915: Drop redundant aspec ratio prop value initialization
HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d
so no need to initialize conn_state->picture_aspect_ratio with it.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-6-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Thu, 20 Jun 2019 14:26:38 +0000 (17:26 +0300)]
drm/i915: Do not override mode's aspect ratio with the prop value NONE
HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that
selected we should keep whatever aspect ratio the mode already has.
Also no point in checking for connector->is_hdmi in the SDVO code
since we only attach the property to HDMI connectors.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-5-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Chris Wilson [Thu, 14 Nov 2019 17:25:35 +0000 (17:25 +0000)]
drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree
As we want to be able to run inside atomic context for retiring the
i915_active, and we are no longer allowed to abuse mutex_trylock, split
the tree management portion of i915_active.mutex into an irq-safe
spinlock.
References:
a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in IRQ contexts")
References: https://bugs.freedesktop.org/show_bug.cgi?id=111626
Fixes:
274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114172535.1116-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 12 Nov 2019 22:36:00 +0000 (22:36 +0000)]
drm/i915/selftests: Add coverage of mocs registers
Probe the mocs registers for new contexts and across GPU resets. Similar
to intel_workarounds, we have tables of what register values we expect
to see, so verify that user contexts are affected by them. In the
future, we should add tests similar to intel_sseu to cover dynamic
reconfigurations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112223600.30993-4-chris@chris-wilson.co.uk
Chris Wilson [Tue, 12 Nov 2019 22:35:59 +0000 (22:35 +0000)]
drm/i915/gt: Refactor mocs loops into single control macro
We repeatedly (and more so in future) use the same looping construct
over the mocs definition table to setup the register state. Refactor the
loop construct into a reusable macro.
add/remove: 2/1 grow/shrink: 1/2 up/down: 113/-330 (-217)
Function old new delta
intel_mocs_init_engine.cold - 71 +71
offset - 28 +28
__func__ 17273 17287 +14
intel_mocs_init 143 113 -30
mocs_register.isra 91 - -91
intel_mocs_init_engine 503 294 -209
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/20191112223600.30993-3-chris@chris-wilson.co.uk
Chris Wilson [Tue, 12 Nov 2019 22:35:58 +0000 (22:35 +0000)]
drm/i915/gt: Tidy up debug-warns for the mocs control table
As we always run new platforms through CI, we only need the debug code
compiled in during CI runs.
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/20191112223600.30993-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 12 Nov 2019 22:35:57 +0000 (22:35 +0000)]
drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all others
Be consistent in our mocs setup on Tigerlake and set the unused control
value to follow the PTE entry as we previously have done. The unused
values are beyond the defines of the ABI, the consistency simplifies our
checking.
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/20191112223600.30993-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 13 Nov 2019 18:06:33 +0000 (18:06 +0000)]
drm/i915/fbdev: Restore physical addresses for fb_mmap()
fbdev uses the physical address of our framebuffer for its fb_mmap()
routine. While we need to adapt this address for the new io BAR, we have
to fix v5.4 first! The simplest fix is to restore the smem back to v5.3
and we will then probably have to implement our fbops->fb_mmap() callback
to handle local memory.
Reported-by: Neil MacLeod <freedesktop@nmacleod.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256
Fixes:
5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Neil MacLeod <freedesktop@nmacleod.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113180633.3947-1-chris@chris-wilson.co.uk
YueHaibing [Fri, 1 Nov 2019 13:46:11 +0000 (21:46 +0800)]
drm/vmwgfx: remove set but not used variable 'srf'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:339:22:
warning: variable srf set but not used [-Wunused-but-set-variable]
'srf' is never used, so can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Thomas Hellstrom [Wed, 13 Nov 2019 18:02:42 +0000 (19:02 +0100)]
drm/ttm, drm/vmwgfx: Use a configuration option for the TTM dma page pool
Drivers like vmwgfx may want to test whether the dma page pool is present
or not. Since it's activated by default by TTM if compiled-in, define a
hidden configuration option that the driver can test for.
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Lionel Landwerlin [Wed, 13 Nov 2019 15:46:39 +0000 (17:46 +0200)]
drm/i915/perf: don't forget noa wait after oa config
I'm observing incoherence metric values, changing from run to run.
It appears the patches introducing noa wait & reconfiguration from
command stream switched places in the series multiple times during the
review. This lead to the dependency of one onto the order to go
missing...
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes:
15d0ace1f876 ("drm/i915/perf: execute OA configuration from command stream")
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/20191113154639.27144-1-lionel.g.landwerlin@intel.com
Dave Airlie [Thu, 14 Nov 2019 01:06:01 +0000 (11:06 +1000)]
Backmerge i915 security patches from commit '
ea0b163b13ff' into drm-next
This backmerges the branch that ended up in Linus' tree. It removes
all the changes for the rc6 patches from Linus' tree in favour of
a patch that is based on a large refactor that occured.
Otherwise it all looks good.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Imre Deak [Thu, 17 Oct 2019 13:38:31 +0000 (16:38 +0300)]
drm/i915/gen8+: Add RC6 CTX corruption WA
In some circumstances the RC6 context can get corrupted. We can detect
this and take the required action, that is disable RC6 and runtime PM.
The HW recovers from the corrupted state after a system suspend/resume
cycle, so detect the recovery and re-enable RC6 and runtime PM.
v2: rebase (Mika)
v3:
- Move intel_suspend_gt_powersave() to the end of the GEM suspend
sequence.
- Add commit message.
v4:
- Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API
change.
v5:
- Rebased on latest upstream gt_pm refactoring.
v6:
- s/i915_rc6_/intel_rc6_/
- Don't return a value from i915_rc6_ctx_wa_check().
v7:
- Rebased on latest gt rc6 refactoring.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
[airlied: pull this later version of this patch into drm-next
to make resolving the conflict mess easier.]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Radhakrishna Sripada [Wed, 13 Nov 2019 23:19:53 +0000 (15:19 -0800)]
drm/i915/tgl: Wa_1606679103
Extend disabling SAMPLER_STATE prefetch workaround to gen12.
v2: Limit the WA to TGL A0 and update the WA no(Chris)
BSpec: 52890
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@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/20191113231953.24853-1-radhakrishna.sripada@intel.com
Dave Airlie [Wed, 13 Nov 2019 23:28:30 +0000 (09:28 +1000)]
Merge tag 'arcpgu-updates-2019.07.18' of github.com:abrodkin/linux into drm-next
This is a pretty simple improvement that allows to find encoder
as the one and only (ARC PGU doesn't support more than one) endpoint
instead of using non-standard "encoder-slave" property.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CY4PR1201MB0120FDB10A777345F9C27720A1C90@CY4PR1201MB0120.namprd12.prod.outlook.com
Bruce Chang [Wed, 13 Nov 2019 23:11:04 +0000 (15:11 -0800)]
drm/i915: Avoid atomic context for error capture
io_mapping_map_atomic/kmap_atomic are occasionally taken in error capture
(if there is no aperture preallocated for the use of error capture), but
the error capture and compression routines are now run in normal
context:
<3> [113.316247] BUG: sleeping function called from invalid context at mm/page_alloc.c:4653
<3> [113.318190] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name: debugfs_test
<4> [113.319900] no locks held by debugfs_test/678.
<3> [113.321002] Preemption disabled at:
<4> [113.321130] [<
ffffffffa02506d4>] i915_error_object_create+0x494/0x610 [i915]
<4> [113.327259] Call Trace:
<4> [113.327871] dump_stack+0x67/0x9b
<4> [113.328683] ___might_sleep+0x167/0x250
<4> [113.329618] __alloc_pages_nodemask+0x26b/0x1110
<4> [113.334614] pool_alloc.constprop.19+0x14/0x60 [i915]
<4> [113.335951] compress_page+0x7c/0x100 [i915]
<4> [113.337110] i915_error_object_create+0x4bd/0x610 [i915]
<4> [113.338515] i915_capture_gpu_state+0x384/0x1680 [i915]
However, it is not a good idea to run the slow compression inside atomic
context, so we choose not to.
Fixes:
895d8ebeaa924 ("drm/i915: error capture with no ggtt slot")
Signed-off-by: Bruce Chang <yu.bruce.chang@intel.com>
Reviewed-by: Brian Welty <brian.welty@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/20191113231104.24208-1-yu.bruce.chang@intel.com
Dave Airlie [Wed, 13 Nov 2019 22:51:02 +0000 (08:51 +1000)]
Merge tag 'drm-misc-next-fixes-2019-11-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
- Fix memory leak in gpu debugfs node's release (Johan)
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113211056.GA78440@art_vandelay
Dave Airlie [Wed, 13 Nov 2019 22:43:06 +0000 (08:43 +1000)]
Merge tag 'drm-next-5.5-2019-11-08' of git://people.freedesktop.org/~agd5f/linux into drm-next
drm-next-5.5-2019-11-08:
amdgpu:
- Enable VCN dynamic powergating on RV/RV2
- Fixes for Navi14
- Misc Navi fixes
- Fix MSI-X tear down
- Misc Arturus fixes
- Fix xgmi powerstate handling
- Documenation fixes
scheduler:
- Fix static code checker warning
- Fix possible thread reactivation while thread is stopped
- Avoid cleanup if thread is parked
radeon:
- SI dpm fix ported from amdgpu
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108212713.5078-1-alexander.deucher@amd.com
Lucas De Marchi [Wed, 13 Nov 2019 02:19:35 +0000 (18:19 -0800)]
drm/i915/tgl: allow DVI/HDMI on port A
Tiger Lake supports HDMI on port A. For other platforms we ignore what
the VBT says regarding HDMI to workaround broken VBTs, see
commit
2ba7d7e04371 ("drm/i915/bios: ignore HDMI on port A"). Make this
apply gen12+ so they inherit the TGL behavior.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113021935.41547-1-lucas.demarchi@intel.com
José Roberto de Souza [Thu, 7 Nov 2019 21:45:59 +0000 (13:45 -0800)]
drm/i915/display/mst: Enable virtual channel payload allocation earlier
This register was being enabled after enable TRANS_DDI_FUNC_CTL and
PIPECONF/TRANS_CONF while BSpec states that it should be set when
enabling TRANS_DDI_FUNC_CTL.
BSpec: 49190
BSpec: 22243
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: 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/20191107214559.77087-3-jose.souza@intel.com
José Roberto de Souza [Thu, 7 Nov 2019 21:45:58 +0000 (13:45 -0800)]
drm/i915/display/dsi: Add support to pipe D
Adding pipe D support to DSI transcoder.
Not adding it for EDP transcoder code paths as only TGL has 4 pipes
and it do not have a EDP transcoder.
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: 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/20191107214559.77087-2-jose.souza@intel.com
José Roberto de Souza [Thu, 7 Nov 2019 21:45:57 +0000 (13:45 -0800)]
drm/i915/display: Fix TRANS_DDI_MST_TRANSPORT_SELECT definition
TRANS_DDI_MST_TRANSPORT_SELECT is 2 bits wide not 3, it was taking
one bit from EDP/DSI Input Select.
Fixes:
b3545e086877 ("drm/i915/tgl: add support to one DP-MST stream")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107214559.77087-1-jose.souza@intel.com
Johan Hovold [Thu, 10 Oct 2019 13:13:30 +0000 (15:13 +0200)]
drm/msm: fix memleak on release
If a process is interrupted while accessing the "gpu" debugfs file and
the drm device struct_mutex is contended, release() could return early
and fail to free related resources.
Note that the return value from release() is ignored.
Fixes:
4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state")
Cc: stable <stable@vger.kernel.org> # 4.18
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010131333.23635-2-johan@kernel.org
Dave Airlie [Wed, 13 Nov 2019 19:53:10 +0000 (05:53 +1000)]
Merge v5.4-rc7 into drm-next
We have the i915 security fixes to backmerge, but first
let's clear the decks for other drivers to avoid a bigger
mess.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Lucas De Marchi [Fri, 8 Nov 2019 21:13:52 +0000 (13:13 -0800)]
drm/i915/bios: make sure to check vbt size
When we call intel_bios_is_valid_vbt(), size may not actually be the
size of the VBT, but rather the size of the blob the VBT is contained
in. For example, when mapping the PCI oprom, size will be the entire
oprom size. We don't want to read beyond what is reported to be the
VBT. So make sure we vbt->vbt_size makes sense and use that for
the latter checks.
v2: check for vbt_size after checking for vbt signature and give it a
more meaningful error message (from Jani)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-3-lucas.demarchi@intel.com
Lucas De Marchi [Fri, 8 Nov 2019 21:13:51 +0000 (13:13 -0800)]
drm/i915/bios: rename bios to oprom when mapping pci rom
oprom is actually a better name to use when using
pci_map_rom(). "bios" is way too generic and confusing.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-2-lucas.demarchi@intel.com
Chris Wilson [Wed, 13 Nov 2019 15:19:56 +0000 (15:19 +0000)]
drm/i915/gt: Invalidate as we write the gen7 breadcrumb
Still the saga of the hsw live_blt incoherency continues. While it did
seem that the invalidate before the breadcrumb had improved the mtbf,
nevertheless live_blt still failed. Mika's next idea was to pull the
invalidate-stall into the breadcrumb write itself.
References:
860afa086841 ("drm/i915/gt: Flush gen7 even harder")
References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
Testcase: igt/i915_selftest/live_blt
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/20191113151956.32242-1-chris@chris-wilson.co.uk
Matt Roper [Tue, 12 Nov 2019 22:47:57 +0000 (14:47 -0800)]
drm/i915/tgl: MOCS table update
The bspec was just updated with a minor correction to entry 61 (it
shouldn't have had the SCF bit set).
v2:
- Add a MOCS_ENTRY_UNUSED() and use it to declare the
explicitly-reserved MOCS entries. (Lucas)
- Move the warning suppression from the Makefile to a #pragma that only
affects the TGL table. (Lucas)
v3:
- Entries 16 and 17 are identical to ICL now, so no need to explicitly
adjust them (or mess with compiler warning overrides).
Bspec: 45101
Fixes:
2ddf992179c4 ("drm/i915/tgl: Define MOCS entries for Tigerlake")
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Francisco Jerez <francisco.jerez.plata@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112224757.25116-2-matthew.d.roper@intel.com
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Matt Roper [Tue, 12 Nov 2019 22:47:56 +0000 (14:47 -0800)]
Revert "drm/i915/ehl: Update MOCS table for EHL"
This reverts commit
f4071997f1de016780ec6b79c63d90cd5886ee83.
These extra EHL entries won't behave as expected without a bit more work
on the kernel side so let's drop them until that kernel work has had a
chance to land. Userspace trying to use these new entries won't get the
advantage of the new functionality these entries are meant to provide,
but at least it won't misbehave.
When we do add these back in the future, we'll probably want to
explicitly use separate tables for ICL and EHL so that userspace
software that mistakenly uses these entries (which are undefined on ICL)
sees the same behavior it sees with all the other undefined entries.
Cc: Francisco Jerez <francisco.jerez.plata@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <stable@vger.kernel.org> # v5.3+
Fixes:
f4071997f1de ("drm/i915/ehl: Update MOCS table for EHL")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112224757.25116-1-matthew.d.roper@intel.com
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Gwan-gyeong Mun [Wed, 13 Nov 2019 12:52:41 +0000 (14:52 +0200)]
drm/i915: Split a setting of MSA to MST and SST
The setting of MSA is done by the DDI .pre_enable() hook. And when we are
using MST, the MSA is only set to first mst stream by calling of
DDI .pre_eanble() hook. It raies issues to non-first mst streams.
Wrong MSA or missed MSA packets might show scrambled screen or wrong
screen.
This splits a setting of MSA to MST and SST cases. And In the MST case it
will call a setting of MSA after an allocating of Virtual Channel from
MST encoder pre_enable callback.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112212
Fixes:
0c06fa156006 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA")
Fixes:
d4a415dcda35 ("drm/i915: Fix MST oops due to MSA changes")
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191106212636.502471-1-gwan-gyeong.mun@intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
[vsyrjala: nuke spurious newline]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit
bd8c9cca88765caee0dfa93967c6d8f16b4cbfb9)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113125241.20547-1-ville.syrjala@linux.intel.com
Imre Deak [Tue, 12 Nov 2019 10:46:08 +0000 (12:46 +0200)]
drm/i915: Fix detection for a CMP-V PCH
According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
belongs to a CMP-V chipset. Based on the same docs the programming of
the PCH is compatible with that of KBP. Fix up my previous wrong
assumption accordingly using the SPT programming which in turn is the
basis for KBP.
The original bug reporter verified that this is the correct PCH
identification (the only way we'll program valid DDC pin-pair values to
the GMBUS register) and the Windows team uses the same identification
(that is using the KBP programming model for this PCH).
I filed the necessary Bspec update requests (BSpec/33734).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051
Fixes:
37c92dc303dd ("drm/i915: Add new CNL PCH ID seen on a CML platform")
Reported-and-tested-by: Cyrus <cyrus.lien@canonical.com>
Cc: Cyrus <cyrus.lien@canonical.com>
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112104608.24587-1-imre.deak@intel.com
Chris Wilson [Mon, 11 Nov 2019 13:32:05 +0000 (13:32 +0000)]
drm/i915/execlists: Move reset_active() from schedule-out to schedule-in
The gem_ctx_persistence/smoketest was detecting an odd coherency issue
inside the LRC context image; that the address of the ring buffer did
not match our associated struct intel_ring. As we set the address into
the context image when we pin the ring buffer into place before the
context is active, that leaves the question of where did it get
overwritten. Either the HW context save occurred after our pin which
would imply that our idle barriers are broken, or we overwrote the
context image ourselves. It is only in reset_active() where we dabble
inside the context image outside of a serialised path from schedule-out;
but we could equally perform the operation inside schedule-in which is
then fully serialised with the context pin -- and remains serialised by
the engine pulse with kill_context(). (The only downside, aside from
doing more work inside the engine->active.lock, was the plan to merge
all the reset paths into doing their context scrubbing on schedule-out
needs more thought.)
Fixes:
d12acee84ffb ("drm/i915/execlists: Cancel banned contexts on schedule-out")
Testcase: igt/gem_ctx_persistence/smoketest
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-3-chris@chris-wilson.co.uk
(cherry picked from commit
31b61f0ef9af62b6404d8df5dcd2cf58f80c9f53)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Lucas De Marchi [Fri, 8 Nov 2019 21:42:51 +0000 (13:42 -0800)]
drm/i915: do not warn late about hdmi on port A
The warning should be just a warning. Where it is currently is wrong
since we already registered the connector on drm, meaning it dies later
on a NULL pointer deref if the VBT-overriding we have is removed. Move
the warning up.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108214251.79305-1-lucas.demarchi@intel.com
Chris Wilson [Tue, 12 Nov 2019 16:09:41 +0000 (16:09 +0000)]
drm/i915/gt: Flush gen7 even harder
live_blt is still failing on hsw, showing the hallmark of incoherency.
Since we are fairly certain that the interrupt is after the seqno is
visible, the other possibility is that the seqno is before the writes to
memory are flushed. Throw in an TLB invalidate before the breadcrumb as
we are reasonably confident that forces a CS stall.
References:
f9228f765873 ("drm/i915/gt: Try an extra flush on the Haswell blitter")
References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
Testcase: igt/i915_selftest/live_blt
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/20191112160941.23969-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 12 Nov 2019 16:36:43 +0000 (16:36 +0000)]
drm/i915/selftests: Remove unused local variable 'file'
drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c:453 igt_threaded_blt() error: uninitialized symbol 'file'.
Fixes:
34485832cb98 ("drm/i915/selftests: Exercise parallel blit operations on a single ctx")
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/20191112163643.3527-1-chris@chris-wilson.co.uk