[Intel-gfx] [PATCH 09/15] drm/i915: Fix intel_psr_is_enabled function and document it.

Daniel Vetter daniel at ffwll.ch
Wed Nov 19 14:51:56 CET 2014


On Tue, Nov 18, 2014 at 06:24:30PM +0000, R, Durgadoss wrote:
> >-----Original Message-----
> >From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf Of Rodrigo Vivi
> >Sent: Friday, November 14, 2014 10:23 PM
> >To: intel-gfx at lists.freedesktop.org
> >Cc: Vivi, Rodrigo
> >Subject: [Intel-gfx] [PATCH 09/15] drm/i915: Fix intel_psr_is_enabled function and document it.
> >
> >This function can be used to check if psr feature got enabled.
> >However on HSW and BDW we currently force psr exit by disabling
> >EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually
> >returning the active/inactive state that is different from the enable/disable
> >meaning and had the risk of false negative.
> >
> >So let's just return the presence of intel_dp at dev_priv->psr.enabled.
> >
> >It would be more easy to just check this presence directly but let's keep
> >it more organized.
> 
> Agreed, but shouldn't we protect it using psr.lock ?

This function is used by DRRS and in a pretty crazy way. Sprinkling docs
and locking over it won't make this any better, what we need is some state
bits in the pipe config so that PSR and DRRS don't step on each anothers
feet. This kind of stuff here doesn't really work as soon as you throw in
the atomic check/commit semeantics we'll eventually have.

If possible I'd vote to just drop this, DRRS isn't enabled by default
currently anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list