Chen Zhou
0d961c4610
drm/i915/gt: fix spelling mistake "undeflow" -> "underflow"
...
There is a spelling mistake in comment, fix it.
Signed-off-by: Chen Zhou <chenzhou10@huawei.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/20200401022506.52965-1-chenzhou10@huawei.com
2020-04-01 14:38:18 +01:00
Chris Wilson
a5572d1f0d
drm/i915/gt: Align engine dump active/pending
...
Insert a space so that the same fields between active/pending execlists
state are aligned.
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/20200401111554.6279-1-chris@chris-wilson.co.uk
2020-04-01 14:30:36 +01:00
Chris Wilson
4d6c185908
drm/i915/gt: Fill all the unused space in the GGTT
...
When we allocate space in the GGTT we may have to allocate a larger
region than will be populated by the object to accommodate fencing. Make
sure that this space beyond the end of the buffer points safely into
scratch space, in case the HW tries to access it anyway (e.g. fenced
access to the last tile row).
v2: Preemptively / conservatively guard gen6 ggtt as well.
Reported-by: Imre Deak <imre.deak@intel.com >
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1554
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Matthew Auld <matthew.auld@intel.com >
Cc: Imre Deak <imre.deak@intel.com >
Cc: stable@vger.kernel.org
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Reviewed-by: Imre Deak <imre.deak@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200331152348.26946-1-chris@chris-wilson.co.uk
2020-03-31 21:51:08 +01:00
Mika Kuoppala
708c82d59b
drm/i915: Report all failed registers for ctx isolation
...
For CI it is enough to point out a single failure
in isolation. However it is beneficial to gather
info in logs for transients further down
the line.
Do not stop into first comparison failure but
continue probing forward.
v2: for all engines and poisons (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20200331135403.16906-1-mika.kuoppala@linux.intel.com
2020-03-31 21:42:12 +01:00
Chris Wilson
606727842d
drm/i915/gt: Include the execlists CCID of each port in the engine dump
...
Since we print out EXECLISTS_STATUS in the dump, also print out the CCID
of each context so we can cross check between the two.
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/20200331094239.23145-1-chris@chris-wilson.co.uk
2020-03-31 21:42:12 +01:00
Chris Wilson
9171555572
drm/i915/execlists: Pause CS flow before reset
...
Since we may be attempting to reset an active engine, we try to freeze
it in place before resetting -- to be on the safe side. We can go one
step further if we are using the CS flow semaphore to prevent the
context switching into the next.
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/20200331091459.29179-2-chris@chris-wilson.co.uk
2020-03-31 21:42:12 +01:00
Chris Wilson
71a6688e81
drm/i915/selftests: Tidy up an error message for live_error_interrupt
...
Since we don't wait for the error interrupt to reset, restart and then
complete the guilty request, clean up the error messages.
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/20200331091459.29179-1-chris@chris-wilson.co.uk
2020-03-31 21:42:12 +01:00
Chris Wilson
f53ae29c0e
drm/i915/gt: Include a few tracek for timeslicing
...
Add a few telltales to see when timeslicing is being enabled.
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/20200331120502.14713-1-chris@chris-wilson.co.uk
2020-03-31 21:42:12 +01:00
Chris Wilson
e2ccf0d009
drm/i915/execlists: Double check breadcrumb before crying foul
...
process_csb: 0000:00:02.0 bcs0: cs-irq head=4, tail=5
process_csb: 0000:00:02.0 bcs0: csb[5]: status=0x00008002:0x60000020
trace_ports: 0000:00:02.0 bcs0: preempted { ff84:45154! prio 2 }
trace_ports: 0000:00:02.0 bcs0: promote { ff84:45155* prio 2 }
trace_ports: 0000:00:02.0 bcs0: submit { ff84:45156 prio 2 }
process_csb: 0000:00:02.0 bcs0: cs-irq head=5, tail=6
process_csb: 0000:00:02.0 bcs0: csb[6]: status=0x00000018:0x60000020
trace_ports: 0000:00:02.0 bcs0: completed { ff84:45155* prio 2 }
process_csb: 0000:00:02.0 bcs0: ring:{start:0x00178000, head:0928, tail:0928, ctl:00000000, mode:00000200}
process_csb: 0000:00:02.0 bcs0: rq:{start:00178000, head:08b0, tail:08f0, seqno:ff84:45155, hwsp:45156},
process_csb: 0000:00:02.0 bcs0: ctx:{start:00178000, head:e000928, tail:0928},
process_csb: GEM_BUG_ON("context completed before request")
In this sequence, we can see that although we have submitted the next
request [ff84:45156] to HW (via ELSP[]) it has not yet reported the
lite-restore. Instead, we see the completion event of the currently
active request [ff84:45155] but at the time of processing that event,
the breadcrumb has not yet been written. Though by the time we do print
out the debug info, the seqno write of ff84:45156 has landed!
Therefore there is a serialisation problem between the seqno writes and
CS events, not just between the CS buffer and its head/tail pointers as
previously observed on Icelake.
This is not a huge problem, as we don't strictly rely on the breadcrumb
to determine HW activity, but it may indicate that interrupt delivery is
before the seqno write, aka bringing back the plague of missed
interrupts from yesteryear. However, there is no indication of this
wider problem, so let's just flush the seqno read before reporting an
error. If it persists after the fresh read we can worry again.
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/20200330234318.30638-1-chris@chris-wilson.co.uk
2020-03-31 10:02:04 +01:00
Chris Wilson
b28b34ac85
drm/i915/execlists: Explicitly reset both reg and context runtime
...
Upon a GPU reset, we copy the default context image over top of the
guilty image. This will rollback the CTX_TIMESTAMP register to before
our value of ce->runtime.last. Reset both back to 0 so that we do not
encounter an underflow on the next schedule out after resume.
This should not be a huge issue in practice, as hangs should be rare in
correct code.
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/20200330125827.5804-1-chris@chris-wilson.co.uk
2020-03-30 21:13:50 +01:00
Chris Wilson
4b379a48de
drm/i915/selftests: Check timeout before flush and cond checks
...
Allow a bit of leniency for the CPU scheduler to be distracted while we
flush the tasklet and so ensure that we always check the status of the
request once more before timing out.
v2: Wait until the HW acked the submit, and we do any secondary actions
for the submit (e.g. timeslices)
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/20200330121644.25277-1-chris@chris-wilson.co.uk
2020-03-30 17:56:00 +01:00
Chris Wilson
8b6d457f95
drm/i915/execlists: Include priority info in trace_ports
...
Add some extra information into trace_ports to help with reviewing
correctness.
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: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200330113137.24425-1-chris@chris-wilson.co.uk
2020-03-30 17:56:00 +01:00
Michal Wajdeczko
d472634ef9
drm/i915/huc: Fix HuC register used in debugfs
...
We report HuC status in debugfs using register read, but
we missed that on Gen11+ HuC uses different register.
Use correct one.
While here, correct placement of the colon.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@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 >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20200330113338.1713-1-michal.wajdeczko@intel.com
2020-03-30 17:56:00 +01:00
Michal Wajdeczko
2da48b1f88
drm/i915/huc: Add more errors for I915_PARAM_HUC_STATUS
...
There might be many reasons why we failed to successfully
load and authenticate HuC firmware, but today we only use
single error in case of no HuC hardware. Add some more
error codes for most common cases (disabled, not installed,
corrupted or mismatched firmware).
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Tony Ye <tony.ye@intel.com >
Cc: Robert M. Fosha <robert.m.fosha@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/20200330113302.1670-1-michal.wajdeczko@intel.com
2020-03-30 15:21:33 +01:00
Chris Wilson
35f3fd8182
drm/i915/execlists: Workaround switching back to a completed context
...
In what seems remarkably similar to the w/a required to not reload an
idle context with HEAD==TAIL, it appears we must prevent the HW from
switching to an idle context in ELSP[1], while simultaneously trying to
preempt the HW to run another context and a continuation of the idle
context (which is no longer idle).
We can achieve this by preventing the context from completing while we
reload a new ELSP (by applying ring_set_paused(1) across the whole of
dequeue), except this eventually fails due to a lite-restore into a
waiting semaphore does not generate an ACK. Instead, we try to avoid
making the GPU do anything too challenging and not submit a new ELSP
while the interrupts + CSB events appear to have fallen behind the
completed contexts. We expect it to catch up shortly so we queue another
tasklet execution and hope for the best.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1501
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: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200327201433.21864-1-chris@chris-wilson.co.uk
2020-03-27 20:53:26 +00:00
Daniele Ceraolo Spurio
a9410a6250
drm/i915/uc: do not free err log on uc_fini
...
We need to keep the GuC error logs around to debug the load failure,
so we can't clean them in the error unwind, which includes uc_fini().
Moving the cleanup to driver remove ensures that the logs stick around
long enough for us to dump them.
v2: reword commit msg (John)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@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/20200326181121.16869-7-daniele.ceraolospurio@intel.com
2020-03-26 21:23:22 +00:00
Daniele Ceraolo Spurio
293a554801
drm/i915/uc: Move uC debugfs to its own folder under GT
...
uC is a component of the GT, so it makes sense for the uC debugfs files
to be in the GT folder. A subfolder has been used to keep the same
structure we have for the code.
v2: use intel_* prefix (Jani), rebase on new gt_debugfs_register_files,
fix permissions for writable debugfs files.
v3: Rename files (Michal), remove blank line (Jani), fix sparse warns.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Andi Shyti <andi.shyti@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: John Harrison <John.C.Harrison@Intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Cc: Tony Ye <tony.ye@intel.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com > #v2
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20200326181121.16869-6-daniele.ceraolospurio@intel.com
2020-03-26 21:23:03 +00:00
Daniele Ceraolo Spurio
34904bd64a
drm/i915/debugfs: move uC printers and update debugfs file names
...
Move the printers to the respective files for clarity. The
guc_load_status debugfs has been squashed in the guc_info one, has
having separate ones wasn't very useful. The HuC debugfs has been
renamed huc_info to match.
v2: keep printing HUC_STATUS2 (Tony), avoid const->non-const
container_of (Jani)
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: John Harrison <John.C.Harrison@Intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Cc: Tony Ye <tony.ye@intel.com >
Cc: Jani Nikula <jani.nikula@linux.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/20200326181121.16869-5-daniele.ceraolospurio@intel.com
2020-03-26 21:22:43 +00:00
Daniele Ceraolo Spurio
801a0caa62
drm/i915/huc: make "support huc" reflect HW capabilities
...
We currently initialize HuC support based on GuC being enabled in
modparam; this means that huc_is_supported() can return false on HW that
does have a HuC when enable_guc=0. The rationale for this behavior is
that HuC requires GuC for authentication and therefore is not supported
by itself. However, we do not allow defining HuC fw wthout GuC fw and
selecting HuC in modparam implicitly selects GuC as well, so we can't
actually hit a scenario where HuC is selected alone. Therefore, we can
flip the support check to reflect the HW capabilities and fw
availability, which is more intuitive and will make it cleaner to log
HuC the difference between not supported in HW and not selected.
Removing the difference between GuC and HuC also allows us to simplify
the init_early, since we don't need to differentiate the support based
on the type of uC.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: John Harrison <John.C.Harrison@Intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Andi Shyti <andi.shyti@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/20200326181121.16869-4-daniele.ceraolospurio@intel.com
2020-03-26 21:22:01 +00:00
Andi Shyti
12df6c59b6
drm/i915/gt: allow setting generic data pointer
...
When registering debugfs files the intel gt debugfs library
forces a 'struct *gt' private data on the caller.
To be open to different usages make the new
"intel_gt_debugfs_register_files()"[*] function more generic by
converting the 'struct *gt' pointer to a 'void *' type.
I take the chance to rename the functions by using "intel_gt_" as
prefix instead of "debugfs_", so that "debugfs_gt_register_files()"
becomes "intel_gt_debugfs_register_files()".
Signed-off-by: Andi Shyti <andi.shyti@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20200326181121.16869-2-daniele.ceraolospurio@intel.com
2020-03-26 21:20:51 +00:00
Chris Wilson
a97b786bfa
drm/i915/gt: Stage the transfer of the virtual breadcrumb
...
We move the virtual breadcrumb from one physical engine to the next, if
the next virtual request is scheduled on a new physical engine. Since
the virtual context can only be in one signal queue, we need it to track
the current physical engine for the new breadcrumbs. However, to move
the list we need both breadcrumb locks -- and since we cannot take both
at the same time (unless we are careful and always ensure consistent
ordering) stage the movement of the signaler via the current virtual
request.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1510
Fixes: 6d06779e86chris@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/20200325130059.30600-1-chris@chris-wilson.co.uk
(cherry picked from commit 6c81e21a47rodrigo.vivi@intel.com >
2020-03-26 10:21:30 -07:00
Chris Wilson
c1ed2fb9d9
drm/i915/gt: Select the deepest available parking mode for rc6
...
On Ivybridge, we can go lower than rc6 to rc6p. And this is required for
Ivybridge to hit the same minimum power consumption as rc6 on other
platforms, so make it so.
v2: Update selftest to include all rc6 residency counters
Note that Andi did mention that we should be converting the magic
numbers into opaque magic macros, so if they ever get reused (unlikely
given only Ivybridge used the extra modes) we'll need to pay back the
technical debt.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1518
Fixes: 730eaeb524chris@chris-wilson.co.uk >
Cc: Andi Shyti <andi.shyti@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Imre Deak <imre.deak@intel.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200324134232.8773-1-chris@chris-wilson.co.uk
(cherry picked from commit 13c5a577b3rodrigo.vivi@intel.com >
2020-03-26 10:21:30 -07:00
Chris Wilson
98479ada42
drm/i915/gt: Treat idling as a RPS downclock event
...
If we park/unpark faster than we can respond to RPS events, we never
will process a downclock event after expiring a waitboost, and thus we
will forever restart the GPU at max clocks even if the workload switches
and doesn't justify full power.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500
Fixes: 3e7abf8141chris@chris-wilson.co.uk >
Cc: Andi Shyti <andi.shyti@intel.com >
Cc: Lyude Paul <lyude@redhat.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200322163225.28791-1-chris@chris-wilson.co.uk
Cc: <stable@vger.kernel.org > # v5.5+
(cherry picked from commit 21abf0bf16rodrigo.vivi@intel.com >
2020-03-26 10:21:30 -07:00
Chris Wilson
a24c57d0b3
drm/i915/gt: Cancel a hung context if already closed
...
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e34483chris@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/20200319170707.8262-2-chris@chris-wilson.co.uk
(cherry picked from commit 8e37d69913rodrigo.vivi@intel.com >
2020-03-26 10:21:30 -07:00
Chris Wilson
2e46a2a0b0
drm/i915: Use explicit flag to mark unreachable intel_context
...
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
v2:
* Use already available context flags. (Chris)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20200319170707.8262-1-chris@chris-wilson.co.uk
(cherry picked from commit 207e4a71fbrodrigo.vivi@intel.com >
2020-03-26 10:21:04 -07:00
Chris Wilson
73c8bfb7fe
drm/i915: Drop final few uses of drm_i915_private.engine
...
We've migrated all the heavy users over to the intel_gt, and can finally
drop the last few users and with that the mirror in dev_priv->engine[].
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Andi Shyti <andi.shyti@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200325234803.6175-1-chris@chris-wilson.co.uk
2020-03-26 10:50:17 +00:00
Chris Wilson
6c81e21a47
drm/i915/gt: Stage the transfer of the virtual breadcrumb
...
We move the virtual breadcrumb from one physical engine to the next, if
the next virtual request is scheduled on a new physical engine. Since
the virtual context can only be in one signal queue, we need it to track
the current physical engine for the new breadcrumbs. However, to move
the list we need both breadcrumb locks -- and since we cannot take both
at the same time (unless we are careful and always ensure consistent
ordering) stage the movement of the signaler via the current virtual
request.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1510
Fixes: 6d06779e86chris@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/20200325130059.30600-1-chris@chris-wilson.co.uk
2020-03-25 13:59:41 +00:00
Chris Wilson
6670b413f8
drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
...
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct submission if we can acquire the tasklet's lock.
v2: Document the read of pending[0] from outside the tasklet with
READ_ONCE.
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/20200325120227.8044-1-chris@chris-wilson.co.uk
2020-03-25 13:05:04 +00:00
Chris Wilson
032d992dcb
drm/i915/selftests: Measure the energy consumed while in RC6
...
Measure and compare the energy consumed, as reported by the rapl MSR,
by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
at least halve the energy consumption of RC0, as this more than likely
means we failed to enter RC0 correctly.
If we can't measure the energy draw with the MSR, then it will report 0
for both measurements. Since the measurement works on all gen6+, this seems
worth flagging as an error.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Andi Shyti <andi.shyti@intel.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200325101502.12591-1-chris@chris-wilson.co.uk
2020-03-25 11:33:05 +00:00
Chris Wilson
9bf7c31386
drm/i915/execlists: Drop setting sibling priority hint on virtual engines
...
We set the priority hint on execlists to avoid executing the tasklet for
when we know that there will be no change in execution order. However,
as we set it from the virtual engine for all siblings, but only one
physical engine may respond, we leave the hint set on the others
stopping direct submission that could take place.
If we do not set the hint, we may attempt direct submission even if we
don't expect to submit. If we set the hint, we may not do any submission
until the tasklet is run (and sometimes we may park the engine before
that has had a chance). Ergo there's only a minor ill-effect on mixed
virtual/physical engine workloads where we may try and fail to do direct
submission more often than required. (Pure virtual / engine workloads
will have redundant tasklet execution suppressed as normal.)
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1522
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/20200325101358.12231-1-chris@chris-wilson.co.uk
2020-03-25 10:53:46 +00:00
Chris Wilson
13c5a577b3
drm/i915/gt: Select the deepest available parking mode for rc6
...
On Ivybridge, we can go lower than rc6 to rc6p. And this is required for
Ivybridge to hit the same minimum power consumption as rc6 on other
platforms, so make it so.
v2: Update selftest to include all rc6 residency counters
Note that Andi did mention that we should be converting the magic
numbers into opaque magic macros, so if they ever get reused (unlikely
given only Ivybridge used the extra modes) we'll need to pay back the
technical debt.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1518
Fixes: 730eaeb524chris@chris-wilson.co.uk >
Cc: Andi Shyti <andi.shyti@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Imre Deak <imre.deak@intel.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200324134232.8773-1-chris@chris-wilson.co.uk
2020-03-24 15:53:51 +00:00
Chris Wilson
af7a272ef6
drm/i915/gt: Only delay the context barrier pm
...
It is strictly sufficient to only delay the intel_engine_pm_put from the
context barrier (and not from the context exit) in order to prevent the
gem_exec_nop contention. Adding the delay to the context exit incurs
noticably extra penalty for soft-rc6.
Fixes: edee52c927chris@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/20200323192029.20723-1-chris@chris-wilson.co.uk
2020-03-23 20:38:56 +00:00
Chris Wilson
edee52c927
drm/i915/gt: Delay release of engine-pm after last retirement
...
Keep the engine-pm awake until the next jiffie, to avoid immediate
ping-pong under moderate load. (Forcing the idle barrier excerbates the
moderate load, dramatically increasing the driver overhead.) On the
other hand, delaying the idle-barrier slightly incurs longer rc6-off
and so more power consumption.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/848
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/20200323092841.22240-4-chris@chris-wilson.co.uk
2020-03-23 12:51:19 +00:00
Chris Wilson
e9037e7f9a
drm/i915: Extend intel_wakeref to support delayed puts
...
In some cases we want to hold onto the wakeref for a little after the
last user so that we can avoid having to drop and then immediately
reacquire it. Allow the last user to specify if they would like to keep
the wakeref alive for a short hysteresis.
v2: Embrace bitfield.h for adjustable flags.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200323103221.14444-1-chris@chris-wilson.co.uk
2020-03-23 12:51:05 +00:00
Chris Wilson
41e4065a6b
drm/i915: Rely on direct submission to the queue
...
Drop the pretense of kicking the tasklet (used only for the defunct guc
submission backend, it should just take ownership of the submit!) and so
remove the bh-kicking from around submission.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200323092841.22240-5-chris@chris-wilson.co.uk
2020-03-23 11:51:39 +00:00
Chris Wilson
8e87e0139a
drm/i915/gt: Mark timeline->cacheline as destroyed after rcu grace period
...
Since we take advantage of RCU for some i915_active objects, like the
intel_timeline_cacheline, we need to delay the i915_active_fini until
after the RCU grace period and we perform the kfree -- that is until
after all RCU protected readers.
<3> [108.204873] ODEBUG: assert_init not available (active state 0) object type: i915_active hint: __cacheline_active+0x0/0x80 [i915]
<4> [108.207377] WARNING: CPU: 3 PID: 2342 at lib/debugobjects.c:488 debug_print_object+0x67/0x90
<4> [108.207400] Modules linked in: vgem snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec ax88179_178a snd_hwdep usbnet btusb snd_hda_core btrtl mii btbcm btintel snd_pcm bluetooth ecdh_generic ecc i915 i2c_hid pinctrl_sunrisepoint pinctrl_intel intel_lpss_pci prime_numbers
<4> [108.207587] CPU: 3 PID: 2342 Comm: gem_exec_parall Tainted: G U 5.6.0-rc6-CI-Patchwork_17047+ #1
<4> [108.207609] Hardware name: Google Soraka/Soraka, BIOS MrChromebox-4.10 08/25/2019
<4> [108.207639] RIP: 0010:debug_print_object+0x67/0x90
<4> [108.207668] Code: 83 c2 01 8b 4b 14 4c 8b 45 00 89 15 87 d2 8a 02 8b 53 10 4c 89 e6 48 c7 c7 38 2b 32 82 48 8b 14 d5 80 2f 07 82 e8 49 d5 b7 ff <0f> 0b 5b 83 05 c3 f6 22 01 01 5d 41 5c c3 83 05 b8 f6 22 01 01 c3
<4> [108.207692] RSP: 0018:ffffc90000e7f890 EFLAGS: 00010282
<4> [108.207723] RAX: 0000000000000000 RBX: ffffc90000e7f8b0 RCX: 0000000000000001
<4> [108.207747] RDX: 0000000080000001 RSI: ffff88817ada8cb8 RDI: 00000000ffffffff
<4> [108.207770] RBP: ffffffffa0341cc0 R08: ffff88816b5a8948 R09: 0000000000000000
<4> [108.207792] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82322d54
<4> [108.207814] R13: ffffffffa0341cc0 R14: ffffffff83df9568 R15: ffff88816064f400
<4> [108.207839] FS: 00007f437d753700(0000) GS:ffff88817ad80000(0000) knlGS:0000000000000000
<4> [108.207863] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [108.207887] CR2: 00007f2ad1fb5000 CR3: 00000001725d8004 CR4: 00000000003606e0
<4> [108.207907] Call Trace:
<4> [108.207959] debug_object_assert_init+0x15c/0x180
<4> [108.208475] ? i915_active_acquire_if_busy+0x10/0x50 [i915]
<4> [108.208513] ? rcu_read_lock_held+0x4d/0x60
<4> [108.208970] i915_active_acquire_if_busy+0x10/0x50 [i915]
<4> [108.209380] intel_timeline_read_hwsp+0x81/0x540 [i915]
<4> [108.210262] __emit_semaphore_wait+0x45/0x1b0 [i915]
<4> [108.210726] ? i915_request_await_dma_fence+0x143/0x560 [i915]
<4> [108.211156] i915_request_await_dma_fence+0x28a/0x560 [i915]
<4> [108.211633] i915_request_await_object+0x24a/0x3f0 [i915]
<4> [108.212102] eb_submit.isra.47+0x58f/0x920 [i915]
<4> [108.212622] i915_gem_do_execbuffer+0x1706/0x2c70 [i915]
<4> [108.213071] ? i915_gem_execbuffer2_ioctl+0xc0/0x470 [i915]
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/20200323092841.22240-1-chris@chris-wilson.co.uk
2020-03-23 11:16:03 +00:00
Chris Wilson
043cd2d14e
drm/i915/gt: Leave rps->cur_freq on unpark
...
Don't override our previous frequency we used after parking, and avoid
continually spiking back to the efficient frequency for mostly idle
workloads. Trust our ability to autotune across a workload switch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Andi Shyti <andi.shyti@intel.com >
Cc: Lyude Paul <lyude@redhat.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200322163225.28791-2-chris@chris-wilson.co.uk
2020-03-22 23:03:08 +00:00
Chris Wilson
21abf0bf16
drm/i915/gt: Treat idling as a RPS downclock event
...
If we park/unpark faster than we can respond to RPS events, we never
will process a downclock event after expiring a waitboost, and thus we
will forever restart the GPU at max clocks even if the workload switches
and doesn't justify full power.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500
Fixes: 3e7abf8141chris@chris-wilson.co.uk >
Cc: Andi Shyti <andi.shyti@intel.com >
Cc: Lyude Paul <lyude@redhat.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200322163225.28791-1-chris@chris-wilson.co.uk
Cc: <stable@vger.kernel.org > # v5.5+
2020-03-22 23:03:00 +00:00
Chris Wilson
bb6892b7ce
drm/i915/gt: Use the correct err_unlock unwind path for a closed context
...
A silly cut'n'paste copied the unlocked error path and used it inside
the pin_mutex lock, we need to drop that lock before returning.
Fixes: b412c63f1cchris@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: https://patchwork.freedesktop.org/patch/msgid/20200322123241.17694-1-chris@chris-wilson.co.uk
2020-03-22 13:44:24 +00:00
Chris Wilson
e50c951ea6
drm/i915/gt: Restrict gen7 w/a batch to Haswell
...
The residual w/a batch is causing system instablity on Ivybridge and
Baytrail under some workloads, so disable until resolved.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1405
Fixes: 47f8253d2bchris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com >
Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200311103640.26572-1-chris@chris-wilson.co.uk
(cherry picked from commit a62774782brodrigo.vivi@intel.com >
2020-03-20 07:04:38 -07:00
Chris Wilson
b412c63f1c
drm/i915/gt: Report context-is-closed prior to pinning
...
Our assertion caught that we do try to pin a closed context if userspace
is viciously racing context-closure with execbuf, so make it fail
gracefully.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1492
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: https://patchwork.freedesktop.org/patch/msgid/20200320130159.3922-1-chris@chris-wilson.co.uk
2020-03-20 13:27:28 +00:00
Chris Wilson
8e37d69913
drm/i915/gt: Cancel a hung context if already closed
...
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e34483chris@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/20200319170707.8262-2-chris@chris-wilson.co.uk
2020-03-19 21:28:24 +00:00
Chris Wilson
207e4a71fb
drm/i915: Use explicit flag to mark unreachable intel_context
...
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
v2:
* Use already available context flags. (Chris)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20200319170707.8262-1-chris@chris-wilson.co.uk
2020-03-19 21:28:20 +00:00
Wambui Karuga
394ad36c51
drm/i915/workarounds: convert to drm_device based logging macros.
...
Replace the use of printk based drm logging macros with the struct
drm_device based logging macros.
Note that this converts DRM_DEBUG_DRIVER() to drm_dbg().
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-8-wambui.karugax@gmail.com
2020-03-19 11:34:36 +02:00
Wambui Karuga
a8fa7c079f
drm/i915/rps: use struct drm_device based logging macros.
...
Replace the use of the printk based drm logging macros with the struct
drm_device based logging macros in i915/gt/intel_rps.c. This also
involves extracting the drm_i915_private device pointer from various
intel types.
This converts the instances of DRM_DEBUG_DRIVER to drm_dbg() while not
converting DRM_DEBUG() instances due to the lack of an analogous
drm_device based macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-7-wambui.karugax@gmail.com
2020-03-19 11:34:32 +02:00
Wambui Karuga
606856f09e
drm/i915/ring_submission: use drm_device based logging macros.
...
Replace the use of printk based drm logging macros to the struct
drm_device based logging macros in i915/gt/intel_ring_submission.c.
This was done using the following semantic patch that transforms based
on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were fixed manually.
Note that this converts DRM_DEBUG_DRIVER to drm_dbg().
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-6-wambui.karugax@gmail.com
2020-03-19 11:34:28 +02:00
Wambui Karuga
edf040f4ee
drm/i915/renderstate: use struct drm_device based logging macros.
...
Replace the use of the printk based drm logging macros with the struct
drm_device based logging macros.
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-5-wambui.karugax@gmail.com
2020-03-19 11:34:22 +02:00
Wambui Karuga
1ca6ce9332
drm/i915/rc6: convert to struct drm_device based logging macros.
...
Converts various instances of the printk based drm logging macros to use
the struct drm_device logging macros. This also involves extracting the
drm_i915_private device from intel types in some cases.
Note that this converts DRM_DEBUG_DRIVER() to drm_dbg().
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-4-wambui.karugax@gmail.com
2020-03-19 11:34:16 +02:00
Wambui Karuga
91682e45ba
drm/i915/lrc: convert to struct drm_device based logging macros.
...
Convert various instances of the printk based drm logging macros to the
struct drm_device based logging macros.
Note that this converts DRM_DEBUG_DRIVER() to drm_dbg() but does not
convert DRM_DEBUG() due to the lack of an analogous drm_device based
macro.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-3-wambui.karugax@gmail.com
2020-03-19 11:34:11 +02:00
Wambui Karuga
36034c95d3
drm/i915/ggtt: convert to drm_device based logging macros.
...
Converts various instances of the printk based drm logging macros to use
the struct drm_device based logging macros in i915/gt/intel_ggtt.c.
This change was done using the following coccinelle script that matches
based on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were fixed manually.
Note that this converts DRM_DEBUG_DRIVER to drm_dbg()
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-2-wambui.karugax@gmail.com
2020-03-19 11:34:04 +02:00
