[Intel-gfx] [PATCH v3 4/7] drm/i915: add support for checking if we hold an RPM reference

[Chris Wilson]

On Thu, Nov 12, 2015 at 06:40:18PM +0200, Imre Deak wrote:
> Atm, we assert that the device is not suspended until the point when the
> HW is truly put to a suspended state. This is fine, but we can catch
> more problems if we check the RPM refcount. After that one drops to zero
> we shouldn't access the HW any more, although the actual suspend may be
> delayed. Based on this change the assert_rpm_wakelock_held helper to
> check the refcount instead of the device suspended state.
> 
> After this change we need to annotate every place explicitly in the code
> where we expect that the HW is in D0 state. Atm in the driver load
> function the D0 state is implicit until we enable runtime PM, but for
> these asserts to work we need to add explicit RPM get/put calls, so fix
> this up.
> 
> Another place where the D0 state is implicit even with a 0 RPM refcount
> is the system and runtime sudpend/resume handlers and the hangcheck
> work. In the former case the susend/resume handlers themselves determine
> at which exact spot the HW is truly on/off and in the latter case the
> work will be flushed in the suspend handler before turning off the HW.
> We regard these cases special and disable the RPM asserts for their
> duration. In the hangcheck work we can nevertheless check that the
> device is not suspended. Fix up these things.
> 
> These explicit annotations also have the positive side effect of
> documenting our assumptions better.
> 
> This caught additional WARNs from the atomic modeset path, those should
> be fixed separately.
> 
> v2:
> - remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville)
> v3:
> - use a new dedicated RPM wakelock refcount to also catch cases where
>   our own RPM get/put functions were not called (Chris)
> - assert also that the new RPM wakelock refcount is 0 in the RPM
>   suspend handler (Chris)
> - change the assert error message to be more meaningful (Chris)
> - prevent false assert errors and check that the RPM wakelock is 0 in
>   the RPM resume handler too
> - prevent false assert errors in the hangcheck work too
> - add a device not suspended assert check to the hangcheck work
> 
> Signed-off-by: Imre Deak <imre.deak at intel.com>
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre