Re: [PATCH v5 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification

[Imre Deak <imre.deak@intel.com>]

On ma, 2016-11-28 at 17:13 +0000, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 06:40:33PM +0200, Imre Deak wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index 66c62f3..4e06e92 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7864,6 +7864,59 @@ int sandybridge_pcode_write(struct drm_i915_private *dev_priv,
> >  	return 0;
> >  }
> >  
> > +static bool skl_pcode_try_request(struct drm_i915_private *dev_priv, u32 mbox,
> > +				  u32 request, u32 reply_mask, u32 reply,
> > +				  u32 *status)
> > +{
> > +	u32 val = request;
> > +
> > +	*status = sandybridge_pcode_read(dev_priv, mbox, &val);
> 
> Hmm. This in turn uses a plain wait_for() that we want to stop relying
> on drm_can_sleep() in future. Right now, it's ok but we're just making
> things harder for ourselves later. I'm not keen on the alternative
> though (passing around I am atomic flags, or making more things atomic
> by default). :|

Another way would be to factor out common parts of
sandybridge_pcode_read/write and implement skl_pcode_try_request() in
terms of those parts. But not sure if that would look better than just
passing an is_atomic flag to sandybridge_pcode_read().

> -Chris
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx