[Intel-gfx] [PATCH v5 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
Imre Deak
imre.deak at intel.com
Mon Nov 28 18:55:29 UTC 2016
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
>
More information about the Intel-gfx
mailing list