Implement the DP-Audio cdclk restriction for GLK, similar to what is
implemented for BDW and other GEN9 platforms. The max. pixel clock
adjustment for GLK, however factors in the 2 pixels per clock output that
GLK generates.
Separating min. cdclk and max. pixel_rate would be nicer, but let's
defer that to future and fix the GLK bug for now.
Chris Wilson [Tue, 21 Mar 2017 10:25:52 +0000 (10:25 +0000)]
drm/i915: Remove intel_ring.last_retired_head
Storing the position of the breadcrumb of the last retired request as
a separate last_retired_head is superfluous as we always copy that into
head prior to recalculation of the intel_ring.space.
Chris Wilson [Tue, 21 Mar 2017 11:33:20 +0000 (11:33 +0000)]
drm/i915/execlists: Split the atomic test_and_clear_bit for irq handler
Rather than impose the cost of a locked test before queuing a new
request, reduce it to a simple test_bit() with a following clear_bit()
prior to doing the CSB check. This ensure that if an interrupt does
occur whilst reading from the CSB, we still detect it (the interrupt
would trigger a rescheduling of the tasklet anyway).
Arnd Bergmann [Mon, 20 Mar 2017 09:40:28 +0000 (10:40 +0100)]
drm/i915: split out check for noncontiguous pfn range
We get a warning with gcc-7 about a pointless comparison when
using a linear memmap:
drivers/gpu/drm/i915/selftests/scatterlist.c: In function 'alloc_table':
drivers/gpu/drm/i915/selftests/scatterlist.c:219:66: error: self-comparison always evaluates to false [-Werror=tautological-compare]
Splitting out the comparison into a separate function avoids the warning
and makes it slightly more obvious what happens.
As intel_engine_init_global_seqno() may be called by
nop_submit_request() from inside irq context, we have to use atomic
versions of kmap/kunmap. This is rare as this requires using gen8 legacy
ringbuffer submission.
Chris Wilson [Mon, 20 Mar 2017 14:31:33 +0000 (14:31 +0000)]
drm/i915: Protect intel_engine_wakeup() for call from irq context
intel_engine_wakeup() is called by nop_request_submit() which is
installed to handle third party fences completed from within irq
context. As such, it needs the full irqsave/irqrestore and not the
partial spin_irq_lock handling.
Fixes: cdc3a4539034 ("drm/i915: No need to save/restore irq status in intel_engine_wakeup") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170320143133.1507-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Tvrtko Ursulin [Mon, 20 Mar 2017 13:25:56 +0000 (13:25 +0000)]
drm/i915/guc: Correct the request_in tracepoint position
It has to be called after the global seqno has been assigned.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 31de73501ac9 ("drm/i915/scheduler: emulate a scheduler for guc") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170320132556.29286-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Sat, 18 Mar 2017 10:42:57 +0000 (10:42 +0000)]
drm/i915: Skip force-wake for uncached mmio flush of GGTT writes
The trick of using an uncached mmio read to ensure that the GGTT writes
are flushed does not require us to do the forcewake dance, so avoid it
in the hope of reducing the frequency that we do keep the device forced
awake.
Chris Wilson [Sat, 18 Mar 2017 10:28:59 +0000 (10:28 +0000)]
drm/i915: Reset tasklet back to execlists after disabling guc
When switching back to execlists, we also now need to restore the
tasklet handler.
Reported-by: Oscar Mateo <oscar.mateo@intel.com> Fixes: 31de73501ac9 ("drm/i915/scheduler: emulate a scheduler for guc") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170318102859.24101-1-chris@chris-wilson.co.uk Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Chris Wilson [Thu, 16 Mar 2017 13:19:53 +0000 (13:19 +0000)]
drm/i915: Retire an active batch pool object rather than allocate new
Since obj->active_count is only updated upon retirement, if we see an
active object in the batch pool, double check that is still active
before deciding to allocate a new object.
Chris Wilson [Mon, 13 Mar 2017 11:28:10 +0000 (11:28 +0000)]
drm/i915: Add i810/i815 pci-ids for completeness
To improve our historical record and to simplify userspace that wants to
include i915_pciids.h as its canonical breakdown of PCI IDs and their
respective generations, include the gen1 ids for i810 and i815.
Chris Wilson [Fri, 17 Mar 2017 12:07:16 +0000 (12:07 +0000)]
drm/i915: Skip execlists_dequeue() early if the list is empty
Do an early read of the execlists' queue before we take the spinlock and
start checking. This is safe as the first writer to the execlists queue
will cause the tasklet to be run again after a memory barrier.
v2: Keep guc in sync with execlists queue changes
v3: Explain the mb between the tasklet running on one cpu and the
execlist_first update and schedule from a second cpu.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170317120716.17191-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 16 Mar 2017 13:19:57 +0000 (13:19 +0000)]
drm/i915: Stop using obj->obj_exec_link outside of execbuf
i915_gem_stolen_list_info() sneakily takes advantage of the
obj->obj_exec_link to save itself from having to allocate. Enough of the
subterfuge, just allocate an array of pointers and sort them instead of
the list.
Chris Wilson [Fri, 17 Mar 2017 12:59:18 +0000 (12:59 +0000)]
drm/i915: Squelch WARN for VLV_COUNTER_CONTROL
Before rc6 is initialised (after driver load or resume), the value inside
VLV_COUNTER_CONTROL is undefined so we cannot make an assertion that is
in HIGH_RANGE mode.
Fixes: 6b7f6aa75e38 ("drm/i915: Use coarse grained residency counter with byt")
Testcase: igt/drv_suspend/debugfs-reader Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170317125918.11351-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
It is unclear if the recommendation to disable it for 2x6 configurations
from commit e015dd69b2cf ("drm/i915/bxt: Add WaEnablePooledEuFor2x6")
should also apply to GLK, but it is applied anyway to be on the safe
side. That restriction can be lifted later if determined not to impact
performance.
The extra restriction should not impact user space either. The only user
space that uses this feature is Beignet, and it only does so for 3x6
devices. See See Beignet's commit 6901899ec90a ("Runtime: set the sub
slice according to kernel pooled EU configure.").
v2: Improve commit message. (Mika, Roy)
Cc: Arun Siluvery <arun.siluvery@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Yang Rong <rong.r.yang@intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170317140436.24645-1-ander.conselvan.de.oliveira@intel.com
The only time we need to emit a flush inside request emission is after
an execbuffer, for which we can use the full __i915_add_request(). All
other instances want the simpler i915_add_request() without flushing, so
remove the useless helper.
Tvrtko Ursulin [Fri, 10 Mar 2017 09:57:47 +0000 (09:57 +0000)]
drm/i915/vgpu: Neuter forcewakes for VGPU more thoroughly
If we avoid initializing forcewake domains when running as
a guest, and also use gen2 mmio accessors in that case, we
can avoid the timer traffic and any looping through the
forcewake code which is currently just so it can end up in
the no-op forcewake implementation.
Zhenyu Wang [Fri, 10 Mar 2017 02:22:38 +0000 (10:22 +0800)]
drm/i915: Fix vGPU balloon for ggtt guard page
From commit a6508ded2a66 ("drm/i915: Use page coloring to provide the guard
page at the end of the GTT"), we no longer explicitly subtract guard page
at end for GGTT address space init, so shouldn't subtract that for vGPU
balloon too, as that will leave that end page to be available for
vGPU. Change balloon to cover full range too.
This fixes to use recent drm-intel tip kernel for guest OS. Found by GVT-g
cmd parser that guest kernel uses end page as scratch then try to run
MI_STORE_REG_MEM onto it.
Chris Wilson [Thu, 16 Mar 2017 20:42:35 +0000 (20:42 +0000)]
drm/i915: Avoid use-after-free of ctx in request tracepoints
trace_i915_gem_request_out may be used after the request is completed,
and so the request may have been retired on another thread, invalidating
the rq->ctx. Avoid dereferencing rq->ctx in the tracepoint by switching
to the fence context id instead, updating all tracepoints to match.
Chris Wilson [Thu, 16 Mar 2017 17:13:04 +0000 (17:13 +0000)]
drm/i915: Restore engine->submit_request before unwedging
When we wedge the device, we override engine->submit_request with a nop
to ensure that all in-flight requests are marked in error. However, igt
would like to unwedge the device to test -EIO handling. This requires us
to flush those in-flight requests and restore the original
engine->submit_request.
v2: Use a vfunc to unify enabling request submission to engines
v3: Split new vfunc to a separate patch.
v4: Make the wait interruptible -- the third party fences we wait upon
may be indefinitely broken, so allow the reset to be aborted.
Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Testcase: igt/gem_eio Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v3 Link: http://patchwork.freedesktop.org/patch/msgid/20170316171305.12972-3-chris@chris-wilson.co.uk
Chris Wilson [Thu, 16 Mar 2017 17:13:03 +0000 (17:13 +0000)]
drm/i915: Move engine->submit_request selection to a vfunc
It turns out that we may want to restore the original
engine->submit_request (and engine->schedule) callbacks from more than
just the guc <-> execlists transition. Move this to a vfunc so we can
have a common interface.
v2: Move initial selection to intel_engines_init_common(), repaint vfunc
with engine->set_default_submission (and a similar colour for the
helper).
Chris Wilson [Thu, 16 Mar 2017 17:13:02 +0000 (17:13 +0000)]
drm/i915: Split I915_RESET_IN_PROGRESS into two flags
I915_RESET_IN_PROGRESS is being used for both signaling the requirement
to i915_mutex_lock_interruptible() to avoid taking the struct_mutex and
to instruct a waiter (already holding the struct_mutex) to perform the
reset. To allow for a little more coordination, split these two meaning
into a couple of distinct flags. I915_RESET_BACKOFF tells
i915_mutex_lock_interruptible() not to acquire the mutex and
I915_RESET_HANDOFF tells the waiter to call i915_reset().
Changbin Du [Mon, 13 Mar 2017 02:47:11 +0000 (10:47 +0800)]
drm/i915: make context status notifier head be per engine
GVTg has introduced the context status notifier to schedule the GVTg
workload. At that time, the notifier is bound to GVTg context only,
so GVTg is not aware of host workloads.
Now we are going to improve GVTg's guest workload scheduler policy,
and add Guc emulation support for new Gen graphics. Both these two
features require acknowledgment for all contexts running on hardware.
(But will not alter host workload.) So here try to make some change.
The change is simple:
1. Move the context status notifier head from i915_gem_context to
intel_engine_cs. Which means there is a notifier head per engine
instead of per context. Execlist driver still call notifier for
each context sched-in/out events of current engine.
2. At GVTg side, it binds a notifier_block for each physical engine
at GVTg initialization period. Then GVTg can hear all context
status events.
In this patch, GVTg do nothing for host context event, but later
will add a function there. But in any case, the notifier callback is
a noop if this is no active vGPU.
Since intel_gvt_init() is called at early initialization stage and
require the status notifier head has been initiated, I initiate it in
intel_engine_setup().
v2: remove a redundant newline. (chris)
Fixes: 3c7ba6359d70 ("drm/i915: Introduce execlist context status change notification")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100232 Signed-off-by: Changbin Du <changbin.du@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170313024711.28591-1-changbin.du@intel.com Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Thu, 16 Mar 2017 12:56:18 +0000 (12:56 +0000)]
drm/i915/scheduler: emulate a scheduler for guc
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up after every request to feed new commands into the GuC).
v2: Drop hack status - though iirc there is still a lockdep inversion
between fence and engine->timeline->lock (which is impossible as the
nesting only occurs on different fences - hopefully just requires some
judicious lockdep annotation)
v3: Apply lockdep nesting to enabling signaling on the request, using
the pattern we already have in __i915_gem_request_submit();
v4: Replaying requests after a hang also now needs the timeline
spinlock, to disable the interrupts at least
v5: Hold wq lock for completeness, and emit a tracepoint for enabling signal
v6: Reorder interrupt checking for a happier gcc.
v7: Only signal the tasklet after a user-interrupt if using guc scheduling
v8: Restore lost update of rq through the i915_guc_irq_handler (Tvrtko)
v9: Avoid re-initialising the engine->irq_tasklet from inside a reset
v10: Hook up the execlists-style tracepoints
v11: Clear the execlists irq_posted bit after taking over the interrupt/tasklet
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170316125619.6856-1-chris@chris-wilson.co.uk Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Chris Wilson [Tue, 14 Mar 2017 11:14:52 +0000 (11:14 +0000)]
drm/i915: Replace irq_seqno_barrier on hws write with a clflush
When manually overwriting the HWS, rather than assume irq_seqno_barrier
does the right thing, we can explicitly flush the cacheline instead.
This avoids us calling the engine->irq_seqno_barrier() from an illegal
context:
Mika Kuoppala [Wed, 15 Mar 2017 16:12:59 +0000 (18:12 +0200)]
drm/i915: Use coarse grained residency counter with byt
Set byt rc residency counters high level as chv does by
default. We lose some accuracy on byt but we can do the calculation
without extra hw read on both platforms, as now they behave
identically in this respect.
Mika Kuoppala [Wed, 15 Mar 2017 15:43:03 +0000 (17:43 +0200)]
drm/i915: Use ktime to calculate rc0 residency
We have used cz timestamp register to gain a reference time wrt
to residency calculations. The residency counts are in cz clk ticks
(333Mhz clock) but for some reason the cz timestamp register gives
100us units. Perhaps for some other usage, the base-ten based values
are easier, but in residency calculations raw units would have been
the easiest.
As there is not much advantage of using base-ten clock through
a more costly punit access, take our reference times directly from
kernel clock.
v2: use ktime (Chris, Ville)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=94852 Reported-by: Len Brown <len.brown@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Mika Kuoppala [Wed, 15 Mar 2017 15:43:00 +0000 (17:43 +0200)]
drm/i915: Return residency as microseconds
Change the granularity from milliseconds to microseconds
when returning rc6 residencies. This is in preparation
for increased resolution on some platforms.
v2: use 64bit div macro (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
lockdep doesn't like us taking the mm->mmap_sem inside the get_pages
callback for a couple of reasons. The straightforward deadlock:
[13755.434059] =============================================
[13755.434061] [ INFO: possible recursive locking detected ]
[13755.434064] 4.11.0-rc1-CI-CI_DRM_297+ #1 Tainted: G U
[13755.434066] ---------------------------------------------
[13755.434068] gem_userptr_bli/8398 is trying to acquire lock:
[13755.434070] (&mm->mmap_sem){++++++}, at: [<ffffffffa00c988a>] i915_gem_userptr_get_pages+0x5a/0x2e0 [i915]
[13755.434096]
but task is already holding lock:
[13755.434098] (&mm->mmap_sem){++++++}, at: [<ffffffff8104d485>] __do_page_fault+0x105/0x560
[13755.434105]
other info that might help us debug this:
[13755.434108] Possible unsafe locking scenario:
By checking the status of the gup worker (serialized by the
obj->mm.lock) we can determine whether it is still active, has failed or
has succeeded. If the worker is still active (or failed), we know that
it cannot be bound and so we can skip taking struct_mutex (risking
potential recursion). As we check the worker status, we mark it to
discard any partial results, forcing us to restart on the next
get_pages.
Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Fixes: 1c8782dd313e ("drm/i915/userptr: Disallow wrapping GTT into a userptr")
Testcase: igt/gem_userptr_blits/map-fixed-invalidate-gup
Testcase: igt/gem_userptr_blits/dmabuf-sync Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170315140150.19432-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Michal Wajdeczko [Wed, 15 Mar 2017 13:37:41 +0000 (13:37 +0000)]
drm/i915: Make intel_uc_sanitize_options() more robust
After negative guc fw selection we could leave guc
submission flag still turned on. Reorder some checks
to cover this case. While here, fix info message and
return early if there is no Guc.
Chris Wilson [Wed, 15 Mar 2017 21:07:26 +0000 (21:07 +0000)]
drm/i915: Only attempt to signal the request once from the interrupt handler
Check that request has not been signaled before acquiring a reference to
the request for signaling later in the interrupt handler.
The loading of the cacheline (for request->fence.flags) should be "free"
when followed by the locked increment of the request->fence.refcount
(which then sets the cacheline to exclusive mode), i.e. the cost of
test_bit prior to an atomic_inc should be negligible. This should
benefit us when we have a pile of bare breadcrumbs (interrupted execbuf)
where we may get interrupts faster than we can get rid of the
intel_wait, or if the device is too slow to run the bottom-half between
interrupts.
Chris Wilson [Wed, 15 Mar 2017 21:07:25 +0000 (21:07 +0000)]
drm/i915/breadcrumbs: Assert that we do not shortcut the current bottom-half
We need to ensure that we always serialize updates to the bottom-half
using the breadcrumbs.irq_lock so that we don't race with a concurrent
interrupt handler. This is most important just prior to leaving the
waiter (when the intel_wait will be overwritten), so make sure we are
not the current bottom-half when skipping the irq locks.
Chris Wilson [Wed, 15 Mar 2017 21:07:24 +0000 (21:07 +0000)]
drm/i915/breadcrumbs: Disable interrupt bottom-half first on idling
Before walking the rbtree of waiters (marking them as complete and waking
them), decouple the interrupt handler. This prevents a race between the
missed waiter waking up and removing its intel_wait (which skips
checking the lock) and the interrupt handler dereferencing the
intel_wait. (Though we do not expect to encounter waiters during idle!)
Chris Wilson [Wed, 15 Mar 2017 21:07:23 +0000 (21:07 +0000)]
drm/i915/breadcrumbs: Update bottom-half before marking as complete
When adding a new request to the breadcrumb rbtree, we mark all those
requests inside the rbtree that are already completed as complete. This
wakes those waiters up and allows them to skip the spinlock before
returning to userspace. If one of those is the current bottom-half and
allocated its intel_wait on the stack, it may then overwrite the
b->irq_wait upon exiting i915_wait_request() just as the interrupt handler
dereferences it.
Fixes: 56299fb7d904 ("drm/i915: Signal first fence from irq handler if complete") 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: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170315210726.12095-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 15 Mar 2017 21:07:22 +0000 (21:07 +0000)]
drm/i915/breadcrumbs: Use booleans for intel_breadcrumbs_busy()
Since commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")
converted intel_breadcrumbs_busy() to reporting a single boolean, we
need only compute a boolean internally (and not needlessly compute the
flag).
Chris Wilson [Tue, 14 Mar 2017 17:18:40 +0000 (17:18 +0000)]
drm/i915: Extend rpm wakelock during i915_handle_error()
We take the runtime pm wakelock during i915_handle_error() to ensure
that all paths that reach the error handler keep the device awake during
the hw reads. However, we need to extend that from the reset handler to
include the earlier capture routines.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170314133309.126432-1-michal.wajdeczko@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Arkadiusz Hiler [Tue, 14 Mar 2017 14:28:12 +0000 (15:28 +0100)]
drm/i915/uc: Simplify firmware path handling
Currently fw->path values can represent one of three possible states:
1) NULL - device without the uC
2) '\0' - device with the uC but have no firmware
3) else - device with the uC and we have firmware
Second case is used only to WARN at a later stage.
We can WARN right away and merge cases 1 and 2.
Code can be even further simplified and common (HuC/GuC logic) happening
right before the fetch can be offloaded to the common function.
v2: fewer temporary variables, more straightforward flow (M. Wajdeczko)
v3: DRM_ERROR instead of WARN (M. Wajdeczko)
v4: coding standard (J. Lahtinen)
v5: non-trivial rebase
v6: remove path check, we are checking fetch status (M. Wajdeczko)
Arkadiusz Hiler [Tue, 14 Mar 2017 14:28:11 +0000 (15:28 +0100)]
drm/i915/guc: Simplify intel_guc_init_hw()
Current version of intel_guc_init_hw() does a lot:
- cares about submission
- loads huc
- implement WA
This change offloads some of the logic to intel_uc_init_hw(), which now
cares about the above.
v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko)
v3: rename once again
v4: remove spurious comments and add some style (J. Lahtinen)
v5: flow changes, got rid of dead checks (M. Wajdeczko)
v6: rebase
v7: rebase & onion teardown (J. Lahtinen)
Arkadiusz Hiler [Tue, 14 Mar 2017 14:28:10 +0000 (15:28 +0100)]
drm/i915/guc: Extract param logic form guc_init_fw()
Let intel_guc_init_fw() focus on determining and fetching the correct
firmware.
This patch introduces intel_uc_sanitize_options() that is called from
intel_sanitize_options().
Then, if we have GuC, we can call intel_guc_init_fw() conditionally
and we do not have to do the internal checks.
v2: fix comment, notify when nuking GuC explicitly enabled (M. Wajdeczko)
v3: fix comment again, change the nuke message (M. Wajdeczko)
v4: update title to reflect new function name + rebase
v5: text && remove 2 uneccessary checks (M. Wajdeczko)
Arkadiusz Hiler [Tue, 14 Mar 2017 14:28:09 +0000 (15:28 +0100)]
drm/i915/uc: Introduce intel_uc_init_fw()
Instead of calling intel_guc_init() and intel_huc_init() one by one this
patch introduces intel_uc_init_fw() function that calls them both.
Called functions are renamed accordingly.
Trying to have subject_verb_object ordering and more descriptive names,
the intel_huc_init() and intel_guc_init() functions are renamed.
For guc_init():
* `intel_guc` is the subject, so those functions now take intel_guc
structure, instead of the dev_priv
* init is the verb
* fw is the object which better describes the function's role
huc_init() change follows the same reasoning.
v2: settle on intel_uc_fetch_fw name (M. Wajdeczko)
v3: yet another rename - intel_uc_init_fw (J. Lahtinen)
v4: non-trivial rebase
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Arkadiusz Hiler [Tue, 14 Mar 2017 14:28:08 +0000 (15:28 +0100)]
drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c
The file fits better.
Additionally rename it to intel_uc_prepare_fw(), as the function does
more than simple fetch.
`obj` cleanup in the function is also fixed (i.e. removed). In the fail
scenario it was always 'put' but there's no possible flow that
initializes the obj properly and then goes to the fail label.
v2: remove second declaration, reorder (M. Wajdeczko)
v3: non-trivial rebase
v4: remove obj cleanup in the fail scenario (C. Wilson)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Arkadiusz Hiler [Tue, 14 Mar 2017 14:28:07 +0000 (15:28 +0100)]
drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()
GuC historically has two "startup" functions called _init() and _setup()
Then HuC came with it's _init() and _load().
This commit renames intel_guc_setup() and intel_huc_load() to
*uc_init_hw() as they called from the i915_gem_init_hw().
The aim is to be consistent in that entry points called during
particular driver init phases (e.g. init_hw) are all suffixed by that
phase. When reading the leaf functions, it should be clear at what stage
during the driver load it is called and therefore what operations are
legal at that point.
Also, since the functions start with intel_guc and intel_huc they take
appropiate structure.
v2: commit message update (Chris Wilson)
v3: change taken parameters to be more "semantic" (M. Wajdeczko)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Tue, 14 Mar 2017 11:50:19 +0000 (11:50 +0000)]
drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)
The rcu_barrier() takes the cpu_hotplug mutex which itself is not
reclaim-safe, and so rcu_barrier() is illegal from inside the shrinker.
[ 309.661373] =========================================================
[ 309.661376] [ INFO: possible irq lock inversion dependency detected ]
[ 309.661380] 4.11.0-rc1-CI-CI_DRM_2333+ #1 Tainted: G W
[ 309.661383] ---------------------------------------------------------
[ 309.661386] gem_exec_gttfil/6435 just changed the state of lock:
[ 309.661389] (rcu_preempt_state.barrier_mutex){+.+.-.}, at: [<ffffffff81100731>] _rcu_barrier+0x31/0x160
[ 309.661399] but this lock took another, RECLAIM_FS-unsafe lock in the past:
[ 309.661402] (cpu_hotplug.lock){+.+.+.}
[ 309.661404]
and interrupts could create inverse lock ordering between them.
[ 309.661410]
other info that might help us debug this:
[ 309.661414] Possible interrupt unsafe locking scenario:
drm/i915/glk: Improve rounding caused by pre-CSC gamma tables
The 33rd entry in the pre-CSC gamma table in Geminilake can represent a
value of 1.0 as 17 bits fixed point with one integer bit. However, the
table was generated such that the value of 1.0 would be 0.ffff with
all the intervals scaled accordingly. For instance, 0.5 mapped to
0.7fff instead of 0.8000.
For a reason that is not clear to the author, the rounding seems to be
different when a cursor plane is used, leading to some seemingly random
failures of the kms_cursor_crc igt tests. The differences weren't
perceptible at 8bpc with images captured by a Chamelium device, but did
cause CRC mismatches.
Daniel Vetter [Wed, 8 Mar 2017 14:12:45 +0000 (15:12 +0100)]
drm/i915: Merge pre/postclose hooks
There's really not a reason afaics that we can't just clean up
everything at the end, in the terminal postclose hook: Since this is
closing a file descriptor we know no one else can have a reference or
a thread doing something with that drm_file except the close code.
Ordering shouldn't matter, as long as we don't kfree before we clean
stuff up.
In the past this was more relevant when drivers still had to track and
clean up pending drm events, but that's all done by the core now.
Since commit c8ebfad7a063 ("drm/i915: Ignore OpRegion panel type except
on select machines") we ignore the OpRegion panel type except for
specific machines (handled via a DMI match), so having SKL explicitly
excluded from using the OpRegion panel type is redundant. So let's
remove the SKL check.
Daniel Vetter [Sun, 12 Mar 2017 20:53:40 +0000 (21:53 +0100)]
drm/i915: annote drop_caches debugfs interface with lockdep
The trouble we have is that we can't really test all the shrinker
recursion stuff exhaustively in BAT because any kind of thrashing
stress test just takes too long.
But that leaves a really big gap open, since shrinker recursions are
one of the most annoying bugs. Now lockdep already has support for
checking allocation deadlocks:
- Direct reclaim paths are marked up with
lockdep_set_current_reclaim_state() and
lockdep_clear_current_reclaim_state().
- Any allocation paths are marked with lockdep_trace_alloc().
If we simply mark up our debugfs with the reclaim annotations, any
code and locks taken in there will automatically complete the picture
with any allocation paths we already have, as long as we have a simple
testcase in BAT which throws out a few objects using this interface.
Not stress test or thrashing needed at all.
v2: Need to EXPORT_SYMBOL_GPL to make it compile as a module.
v3: Fixup rebase fail (spotted by Chris).
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-kernel@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170312205340.16202-1-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Jani Nikula [Fri, 10 Mar 2017 13:27:58 +0000 (15:27 +0200)]
drm/i915/vbt: split out defaults that are set when there is no VBT
The main thing are the DDI ports. If there's a VBT that says there are
no outputs, we should trust that, and not have semi-random
defaults. Unfortunately, the defaults have resulted in some Chromebooks
without VBT to rely on this behaviour, so we split out the defaults for
the missing VBT case.
Ville Syrjälä [Thu, 9 Mar 2017 15:44:34 +0000 (17:44 +0200)]
drm/i915: Optimize VLV/CHV display FIFO updates
Use I915_{READ,WRITE}_FW() for updating the DSPARB registers on
VLV/CHV. This is less expesive as we can grab the uncore.lock across
the entire sequence of reads and writes instead of each register
access grabbing it.
This also allows us to eliminate the dsparb lock entirely as the
uncore.lock now effectively protects the contents of the DSPARB
registers.
v2: Add a note that interrupts are already disabled (Chris)
Ville Syrjälä [Thu, 9 Mar 2017 15:44:33 +0000 (17:44 +0200)]
drm/i915: Use I915_READ_FW for plane updates
Optimize the plane register accesses a little bit by grabbing
the uncore lock manually across the entire pile of accesses and
using I915_READ_FW().
This helps keep the pipe update vblank evade critical section
below our 100 usec deadline, particularly with lockdep enabled.
And in general we want to keep that critical section as short
as possible as it's executed with interrupts disabled.
Not all plane updates currently happen from within the vblank evade
critical section, so we must use the irqsave/irqrestore variants
of the spinlock functions in the plane hooks.
Ville Syrjälä [Thu, 9 Mar 2017 15:44:32 +0000 (17:44 +0200)]
drm/i915: Organize plane register writes into tighter bunches
Pull all the plane register writes closer together to avoid having
a lot of unrelated stuff in between them. This will make things more
clear once we'll grab the uncore lock around the entire bunch. Also
in the future we might even consider moving more of the register
value computation out from the plane update hooks. This should make
that easier to do.
Ville Syrjälä [Thu, 9 Mar 2017 15:44:31 +0000 (17:44 +0200)]
drm/i915: s/__raw_i915_read32/I915_READ_FW/ in the SKL+ scanline read w/a
Replace __raw_i915_read32() with I915_READ_FW() in the workaround for
the SKL+ scanline counter hardware fail. The two are the same thing
but everyone else uses I915_READ_FW() so let's follow suit.
Ville Syrjälä [Mon, 13 Feb 2017 17:58:18 +0000 (19:58 +0200)]
drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support
Check that the sink really declared 12bpc support before we enable it.
This should not actually never happen since it's mandatory for HDMI
sinks to support 12bpc if they support any deep color modes. But
reality disagrees with the theory and there are actually sinks in
the wild that violate the spec.
v2: Fix the output_types check
Update commit message to state that these things are in fact real
Chris Wilson [Mon, 13 Mar 2017 09:56:17 +0000 (09:56 +0000)]
drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info
i915_drpc_info missed covering a few register read with the runtime pm
wakelock. Be simple and cover the entire function with a single wakelock
so that new additions are not similarly missed in future.
Chris Wilson [Mon, 13 Mar 2017 10:07:50 +0000 (10:07 +0000)]
drm/i915/selftests: Fix error path for ggtt walk_hole()
The patch 6e32ab3d4777: "drm/i915: Fill different pages of the GTT"
from Feb 13, 2017, leads to the following static checker warning:
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:583 walk_hole()
error: 'vma' dereferencing possible ERR_PTR()
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 6e32ab3d4777 ("drm/i915: Fill different pages of the GTT" Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170313100750.2685-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Chris Wilson [Fri, 10 Mar 2017 00:09:42 +0000 (00:09 +0000)]
drm/i915: Move whole object to CPU domain for coherent shmem access
If the object is coherent, we can simply update the cache domain on the
whole object rather than calculate the before/after clflushes. The
advantage is that we then get correct tracking of ellided flushes when
changing coherency later.
Chris Wilson [Sun, 12 Mar 2017 13:27:45 +0000 (13:27 +0000)]
drm/i915: Rename REDIRECT_TO_GUC bit
The REDIRECT_TO_GUC bit is a strange beast as it is a disable bit -
setting the bit in the pm interrupt generation stops the interrupt going
to the guc (not sending it to the guc as the name implies). To help the
reader rename it to DISABLE_REDIRECT_TO_GUC so that we keep the bspec
greppable name without it being as confusing!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170312132745.9618-1-chris@chris-wilson.co.uk Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Jani Nikula [Fri, 10 Mar 2017 13:27:57 +0000 (15:27 +0200)]
drm/i915/vbt: don't propagate errors from intel_bios_init()
We don't use the error return for anything other than reporting and
logging that there is no VBT. We can pull the logging in the function,
and remove the error status return. Moreover, if we needed the
information for something later on, we'd probably be better off storing
the bit in dev_priv, and using it where it's needed, instead of using
the error return.
drm/i915/guc: Update rps.pm_intrmsk_mbz in guc_interrupts_capture/release
Different state is to be maintained for rps.pm_intrmsk_mbz for GuC and
Execlists. Updating it inside guc_interrupts_* routines as in those
routines GuC load/submission params are sanitized and it should not be set
based on HAS_GUC_SCHED during intel_irq_init.
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489199821-6707-3-git-send-email-sagar.a.kamble@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Thu, 9 Mar 2017 21:12:32 +0000 (21:12 +0000)]
drm/i915: Defer unmasking RPS interrupts until after making adjustments
To make our adjustments to RPS requires taking a mutex and potentially
sleeping for an unknown duration - until we have completed our
adjustments further RPS interrupts are immaterial (they are based on
stale thresholds) and we can safely ignore them.
Chris Wilson [Thu, 9 Mar 2017 21:12:31 +0000 (21:12 +0000)]
drm/i915: Use max(render, media) for Baytrail busyness calculation
Currently, we sum the render and media cycles (on different engines) to
compute a percentage - but we fail to factor in the duplication into the
threshold calculations. This makes us very eager to upclock!
If we just consider the maximum busy cycles of either counter, we should
have an accurate reflection on whether there are cycles to spare to
handle the workload at this frequency.
Chris Wilson [Thu, 9 Mar 2017 21:12:30 +0000 (21:12 +0000)]
drm/i915: Stop using RP_DOWN_EI on Baytrail
On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
compute everything from the UP_EI which does seem to correspond to the
desired interval.
v2: Fixup gen6_rps_pm_mask() as well
v3: Inline vlv_c0_above() to combine the now identical elapsed
calculation for up/down and simplify the threshold testing
Chris Wilson [Wed, 8 Mar 2017 14:46:22 +0000 (14:46 +0000)]
drm/i915: Extend debugfs/i915_drop_caches to call i915_gem_shrink_all()
Sometimes we want to explicitly page out all available objects from igt,
i.e. call i915_gem_shrink_all() and check that subsequent operations
succeed. This adds DROP_SHRINK_ALL [0x8] to the set of flags for
debugfs/i915_drop_caches for that purpose.
Chris Wilson [Fri, 10 Mar 2017 11:55:18 +0000 (11:55 +0000)]
drm/i915/cmdparser: Limit clflush to active cachelines
We only need to clflush those cachelines that we have validated to be
read by the GPU. Userspace typically fills the batch length in
correctly, the exceptions tend to be explicit tests within igt.
v2: Use ptr_mask_bits() to make Mika happy
v3: cmd is not advanced on MI_BBE, so make sure to include an extra
dword in the clflush.
Tvrtko Ursulin [Fri, 10 Mar 2017 09:32:49 +0000 (09:32 +0000)]
drm/i915: Fix forcewake active domain tracking
In commit 003342a50021 ("drm/i915: Keep track of active
forcewake domains in a bitmask") I forgot to adjust the
newly introduce fw_domains_active state across reset.
This caused the assert_forcewakes_inactive to trigger
during suspend and resume if there were user held
forcewakes.
v2: Bitmask checks are required since vfuncs are not
always present.
v3: Move bitmask tracking to get/put vfunc for simplicity.
(Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 003342a50021 ("drm/i915: Keep track of active forcewake domains in a bitmask")
Testcase: igt/drv_suspend/forcewake Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: "Paneri, Praveen" <praveen.paneri@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: v4.10+ <stable@vger.kernel.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170310093249.4484-1-tvrtko.ursulin@linux.intel.com
Shashank Sharma [Thu, 9 Mar 2017 13:43:41 +0000 (19:13 +0530)]
drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c
In I915 driver, there are many places where variable name for
intel_encoder object is given as 'intel_encoder' whereas it would
make more sense to call it just 'encoder' when possible.
This patch does this cleanup in file intel_ddi.c.
PS: There are few functions where both drm_encoder and intel_encoder
are present. For such functions, this patch does nothing.
Suggested-by: Ander Conselvan De Oliveira <conselvan2@gmail.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ander Conselvan De Oliveira <conselvan2@gmail.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489067021-4709-1-git-send-email-shashank.sharma@intel.com
Andrew Morton [Thu, 9 Mar 2017 23:47:37 +0000 (15:47 -0800)]
drivers/gpu/drm/i915/selftests/i915_selftest.c: fix build with gcc-4.4.4
gcc-4.4.4 has issues with anonymous union initializers.
In file included from drivers/gpu/drm/i915/selftests/i915_selftest.c:68:
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: error: unknown field 'mock' specified in initializer
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: warning: missing braces around initializer
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: warning: (near initialization for 'mock_selftests[0].<anonymous>')
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:12: error: unknown field 'mock' specified in initializer
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:13: error: unknown field 'm
...
Work around this.
Fixes: 953c7f82eb89 ("drm/i915: Provide a hook for selftests") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170310090314.3142-1-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tvrtko Ursulin [Thu, 9 Mar 2017 13:20:04 +0000 (13:20 +0000)]
drm/i915/guc: Fix request re-submission after reset
In order to ensure no missed interrupts we must first re-direct
the interrupts to GuC, and only then re-submit the requests to
be replayed after a GPU reset. Otherwise context switch can fire
before GuC has been set up to receive it triggering more hangs.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170309132005.1317-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Thu, 9 Mar 2017 14:20:49 +0000 (14:20 +0000)]
drm/i915: Ignore skl+ for debugfs/i915_sr_status
There is no easily digestible single self-refresh status bit, so don't
report one for debugfs/i915_sr_status on gen9+. For the moment this
avoids a read of the non-existent WM1_LP_ILK register.
drm/i915: Initialize pm_intr_keep during intel_irq_init for GuC
Driver needs to ensure that it doesn't mask the PM interrupts, which are
unmasked/needed by GuC firmware. For that, Driver maintains a bitmask of
interrupts to be kept unmasked, pm_intr_keep.
pm_intr_keep was determined across GuC load. GuC gets loaded in different
scenarios and it is not going to change the pm_intr_keep so this patch
moves its setup to intel_irq_init.
This patch fixes incorrect RPS masking leading to UP interrupts triggered
even when at cur_freq=max and inversly for Down interrupts.
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488862355-9768-1-git-send-email-sagar.a.kamble@intel.com
drm/i915: Nuke skl_update_plane debug message from the pipe update critical section
printks are slow so we should not be doing them from the vblank evade
critical section. These could explain why we sometimes seem to
blow past our 100 usec deadline.
The problem has been there ever since commit c331879ce8ea ("drm/i915:
skylake sprite plane scaling using shared scalers.") but it may not have
been readily visible until commit e1edbd44e23b ("drm/i915: Complain
if we take too long under vblank evasion.") increased our chances
of noticing it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1488974407-25175-1-git-send-email-maarten.lankhorst@linux.intel.com Fixes: c331879ce8ea ("drm/i915: skylake sprite plane scaling using shared scalers") Cc: <stable@vger.kernel.org> # v4.2+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[mlankhorst: Add missing tags, point to the correct offending commit]
projects / karo-tx-linux.git / log