From: Emil Velikov
This static inline function doesn't modify any state.
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Emil Velikov
Reviewed-by: Daniel Vetter
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/include/drm
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did
Each individual pass is as effective at spotting an error using the
Chinese whisper as any other, so the effectiveness of adding more passes
rapidly diminishes. To keep the tests bounded within time, limit a
subtest to a mere 150s!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108592
Sign
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
r
On 14/01/2019 09:16, Chris Wilson wrote:
Each individual pass is as effective at spotting an error using the
Chinese whisper as any other, so the effectiveness of adding more passes
rapidly diminishes. To keep the tests bounded within time, limit a
subtest to a mere 150s!
Bugzilla: https://bugs
Quoting Tvrtko Ursulin (2019-01-14 09:42:55)
>
> On 14/01/2019 09:16, Chris Wilson wrote:
> > +
> > + if (++pass == 1024)
> > + break;
> > }
> > }
> > igt_info("Number of migrations fo
On 11/01/2019 19:46, Ville Syrjala wrote:
From: Ville Syrjälä
To overcome display engine stride limits we'll want to remap the
pages in the GTT. To that end we need a new gtt_view type which
is just like the "rotated" type except not rotated.
I think I asked this before, so sorry if you also
On Mon, Jan 14, 2019 at 08:54:08AM +, Emil Velikov wrote:
> From: Emil Velikov
>
> There are cases (in mesa and applications) where one would open the
> primary node without properly authenticating the client.
>
> Sometimes we don't check if the authentication succeeds, but there's
> also ca
From: Tony Ye
On Icelake we need to turn off subslices not containing the VME block or
the VME kernel will hang.
v2: (Tvrtko Ursulin)
* Remove libdrm usage for setting context param.
* Cleanup bitmask operation.
* Only apply the workaround for ICL.
v3: (Tvrtko Ursulin)
* Added hang detector
From: Tony Ye
Simple test which exercises the VME fixed function block.
v2: (Tvrtko Ursulin)
* Small cleanups like copyright date, tabs, remove unused bits.
v3: (Tony Ye)
* Added curbe data entry for dst surface.
* Read the dst surface after the VME kernel being executed.
v4: (Tony Ye)
* A
From: Lionel Landwerlin
Verify that the per-context dynamic SSEU uAPI works as expected.
v2: Add subslice tests (Lionel)
Use MI_SET_PREDICATE for further verification when available (Lionel)
v3: Rename to gem_ctx_rpcs (Lionel)
v4: Update kernel API (Lionel)
Add 0 value test (Lionel)
From: Tvrtko Ursulin
New in this version:
* Updated for engine_class/engine_instance uAPI rename.
Lionel Landwerlin (1):
tests/gem_ctx_sseu: Dynamic (sub)slice programming tests
Tony Ye (2):
tests/gem_media_vme: Simple test to exercise the VME block
tests/gem_media_vme: Shut down half of
From: Tvrtko Ursulin
Sync with latest drm headers from drm-tip.
Acked-by: Chris Wilson
---
include/drm-uapi/drm_fourcc.h | 2 +-
include/drm-uapi/drm_mode.h | 19 +++
include/drm-uapi/i915_drm.h | 64 +++
include/drm-uapi/msm_drm.h| 25 +
On Fri, Jan 11, 2019 at 11:13:37AM -0200, Rodrigo Siqueira wrote:
> The force option allows users to specify which driver they want that IGT
> uses. Nonetheless, if the user has two or more loaded drivers in his
> system, the force option will not work as expected because IGT will take
> the first
== Series Details ==
Series: series starting with [v2,1/2] drm: annotate drm_core_check_feature()
dev arg. as const
URL : https://patchwork.freedesktop.org/series/55154/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
57a47732f5af drm: annotate drm_core_check_feature() dev arg.
On 01/14, Petri Latvala wrote:
> On Fri, Jan 11, 2019 at 11:13:37AM -0200, Rodrigo Siqueira wrote:
> > The force option allows users to specify which driver they want that IGT
> > uses. Nonetheless, if the user has two or more loaded drivers in his
> > system, the force option will not work as expe
== Series Details ==
Series: series starting with [v2,1/2] drm: annotate drm_core_check_feature()
dev arg. as const
URL : https://patchwork.freedesktop.org/series/55154/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5414 -> Patchwork_11287
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev13)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
Applying: drm/i915/execlists: Move RPCS setup to context pin
Applying: drm/i915: Record the sseu configuration per-context & engi
From: Lionel Landwerlin
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configurati
From: Tvrtko Ursulin
Configuring RPCS in context image just before pin is sufficient and will
come extra handy in one of the following patches.
v2:
* Split image setup a bit differently. (Chris Wilson)
v3:
* Update context image after reset as well - otherwise the application
of pinned def
From: Tvrtko Ursulin
Changes since last version:
* Rebase for drm-tip changes.
Test-with: 20190114102955.10721-1-tvrtko.ursu...@linux.intel.com
Lionel Landwerlin (2):
drm/i915: Record the sseu configuration per-context & engine
drm/i915/perf: lock powergating configuration to default when
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context.
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
r
From: Tvrtko Ursulin
Exercise the context image reconfiguration logic for idle and busy
contexts, with the resets thrown into the mix as well.
Free from the uAPI restrictions this test runs on all Gen9+ platforms
with slice power gating.
v2:
* Rename some helpers for clarity.
* Include subtes
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev14)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bef4bdb66bef drm/i915/execlists: Move RPCS setup to context pin
495ee6ca200b drm/i915: Record the
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev14)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Move RPCS setup to context pin
Okay!
Commit: drm/
Everytime we take a wakeref, record the stack trace of where it was
taken; clearing the set if we ever drop back to no owners. For debugging
a rpm leak, we can look at all the current wakerefs and check if they
have a matching rpm_put.
v2: Use skip=0 for unwinding the stack as it appears our noinl
Keep track of our wakeref used to keep the device awake so we can catch
any leak.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_perf.c | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
d
As the GT_IRQ power domain implies a wakeref, we can use it inplace of
our existing redundant rpm grab.
v2: Drop papering over forgetting to take the runtime wakeref in
selftests
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_
Keep track of the temporary rpm wakeref used for panel backlight access,
so that we can cancel it immediately upon release and so more clearly
identify leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_panel.c | 5 +++--
1 file changed
Keep track of the temporary rpm wakeref inside hotplug detection, so
that we can cancel it immediately upon release and so clearly identify
leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_hotplug.c | 5 +++--
1 file changed, 3 insert
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Revi
Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/intel_dp.c | 231 +---
As we only release each power well once, we assume that each transcoder
maps to a different domain. Complain if this is not so.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --gi
As sysfs has a simple pattern of taking a rpm wakeref around the user
access, we can track the local reference and drop it as soon as
possible.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_sysfs.c | 24 ++--
1 file cha
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
Keep track of our acquired wakeref for interacting with the guc, so that
we can cancel it upon release and so clearly identify leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_guc_log.c | 15 +--
drivers/gpu/drm/i915/intel
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping
As debugfs has a simple pattern of taking a rpm wakeref around the user
access, we can track the local reference and drop it as soon as
possible.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 135 +---
1
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
Keep track of the temporary rpm wakerefs used for user access to the
device, so that we can cancel them upon release and clearly identify any
leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c| 47 +-
Keep track of the rpm wakeref used for framebuffer access so that we can
cancel upon release and so more clearly identify leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_display.c | 5 +++--
drivers/gpu/drm/i915/intel_fbdev.c | 9 +
Track the temporary wakerefs used within the selftests so that leaks are
clear.
v2: Add a couple of coarse annotations for mock selftests as we now
loudly warn about the errors.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/huge_page
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Revi
Record the wakeref used for keeping the device awake as the GPU is
executing requests and be sure to cancel the tracking upon parking.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 11 ++
Track the wakeref used for temporary access to the device, and discard
it upon release so that leaks can be identified.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_pmu.c | 26 +-
1 file changed, 17 insertions(+),
Chris Wilson writes:
> As the GT_IRQ power domain implies a wakeref, we can use it inplace of
> our existing redundant rpm grab.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/i915_gem.c
Keep hold of the local wakeref used in error handling, to cancel
the tracking upon release so that leaks can be identified.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
dif
== Series Details ==
Series: series starting with [CI,01/21] drm/i915: Track all held rpm wakerefs
URL : https://patchwork.freedesktop.org/series/55181/
State : failure
== Summary ==
Applying: drm/i915: Markup paired operations on wakerefs
Using index info to reconstruct a base tree...
M
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev14)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5415 -> Patchwork_11289
Summary
---
Quoting Patchwork (2019-01-14 14:29:32)
> == Series Details ==
>
> Series: series starting with [CI,01/21] drm/i915: Track all held rpm wakerefs
> URL : https://patchwork.freedesktop.org/series/55181/
> State : failure
>
> == Summary ==
>
> Applying: drm/i915: Markup paired operations on waker
Use another sensitive CPU reloc to emit a chained batch from inside the
updated buffer to reduce the workload on slow machines to fit within the
CI timeout.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108248
Signed-off-by: Chris Wilson
---
tests/i915/gem_cpu_reloc.c | 347 ++
Chris Wilson writes:
> Currently Ironlake operates under the assumption that rpm awake (and its
> error checking is disabled). As such, we have missed a few places where we
> access registers without taking the rpm wakeref and thus trigger
> warnings. intel_ips being one culprit.
>
> As this invo
Chris Wilson writes:
> As the GT_IRQ power domain implies a wakeref, we can use it inplace of
> our existing redundant rpm grab.
>
> v2: Drop papering over forgetting to take the runtime wakeref in
> selftests
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
If we break out of the test loop early, we may not have filled all
dwords, so be careful to only check as far as we completed.
Fixes: d9cd03c887a5 ("i915/gem_exec_whisper: Limit to a maximum of 150s")
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 12 ++--
1 file changed
Quoting Mika Kuoppala (2019-01-14 15:01:59)
> Chris Wilson writes:
> > unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
> > {
> > - unsigned long val;
> > + intel_wakeref_t wakeref;
> > + unsigned long val = 0;
> >
> > if (!IS_GEN(dev_priv, 5))
> >
On Fri, Jan 11, 2019 at 04:41:37PM -0800, Matt Roper wrote:
> On Fri, Jan 11, 2019 at 07:08:12PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On g4x+ the pipe gamma enable bit for the primary plane affects
> > the pipe bottom color as well. The same for the pipe csc enable
> > bit
Quoting Chris Wilson (2019-01-14 14:32:35)
> Quoting Patchwork (2019-01-14 14:29:32)
> > == Series Details ==
> >
> > Series: series starting with [CI,01/21] drm/i915: Track all held rpm
> > wakerefs
> > URL : https://patchwork.freedesktop.org/series/55181/
> > State : failure
> >
> > == Summa
drm/i915 is tracking all wakeref owners with a cookie in order to
identify leaks. To that end, each rpm acquisition ops->get_power is
assigned a cookie which should be passed to ops->put_power to signify
its release (and removal from the list of wakeref owners). As snd/hda is
already using a bool t
Track the temporary rpm wakerefs used within audio so that they may be
marked as complete and the tracking cancelled upon release.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_audio.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i91
Just in case the audio linkage is swapped between components during the
runtime pm sequence, we need to protect the rpm tracking with a mutex.
Signed-off-by: Chris Wilson
Cc: Takashi Iwai
Cc: Jani Nikula
---
include/sound/hdaudio.h| 1 +
sound/hda/hdac_component.c | 7 +++
2 files chan
On 14/01/2019 16:34, Chris Wilson wrote:
If we break out of the test loop early, we may not have filled all
dwords, so be careful to only check as far as we completed.
Fixes: d9cd03c887a5 ("i915/gem_exec_whisper: Limit to a maximum of 150s")
Signed-off-by: Chris Wilson
---
tests/i915/gem_exe
Quoting Tvrtko Ursulin (2019-01-14 17:43:17)
>
> On 14/01/2019 16:34, Chris Wilson wrote:
> > If we break out of the test loop early, we may not have filled all
> > dwords, so be careful to only check as far as we completed.
> >
> > Fixes: d9cd03c887a5 ("i915/gem_exec_whisper: Limit to a maximum
On Mon, 14 Jan 2019 18:37:53 +0100,
Chris Wilson wrote:
>
> Just in case the audio linkage is swapped between components during the
> runtime pm sequence, we need to protect the rpm tracking with a mutex.
It's not clear to me how does this happens.
Could you elaborate a bit more the scenario?
t
== Series Details ==
Series: series starting with [v2,1/2] drm: annotate drm_core_check_feature()
dev arg. as const
URL : https://patchwork.freedesktop.org/series/55154/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5414_full -> Patchwork_11287_full
==
Quoting Takashi Iwai (2019-01-14 17:46:57)
> On Mon, 14 Jan 2019 18:37:53 +0100,
> Chris Wilson wrote:
> >
> > Just in case the audio linkage is swapped between components during the
> > runtime pm sequence, we need to protect the rpm tracking with a mutex.
>
> It's not clear to me how does this
On Mon, 14 Jan 2019 18:37:52 +0100,
Chris Wilson wrote:
>
> drm/i915 is tracking all wakeref owners with a cookie in order to
> identify leaks. To that end, each rpm acquisition ops->get_power is
> assigned a cookie which should be passed to ops->put_power to signify
> its release (and removal fro
On Mon, 14 Jan 2019 18:51:31 +0100,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-01-14 17:46:57)
> > On Mon, 14 Jan 2019 18:37:53 +0100,
> > Chris Wilson wrote:
> > >
> > > Just in case the audio linkage is swapped between components during the
> > > runtime pm sequence, we need to protect
On 1/14/2019 09:37, Chris Wilson wrote:
Track the temporary rpm wakerefs used within audio so that they may be
marked as complete and the tracking cancelled upon release.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_audio.c | 10 ++
1 file changed, 6 insertions(+), 4 d
== Series Details ==
Series: series starting with [1/3] drm/i915/audio: Track temporary rpm wakerefs
URL : https://patchwork.freedesktop.org/series/55194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b531f8b4dca8 drm/i915/audio: Track temporary rpm wakerefs
c78a3bd63af7 snd/hd
Hi Dave and Daniel,
Here goes first pull request targeting 5.1
made out of 2 tags:
drm-intel-next-2019-01-10:
- Unwind failure on pinning the gen7 PPGTT (Chris)
- Fastset updates to make sure DRRS and PSR are properly enabled (Hans)
- Header include clean-up (Brajeswar, Jani)
- Improvements and
On Mon, Jan 14, 2019 at 07:11:10PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 11, 2019 at 04:41:37PM -0800, Matt Roper wrote:
> > On Fri, Jan 11, 2019 at 07:08:12PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > On g4x+ the pipe gamma enable bit for the primary plane affects
> >
== Series Details ==
Series: series starting with [1/3] drm/i915/audio: Track temporary rpm wakerefs
URL : https://patchwork.freedesktop.org/series/55194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5417 -> Patchwork_11291
On Wed, Jan 09, 2019 at 01:14:14PM -0800, Radhakrishna Sripada wrote:
> intel_dp->dsc_dpcd is defined as an array making the if check redundant.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Radhakrishna Sripada
This fixes a Clang warning I saw after the patch that added this hit
linux-next.
Reviewed-
On Thu, Dec 20, 2018 at 01:26:08PM +0200, Juha-Pekka Heikkila wrote:
> Primary and sprite plane enable on ILK-IVB may take two frames to complete
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103925
> Signed-off-by: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/i915/intel_display.c |
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev14)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5415_full -> Patchwork_11289_full
Summary
Quoting Takashi Iwai (2019-01-14 18:00:02)
> On Mon, 14 Jan 2019 18:51:31 +0100,
> Chris Wilson wrote:
> >
> > Quoting Takashi Iwai (2019-01-14 17:46:57)
> > > On Mon, 14 Jan 2019 18:37:53 +0100,
> > > Chris Wilson wrote:
> > > >
> > > > Just in case the audio linkage is swapped between component
Always perform the requested reset, even if we believe the engine is
idle. Presumably there was a reason the caller wanted the reset, and in
the near future we lose the easy tracking for whether the engine is
idle.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c |
Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more
consistently if called concurrently.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 32 ++-
drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++-
.../gpu/dr
Currently the code to reset the GPU and our state is spread widely
across a few files. Pull the logic together into a common file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile |3 +-
drivers/gpu/drm/i915/i915_debugfs.c |2 +
drivers/gpu/drm/i915
Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged()
as a reminder that it must be callable without struct_mutex held.
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 6 +++---
1 file changed, 3 inser
In preparation for relaxing the conditions under which we wait to allow
waiting on the GPU from any context (e.g. holding nearly any other
mutex) is to remove taking struct_mutex from inside GPU reset. The issue
being that any mutex required for GPU reset is required to avoid
indefinite waits while
In preparation for the next few commits, make resetting the GPU atomic.
Currently, we have prepared gen6+ for atomic resetting of individual
engines, but now there is a requirement to perform the whole device
level reset (just the register poking) from inside an atomic context.
Signed-off-by: Chri
Now that the submission backends are controlled via their own spinlocks,
with a wave of a magic wand we can lift the struct_mutex requirement
around GPU reset. That is we allow the submission frontend (userspace)
to keep on submitting while we process the GPU reset as we can suspend
the backend ind
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving c
We have two classes of VM, global GTT and per-process GTT. In order to
allow ourselves the freedom to mix both along call chains, distinguish
the two classes with regards to their mutex and lockdep maps.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_g
Quoting Takashi Iwai (2019-01-14 17:54:08)
> On Mon, 14 Jan 2019 18:37:52 +0100,
> Chris Wilson wrote:
> > diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h
> > index b4fa1c775251..39761120ee76 100644
> > --- a/include/sound/hdaudio.h
> > +++ b/include/sound/hdaudio.h
> > @@ -366,8 +36
We want to exclude any GGTT objects from being present on our internal
lists to avoid the deadlock we may run into with our requirement for
struct_mutex during invalidate. However, if the gup_fast fails, we put
the userptr onto the workqueue and mark it as active, so that we
remember to serialise t
On Braswell, under heavy stress, if we update the GGTT while
simultaneously accessing another region inside the GTT, we are returned
the wrong values. To prevent this we stop the machine to update the GGTT
entries so that no memory traffic can occur at the same time.
This was first spotted in
com
On Mon, 14 Jan 2019 21:57:15 +0100,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-01-14 18:00:02)
> > On Mon, 14 Jan 2019 18:51:31 +0100,
> > Chris Wilson wrote:
> > >
> > > Quoting Takashi Iwai (2019-01-14 17:46:57)
> > > > On Mon, 14 Jan 2019 18:37:53 +0100,
> > > > Chris Wilson wrote:
> >
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull th
== Series Details ==
Series: series starting with [1/8] drm/i915: Serialise concurrent calls to
i915_gem_set_wedged()
URL : https://patchwork.freedesktop.org/series/55200/
State : failure
== Summary ==
Applying: drm/i915: Serialise concurrent calls to i915_gem_set_wedged()
Applying: drm/i915:
== Series Details ==
Series: series starting with [1/3] drm/i915: Prevent concurrent GGTT update and
use on Braswell (again)
URL : https://patchwork.freedesktop.org/series/55201/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
071bbd0707df drm/i915: Prevent concurrent GGTT updat
== Series Details ==
Series: series starting with [1/3] drm/i915: Prevent concurrent GGTT update and
use on Braswell (again)
URL : https://patchwork.freedesktop.org/series/55201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5418 -> Patchwork_11293
===
Quoting Patchwork (2019-01-14 21:26:32)
> == Series Details ==
>
> Series: series starting with [1/8] drm/i915: Serialise concurrent calls to
> i915_gem_set_wedged()
> URL : https://patchwork.freedesktop.org/series/55200/
> State : failure
>
> == Summary ==
>
> Applying: drm/i915: Serialise c
We have two classes of VM, global GTT and per-process GTT. In order to
allow ourselves the freedom to mix both along call chains, distinguish
the two classes with regards to their mutex and lockdep maps.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_g
Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock. Howev
== Series Details ==
Series: drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex (rev3)
URL : https://patchwork.freedesktop.org/series/46547/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5418 -> Patchwork_11294
Su
Th heavy variant of gem_ctx_switch does little more than provide an
alternate timing for the basic gem_ctx_switch; the timing only effects
the HW and does not stress the driver any differently. As such,
including gem_ctx_switch/heavy provides no more basic coverage for BAT
over and above the defaul
1 - 100 of 111 matches
Mail list logo
