On Thu, Jan 31, 2019 at 1:01 PM Masahiro Yamada
wrote:
>
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way,
On 2/7/19 3:27 PM, Daniel Vetter wrote:
Hi Daniel,
I have a few possible changes for this documentation (see below).
> ---
> Documentation/driver-api/component.rst | 17
> Documentation/driver-api/device_link.rst | 3 +
> Documentation/driver-api/index.rst | 1 +
> drivers/bas
== Series Details ==
Series: drm/i915/selftests: Move local mock_ggtt allocations to the heap
URL : https://patchwork.freedesktop.org/series/56813/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5617_full -> Patchwork_12241_full
=
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
(rev2)
URL : https://patchwork.freedesktop.org/series/56809/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5617_full -> Patchwork_12240_full
==
== Series Details ==
Series: drm/i915/selftests: Move local mock_ggtt allocations to the heap
URL : https://patchwork.freedesktop.org/series/56813/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5617 -> Patchwork_12241
Summa
On Sun, 17 Feb 2019 at 20:27, Chris Wilson wrote:
>
> Quoting Matthew Auld (2019-02-17 18:35:05)
> > On Thu, 14 Feb 2019 at 18:32, Chris Wilson wrote:
> > >
> > > The kernel must not return stale information back to userspace when they
> > > create a new object. For that purpose, we always clear
Quoting Matthew Auld (2019-02-17 18:35:05)
> On Thu, 14 Feb 2019 at 18:32, Chris Wilson wrote:
> >
> > The kernel must not return stale information back to userspace when they
> > create a new object. For that purpose, we always clear objects on
> > creation, so verify that this is so.
> >
> > Sig
This struct appears quite large and pushes our stack frame over
1024 bytes -- too high for conservative setups. So move the mock_ggtt
struct to the heap.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 16 +++---
Quoting Matthew Auld (2019-02-17 18:40:05)
> On Sun, 17 Feb 2019 at 16:13, Chris Wilson wrote:
> >
> > This struct appears quite large and pushes our stack frame over
> > 1024 bytes -- too high for conservative setups. So move the mock_ggtt
> > struct to the heap.
> >
> > Signed-off-by: Chris Wils
On Sun, 17 Feb 2019 at 16:13, Chris Wilson wrote:
>
> This struct appears quite large and pushes our stack frame over
> 1024 bytes -- too high for conservative setups. So move the mock_ggtt
> struct to the heap.
>
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
Missing kfree() somewhere?
Revi
On Thu, 14 Feb 2019 at 18:32, Chris Wilson wrote:
>
> The kernel must not return stale information back to userspace when they
> create a new object. For that purpose, we always clear objects on
> creation, so verify that this is so.
>
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> ---
> te
The write hazard lies extend also to the cache-dirty tracking; as we
purposefully do not tell the kernel we are writing to the bo, it fails
to note the CPU cache as dirty and so the gem_read() may not
sufficiently flush the caches prior to reading back from the GPU.
Signed-off-by: Chris Wilson
Cc
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
(rev2)
URL : https://patchwork.freedesktop.org/series/56809/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5617 -> Patchwork_12240
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
(rev2)
URL : https://patchwork.freedesktop.org/series/56809/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make user contexts bannable agai
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
(rev2)
URL : https://patchwork.freedesktop.org/series/56809/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f1a2277064d5 drm/i915: Make user contexts bannable again!
801c337002f
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
URL : https://patchwork.freedesktop.org/series/56809/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5616 -> Patchwork_12239
Some clients, such as mesa, may only emit minimal incremental batches
that rely on the logical context state from previous batches. They know
that recovery is impossible after a hang as their required GPU state is
lost, and that each in flight and subsequent batch will hang (resetting
the context i
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
URL : https://patchwork.freedesktop.org/series/56809/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make user contexts bannable again!
Okay!
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
URL : https://patchwork.freedesktop.org/series/56809/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b5b63e011d58 drm/i915: Make user contexts bannable again!
0bad7186178e drm/i9
Introduce a new ABI method for detecting a wedged driver by reporting
-EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
This struct appears quite large and pushes our stack frame over
1024 bytes -- too high for conservative setups. So move the mock_ggtt
struct to the heap.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++-
drivers/gpu/drm/i915/sel
The idea of taking the reset lock around writing the fence register was
to serialise the mmio write we also perform during the reset where those
registers get clobbered. However, the lock is overkill as write tearing
between reset and fence_update() is harmless; the final value of the
fence registe
CI still reports the occasional multi-second delay for resets, in
particular along the wedge+recovery paths. As the likely, and unbounded,
delay here is from sync_rcu, use the expedited variant instead.
Testcase: igt/gem_eio/unwedge-stress
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drive
Remove the "safety-factor" in our udelays for i915_do_reset(). If we are
told to hold the line high for 20us, do it only for 20us plus the tiny
bit of udelay latency.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
The stack usage exceeded 1024 bytes prompting warnings on conservative
setups, so move the temporary allocation for HW readback onto the heap.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 48 ++--
1 file changed, 31 insertions(
Annoyingly, struct_mutex was not entirely eliminated from the reset
pathway; for reasons of its own, intel_display_resumes() requires
struct_mutex to prepare the planes it already captured. To avoid the
immediate problem of a deadlock between the struct_mutex and the reset
srcu, we have to acquire
Some clients, such as mesa, may only emit minimal incremental batches
that rely on the logical context state from previous batches. They know
that recovery is impossible after a hang as their required GPU state is
lost, and that each in flight and subsequent batch will hang (resetting
the context i
Since moving the bannable boolean into the context flags, we lost the
default setting of contexts being bannable. Oops.
Sadly because we have multi-level banning scheme, our testcase for being
banned cannot distinguish between the expected ban on the context and
the applied banned via the fd.
Fix
We force a reset on test exit so that we can rapidly cleanup after a
naughty test, it is not unknown for us to leave a queue of hanging
batches around. However, if we have also fiddled with the i915.reset
parameter in the meantime, this can leave the kernel unable to fulfil
our request (and those n
Lock down the new uABI that DRM_IOCTL_I915_GEM_CONTEXT_CREATE returns
-EIO when wedged.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_eio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index ac85a2eff..3c54820
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_eio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index 3c54820c9..3a
kms_fence_pin_leak tests smooth sharp edges that are i915 specific (and
requires using GEM to do so). It doesn't belong in the general paddock
of all driver tests, so move it into the i915/ stable.
Signed-off-by: Chris Wilson
Cc: Arkadiusz Hiler
Cc: Petri Latvala
Acked-by: Petri Latvala
---
t
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson
---
tests/i915/
Check that the GPU even exists before submitting a batch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109589
Signed-off-by: Chris Wilson
---
tests/kms_fence_pin_leak.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/kms_fence_pin_leak.c b/tests/kms_fence_pin_leak.c
index 62c
basic-allocations was written to demonstrate a flaw in our continual
reallocation of cmdparser shadow bo, largely fixed by keeping a small
cache of bo of different lengths (to speed up the search for the correct
sized bo). We only care enough to exercise the slowdown by submitting
lots of execbufs,
The kernel must not return stale information back to userspace when they
create a new object. For that purpose, we always clear objects on
creation, so verify that this is so.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
tests/i915/gem_create.c | 71 +
36 matches
Mail list logo
