in
emit_stop_watchdog. (Chris)
Cc: Chris Wilson
Signed-off-by: Tomas Elf
Signed-off-by: Ian Lister
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_context.h | 4 ++
drivers/gpu/drm/i915/intel_lrc.c| 85 +++--
drivers/gpu/drm/i
Ursulin
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 4 ++--
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915
patch you could say,
Tested-by: Michel Thierry
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Lahtinen
Cc: Oscar Mateo
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index fb936bb5cb93..ec391ef981aa
915->ggtt.invalidate = gen6_ggtt_invalidate;
+ if (i915->ggtt.invalidate == guc_ggtt_invalidate)
+ i915->ggtt.invalidate = gen6_ggtt_invalidate;
}
void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv)
Reviewed-by: Michel Thierry
btw the bug can only happen in
On 6/2/2017 1:16 PM, Chris Wilson wrote:
Quoting Michel Thierry (2017-05-22 18:46:24)
+ /* try engine reset first, and continue if fails */
/* Please use sentences when convenient. It looks much neater that way. */
_less_ broken English:
/*
* Try engine reset when available. We
is Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_uc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 3524ff07a0f2..c5ef4fa2b404 100644
--- a/drivers
x27;t shoot the messenger (Chris)
Fixes: 3950bf3dbff10 ("drm/i915/guc: Add onion teardown to the GuC
setup")
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Joonas Lahtinen
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_uc.c | 7 +--
1
s for explict igt_allow_hang()
Signed-off-by: Chris Wilson
Cc: Michel Thierry
---
lib/igt_aux.c | 10
lib/igt_gt.c| 4
lib/igt_sysfs.c | 72 ++---
lib/igt_sysfs.h | 6 +
4 files changed, 74 insertions(+), 18 dele
On 6/5/2017 3:57 PM, Chris Wilson wrote:
Quoting Michel Thierry (2017-06-05 22:21:48)
On 6/5/2017 5:13 AM, Chris Wilson wrote:
The hang detector relies on a uevent for notification and aborting the
test. As proposed, fine-grained resets may not produce a global uevent
and so this hang
On 6/4/2017 5:06 AM, Chris Wilson wrote:
And whilst I'm here, we need to extend I915_PARAM_HAS_GPU_RESET to
indicate having per-engine resets for the complimentary set of igt.
-Chris
Something like this?
case I915_PARAM_HAS_GPU_RESET:
- value = i915.enable_hangcheck &&
ned-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.c | 13 +++
drivers/gpu/drm/i915/i915_drv.h | 10 +
drivers/gpu/drm/i915/i915_irq.c | 45 +
drivers/gpu/drm/i915/i915_pci.c |
On 6/6/2017 3:16 AM, Chris Wilson wrote:
I didn't think it was sensible to advertise reset-engine support without
global reset (or the hangcheck to detect the error), and for the time
being we can keep thinking of this as an integer rather than a set of
flags.
So I was just thinking of
value =
On 6/5/2017 10:32 AM, Patchwork wrote:
== Series Details ==
Series: drm/i915/guc: Clear enable_guc_loading in case of init failure (rev2)
URL : https://patchwork.freedesktop.org/series/25228/
State : success
== Summary ==
Series 25228v2 drm/i915/guc: Clear enable_guc_loading in case of init
ot;), that is no longer the case.
Cc: Michel Thierry
Signed-off-by: Antonio Argenziano
If we want the test to pass, then it's ok. Someone else may say we need
further subtests.
On the basis this brings existing tests to the current expectation,
Reviewed-by: Michel Thierry
(with the
ge (Michel Thierry)
Cc: Michel Thierry
Signed-off-by: Antonio Argenziano
My rb[1] still stands. Thanks for resending this.
-Michel
[1]https://lists.freedesktop.org/archives/intel-gfx/2017-June/130239.html
___
Intel-gfx mailing list
Intel-gfx@lists.freed
On 13/06/17 01:27, Jani Nikula wrote:
On Mon, 15 May 2017, Jani Nikula wrote:
Continuing [1] for v4.12-rc1
The following commits have been marked as Cc: stable or fixing something
in v4.12-rc1 or earlier, but failed to cherry-pick to
drm-intel-fixes. Please see if they are worth backporting, a
Signed-off-by: Tomas Elf
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.c | 48 -
drivers/gpu/drm/i915/i915_drv.h | 5 +++
drivers/gpu/drm/i915/i915_gem.c | 96 +
3 files changed, 109
nowledge reset
_readiness_.
v9: Support parallel resets (in different engines). Return type of reset
available in get-param ioctl. Watchdog timeout won't capture the error state.
Daniele Ceraolo Spurio (1):
drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder
Michel Thierry (20):
regardless of submission mode. (Chris)
Signed-off-by: Arun Siluvery
Signed-off-by: Jeff McGee
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.c| 24 +++
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_guc_submission.c | 48
/reset_engine/ (Chris)
Define count as unsigned int (Tvrtko)
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 10 ++
drivers/gpu/drm/i915
ed-by: Chris Wilson
Reviewed-by: Chris Wilson (v5)
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 14 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gp
;t capture error state in case of watchdog timeout. The capture
process is time consuming and this will align to what happens when we
use GuC to handle the watchdog timeout. (Chris)
Signed-off-by: Tomas Elf
Signed-off-by: Ian Lister
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
In preparation for engine reset work update this parameter to handle more
than one type of reset. Default at the moment is still full gpu reset.
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_params.c | 6
_REG_WRITE/WA_REG_WR_GUC_RESTORE).
v5: Only ask guc to reapply workarounds in case of render reset (Daniele).
Cc: Daniele Ceraolo Spurio
Signed-off-by: Arun Siluvery
Signed-off-by: Jeff McGee
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h| 3 ++
drivers/gp
e for them (magic 8-ball predicts this will change
again later on, so future-proof it). (Daniele)
Cc: Daniele Ceraolo Spurio
Signed-off-by: Tomas Elf
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 56 +++
dri
empts to use pad as input (Antonio)
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Antonio Argenziano
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
include/uapi/drm/i915_drm.h | 6 +-
2 files changed, 15 insertions(+), 3 deletions(-)
i915_engine_info too (Chris).
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_debugfs.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915
et-engine flag locking better (Chris)
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Ian Lister
Signed-off-by: Tomas Elf
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.c | 13 +++
drivers/gpu/drm/i915/i915_drv.h | 10 +
driver
Winiarski (v2)
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_guc_submission.c | 11 +--
drivers/gpu/drm/i915/intel_guc_fwif.h | 1 -
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gp
/resume/reset (Daniele).
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_guc_submission.c | 21 ++---
drivers/gpu/drm/i915/intel_guc_fwif.h | 2 +-
drivers/gpu/drm/i915
has been
seen at least once in CI.
References: https://intel-gfx-ci.01.org/CI/Trybot_831/
Reported-by: Antonio Argenziano
Cc: Mika Kuoppala
Cc: Chris Wilson
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_uncore.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions
Save the watchdog threshold (in us) as part of the engine state.
v2: Only do it for gen8+ (and prevent a missing-case warn).
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 12
2 files changed, 9 insertions
So users (tests) can detect which type of reset (engine vs global) is
active.
Suggested-by: Chris Wilson
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
,
provide a simple debugfs entry to see the number of times media reset
has happened.
v2: Remove unnecessary struct_mutex, _get_dirty_page and kmap_atomic;
use READ_ONCE. (Chris)
Cc: Chris Wilson
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_debugfs.c | 22
Check that we can reset specific engines, also check the fallback to
full reset if something didn't work.
v2: rebase.
v3: use RESET_ENGINE_IN_PROGRESS flag.
v4: use I915_RESET_ENGINE flag.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c
Ursulin
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 4 ++--
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915
This feature is made available only from Gen8, for previous gen devices
driver uses legacy full gpu reset.
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Tomas Elf
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed
in
emit_stop_watchdog. (Chris)
Cc: Chris Wilson
Signed-off-by: Tomas Elf
Signed-off-by: Ian Lister
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_context.h | 4 ++
drivers/gpu/drm/i915/intel_lrc.c| 85 +++--
drivers/gpu/drm/i
On 15/06/17 14:14, Chris Wilson wrote:
Quoting Michel Thierry (2017-06-15 21:18:17)
Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
On 19/06/17 05:46, Chris Wilson wrote:
Quoting Michel Thierry (2017-06-15 21:18:12)
@@ -2992,10 +3014,8 @@ void i915_gem_reset_finish(struct drm_i915_private
*dev_priv)
lockdep_assert_held(&dev_priv->drm.struct_mutex);
- for_each_engine(engine, dev_p
the existing reset_queue, and remember that kselftests is
playing games with I915_RESET_BACKOFF to prevent hangcheck from screwing
up.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_irq.c | 23 +++
drivers/gpu
On 20/06/17 04:03, Tvrtko Ursulin wrote:
On 20/06/2017 10:57, Chris Wilson wrote:
Next chunk from Michel finally reviewed, after a little hiatus as the
series uncovered a deadlock with concurrent resets.
Will apply if no objections, and move on to the guc enabling patches.
Go for it! :)
A
Soon we will have tests that are only for platforms with reset-engine
(GEN8+), so add a helper to query the has_gpu_reset via the getparam ioctl.
Signed-off-by: Michel Thierry
---
lib/ioctl_wrappers.c | 22 ++
lib/ioctl_wrappers.h | 1 +
2 files changed, 23 insertions
the number
of per-engine resets and use reset_count + reset_engine_count when
checking for the updated reset count.
Signed-off-by: Michel Thierry
---
tests/gem_reset_stats.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
_hang()
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Link:
http://patchwork.freedesktop.org/patch/msgid/20170605121314.21135-1-ch...@chris-wilson.co.uk
Reviewed-by: Michel Thierry
Signed-off-by: Michel Thierry
---
lib/igt_aux.c | 10
lib/igt_gt.c| 4
lib/igt_sysfs.c
On 23/06/17 06:19, Chris Wilson wrote:
Smatch spots:
drivers/gpu/drm/i915/selftests/intel_hangcheck.c:669
igt_render_engine_reset_fallback() error: double unlock
'mutex:&i915->drm.struct_mutex'
Signed-off-by: Chris Wilson
Reviewed-by: Michel Thierry
---
drivers/gpu/d
register addresses haven't been reused, but we
should not been reading (and writing to) registers that do not exist.
References: IHD-OS-BDW-Vol 2c-11.15, page 75.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 29 -
drivers/gpu/drm
On 23/06/17 16:35, Chris Wilson wrote:
Quoting Michel Thierry (2017-06-24 00:17:29)
Until Haswell/Baytrail, the hardware used to have a per engine fault
register (e.g. 0x4094 - render fault register, 0x4194 - media fault
register, etc). But since Broadwell, all these registers were combined
register addresses haven't been reused, but we
should not been reading (and writing to) registers that do not exist.
v2: Rename fault variable, use INTEL_GEN (Chris).
References: IHD-OS-BDW-Vol 2c-11.15, page 75.
Cc: Chris Wilson
Signed-off-by: Michel Thierry
---
drivers/gpu/drm
On 6/28/2017 7:10 AM, Arkadiusz Hiler wrote:
On Tue, Jun 20, 2017 at 11:25:01AM -0700, Michel Thierry wrote:
Soon we will have tests that are only for platforms with reset-engine
(GEN8+), so add a helper to query the has_gpu_reset via the getparam ioctl.
Signed-off-by: Michel Thierry
Soon we will have tests that are only for platforms with reset-engine
(GEN8+), so add a helper to query the has_gpu_reset via the getparam ioctl.
v2: Add more helper functions to avoid using magic numbers in tests (Arek).
Cc: Arkadiusz Hiler
Signed-off-by: Michel Thierry
---
lib
the number
of per-engine resets and use reset_count + reset_engine_count when
checking for the updated reset count.
v2: Rebase, don't use gem_gpu_reset_type directly, since we now have
additional helpers.
Cc: Arkadiusz Hiler
Signed-off-by: Michel Thierry
---
tests/gem_reset_stats.c
Let the memory controller do all the swizzling").
Cc: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 87e13131f6ea.
On 6/29/2017 6:07 AM, Chris Wilson wrote:
Quoting Ville Syrjälä (2017-06-29 14:05:25)
On Wed, Jun 28, 2017 at 04:24:27PM -0700, Michel Thierry wrote:
There's no need to keep reading random registers in i915_swizzle_info if
the platform is not doing GPU side swizzling.
After HSW, swizzli
, we will still need to keep this for the
full gpu reset case.
Cc: Chris Wilson
Cc: Michal Winiarski
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_uc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff
oxton,
Broxton is just the first machine on which I have confirmed this bug.
Fixes: 142bc7d99bcf ("drm/i915: Modify error handler for per engine hang
recovery")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 f
On Thu, Jul 6, 2017 at 12:11 AM, Chris Wilson
wrote:
Quoting Michel Thierry (2017-07-06 02:24:26)
On 04/07/17 09:09, Chris Wilson wrote:
> Triggering a GPU reset for one engine affects another, notably
> corrupting the context status buffer (CSB) effectively losing
track of
>
-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 165 +++
drivers/gpu/drm/i915/selftests/mock_context.c| 8 ++
drivers/gpu/drm/i915/selftests/mock_context.h| 3 +
3 fil
On 06/07/17 04:12, Arkadiusz Hiler wrote:
On Tue, Jun 20, 2017 at 11:25:02AM -0700, Michel Thierry wrote:
Platforms with per-engine reset enabled (i915.reset=2) are unlikely to
perform a full chip reset, keeping the reset_count unmodified. In order
to keep the expectations of this test, enforce
ate page for the HWSP like what happens for
pre-execlists platform.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michel Thierry > ---
drivers/gpu/drm/i915/intel_engine_cs.c | 123 +++
drivers/gpu/drm/i915/intel_lrc.c| 42 +
On 06/07/17 15:50, Antonio Argenziano wrote:
+
+igt_fixture {
+int fd;
+
+fd = drm_open_driver(DRIVER_INTEL);
+igt_assert(igt_sysfs_set_parameter
+ (fd, "reset", "%d", INT_MAX /* any reset method */));
I would still suggest that we restore the reset val
On 07/07/17 14:15, Daniele Ceraolo Spurio wrote:
After a bit of investigation I've found that the issue is not actually
with the positioning of the HWSP but with the fact that we use
status_page.ggtt_offset to point to the lrca offset of the default
context in guc_ads_create instead of using
k
a bit of mystery as to why the context was banned,
and also reduces awareness overall of when a GPU (engine) reset occurs
with its possible side-effects.
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.c | 8 +---
1 file changed, 5
the GuC interaction, it was also
noticed that the firmware expects the size of only the engine context
(context minus the execlist part, i.e. don't include the first 80
dwords), so pass the right size.
Reported-by: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
Cc: Daniele Ceraolo S
On 7/11/2017 3:37 PM, Chris Wilson wrote:
Quoting Michel Thierry (2017-07-11 22:29:39)
Using the HWSP ggtt_offset to get the lrca offset is only correct if the
HWSP happens to be before it (when we reuse the PPHWSP of the kernel
context as the engine HWSP). Instead of making this assumption
On 7/11/2017 5:07 PM, Chris Wilson wrote:
Quoting Chris Wilson (2017-07-12 01:00:02)
Also feel free to try and fixup the other confusion in intel_lrc.c.
Perhaps something like:
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b0738d2..f498aa6 100644
--- a/d
On 7/11/2017 5:54 PM, Chris Wilson wrote:
Quoting Michel Thierry (2017-07-12 01:14:46)
On 7/11/2017 5:07 PM, Chris Wilson wrote:
Quoting Chris Wilson (2017-07-12 01:00:02)
Also feel free to try and fixup the other confusion in intel_lrc.c.
Perhaps something like:
diff --git a/drivers/gpu/drm
niele Ceraolo Spurio
Signed-off-by: Michel Thierry
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Oscar Mateo
---
drivers/gpu/drm/i915/i915_guc_submission.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm
adds defines for the GuC shared page, the PPHWSP page and the
start of the logical state. It also updated the places where the old
define was being used. Since we are not changing the size (or format) of
the context, there are no functional changes.
Suggested-by: Chris Wilson
Signed-off-by: Michel
On 7/12/2017 12:45 PM, Chris Wilson wrote:
Quoting Michel Thierry (2017-07-12 20:30:31)
Not only the context image consist of two parts (the PPHWSP, and the
logical context state), but we also allocate a header at the start of
for sharing data with GuC. Thus every lrc looks like this
... the only small changes
I noticed were in intel_engine_init_common and logical_ring_init).
Apart from those 2 things, it looks good to me.
Reviewed-by: Michel Thierry
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michel Thierry
Link:
http://patchwork.freedesktop.org/patch/msgid/1499357440-34688-1-git-send-ema
tself. Still a step in the right direction towards
reducing our resubmit latency, although it appears lost in the noise!
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c| 20 +++-
drivers/gpu/drm
any latency, but a small
reduction in overall cpu usage.
Much appreciation for Ben dropping the bombshell that the CSB was in the
HWSP and for Michel in digging out the details.
Suggested-by: Ben Widawsky
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
of re-using the PPHWSP of the kernel
ctx we can allocate a separate page for the HWSP like what happens for
pre-execlists platform.
v2: Add a use-case for the register arena of the HWSP.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michel Thierry
Link:
http://patchwork.freedesktop.org/patch/msgid/1
GVT-g, it currently depends on intercepting CSB mmio
Suggested-by: Ben Widawsky
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
Cc: Zhenyu Wang
Cc: Zhi Wang
Acked-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_debugfs.c
g our resubmit latency, although it appears lost in the noise!
v2: Cannonlake moved the CSB write index
v3: Include the sw/hwsp state in debugfs/i915_engine_info
v4: Also revert to using CSB mmio for GVT-g
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Da
915_reset_engine(struct intel_engine_cs *engine)
error->reset_engine_count[engine->id]++;
out:
+ i915_gem_reset_finish_engine(engine);
return ret;
}
Reviewed-by: Michel Thierry
___
Intel-gfx maili
ed = 0;
+
if (request && i915_gem_reset_request(request)) {
DRM_DEBUG_DRIVER("resetting %s to restart from tail of request
0x%x\n",
engine->name, request->global_seqno);
Reviewed-by: Michel Thierry
___
return ENGINE_ACTIVE_SEQNO;
- if (i915_seqno_passed(hc->seqno, intel_engine_last_submit(engine)))
+ if (intel_engine_is_idle(engine))
return ENGINE_IDLE;
return engine_stuck(engine, hc->acthd);
Reviewed-by: Michel Thierry
_
CSB (0 head=1, tail=2), ctx=0, rq=3
Note that this bug may be affect all machines and not just Broxton,
Broxton is just the first machine on which I have confirmed this bug.
Hopefully this is just broxton being broxton... I think I already sent
this, but anyway...
Acked-by: Michel Thierry
On 17/07/17 02:11, Chris Wilson wrote:
We should only ever do nop_submit_request when the machine is wedged, so
assert it is so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/d
the context was banned,
and also reduces awareness overall of when a GPU (engine) reset occurs
with its possible side-effects.
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions
On 7/20/2017 5:51 AM, Chris Wilson wrote:
Quoting Michel Thierry (2017-07-18 01:15:00)
On 17/07/17 02:11, Chris Wilson wrote:
We should only ever do nop_submit_request when the machine is wedged, so
assert it is so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 1
On 7/21/2017 5:32 AM, Chris Wilson wrote:
Extract the common barrier against rogue hangchecks from disrupting our
direct testing of resets, and in the process expand the lock to include
the per-engine reset shortcuts.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
I don&#
be the active request at the time of the reset.
Reported-by: Daniel Vetter
Fixes: c64992e035d7 ("drm/i915: Look for active requests earlier in the reset
path")
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
Cc: Daniel Vetter
Reviewed-by: Joonas Lahtinen #v1
-Chri
5_reset(dev_priv, 0);
I guess adding a wrapper to make flags=0 the default it's an overkill,
plus I see the benefit of not flooding dmesg.
Reviewed-by: Michel Thierry
mutex_unlock(&dev_priv->drm.struct_mutex);
}
On 7/21/2017 5:32 AM, Chris Wilson wrote:
The purpose of the test was to check per-engine resets would fallback to
the global reset when required, but first we actually need a test for a
basic i915_handle_error()!
Cc: Mika Kuoppala
Cc: Michel Thierry
Signed-off-by: Chris Wilson
---
drivers
On 6/30/2017 10:41 AM, Michel Thierry wrote:
The driver reloads the GuC firmware after full gpu reset or
suspend/resume, but it never disables the GuC beforehand.
This leads us to hit the assert inside i915_ggtt_enable_guc added
by commit 04f7b24eccdf ("drm/i915/guc: Assert that we s
telist_count[engine->id]++;
return 0;
--
1.9.1
I see RCS_FORCE_TO_NONPRIV in "Render Engine *Power* Context" and not in
the "Register State Context", so
Acked-by: Michel Thierry
___
Intel-gfx mailing list
In
On 9/29/2017 3:25 AM, Joonas Lahtinen wrote:
On Thu, 2017-09-28 at 16:47 -0700, Michel Thierry wrote:
On 28/09/17 15:40, Oscar Mateo wrote:
RING_FORCE_TO_NONPRIV registers do not live in the logical context. They are
simply
global privileged MMIO registers that happen to be powercontext saved
WaDisableCtxRestoreArbitration was only applied for bdw and chv, but
this changed after the code got moved to gen8_emit_bb_start (and, at
least in my tree, there is no gen9_emit_bb_start).
Fixes: 3ad7b52d962e ("drm/i915/execlists: Move bdw GPGPU w/a to emit_bb")
Signed-off-by: Michel T
On 10/5/2017 11:28 AM, Chris Wilson wrote:
Quoting Michel Thierry (2017-10-05 19:19:27)
WaDisableCtxRestoreArbitration was only applied for bdw and chv, but
this changed after the code got moved to gen8_emit_bb_start (and, at
least in my tree, there is no gen9_emit_bb_start).
But I need to
On 10/31/2017 3:20 AM, Chris Wilson wrote:
Quoting Patchwork (2017-10-30 23:20:13)
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6267/shards.html
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6267/shard-kbl1/igt@prime_b...@wait-hang-render.html
is suspicious.
-
Signed-off-by: Michel Thierry
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 15 +--
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_guc.c | 24
drivers/gpu/drm/i915/intel_guc_fwif.h | 1 +
drivers/gpu/d
data[2] = INTEL_GUC_PREEMPT_OPTION_DROP_WORK_Q |
--
2.14.2
Since Michał is not around,
Reviewed-by: Michel Thierry
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 38 ++-
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
3 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b
mber of clients; check for client allocation failure when
number of doorbells is exceeded; validate client properties; reuse
guc_init_doorbell_hw (Chris).
v3: guc_init_doorbell_hw test added per Chris suggestion.
Signed-off-by: Michel Thierry
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spu
On 11/10/2017 12:51 PM, Chris Wilson wrote:
Quoting Michel Thierry (2017-11-10 19:01:16)
Until Haswell/Baytrail, the hardware used to have a per engine fault
register (e.g. 0x4094 - render fault register, 0x4194 - media fault
register and so on). But since Broadwell, all these registers were
On 11/10/2017 3:50 PM, Chris Wilson wrote:
Quoting Michel Thierry (2017-11-10 23:42:31)
On 11/10/2017 12:51 PM, Chris Wilson wrote:
Quoting Michel Thierry (2017-11-10 19:01:16)
Until Haswell/Baytrail, the hardware used to have a per engine fault
register (e.g. 0x4094 - render fault register
301 - 400 of 1163 matches
Mail list logo
