[Intel-gfx] [PATCH] drm/i915: hpd_init needs to be audited for runtime pm
Imre Deak
imre.deak at intel.com
Tue May 27 23:17:50 CEST 2014
On Tue, 2014-05-27 at 22:58 +0200, Daniel Vetter wrote:
> Looks like work for Imre or someone else from the runtime pm gang.
>
> Cc: Imre Deak <imre.deak at intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> ---
> drivers/gpu/drm/i915/i915_irq.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 4ef642348450..4dbdd3b23758 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4423,6 +4423,10 @@ void intel_hpd_init(struct drm_device *dev)
> unsigned long irqflags;
> int i;
>
> + /*
> + * AUDIT-ME: This looks unsafe now that we run hpd_init at interesting
> + * times due to runtime pm. Same for the connector->polled access below.
> + */
Ok, I can go through it, also considering if it's safe to be called from
other platforms as discussed on IRC. But the above comment seems to
suggest that we can get here via the runtime PM resume path, which can
really be called at basically any time (making locking etc an
interesting problem). But that's not really true in this case, since -
on VLV at least - we get here only from a well defined point during a
modeset-on transition.
--Imre
> for (i = 1; i < HPD_NUM_PINS; i++) {
> dev_priv->hpd_stats[i].hpd_cnt = 0;
> dev_priv->hpd_stats[i].hpd_mark = HPD_ENABLED;
More information about the Intel-gfx
mailing list