[Intel-gfx] [PATCH v2] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
Chris Wilson
chris at chris-wilson.co.uk
Wed Jan 27 07:11:48 PST 2016
On Wed, Jan 27, 2016 at 02:27:20PM +0000, daniele.ceraolospurio at intel.com wrote:
> From: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
>
> While running some tests on the scheduler patches with rpm enabled I
> came across a corruption in the ringbuffer, which was root-caused to
> the GPU being suspended while commands were being emitted to the
> ringbuffer. The access to memory was failing because the GPU needs to
> be awake when accessing stolen memory (where my ringbuffer was located).
> Since we have this constraint it looks like a sensible idea to check
> that we hold a refcount when we access the rungbuffer.
>
> v2: move the check from ring_begin to ringbuffer iomap time (Chris)
>
> Cc: John Harrison <John.C.Harrison at Intel.com>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 6f5b511..c661dfe 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2119,6 +2119,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
> return ret;
> }
>
> + // if we don't hold a wakeref the I/O access can fail
/* C-style comments only */
/* Access through the GTT requires the device to be awake. */
> + assert_rpm_wakelock_held(dev_priv);
Now if we could just add intel_runtime_pm_get_noresume() here
and add intel_runtime_pm_put() to unpin to indicate the range of
the access, that would be ideal. However, that requires us to be more
proactive in dropping the context pin.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list