[Intel-gfx] [PATCH v2 2/2] drm/i915/skl: Increase PCODE CDCLK change notify timeout

Imre Deak imre.deak at intel.com
Mon Nov 28 11:12:13 UTC 2016


On pe, 2016-11-25 at 11:44 +0000, Chris Wilson wrote:
> On Fri, Nov 25, 2016 at 01:30:38PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 25, 2016 at 12:57:01PM +0200, Imre Deak wrote:
> > > commit 848496e5902833600f7992f4faa82dc1546051ba
> > > Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > Date:   Wed Jul 13 16:32:03 2016 +0300
> > > 
> > >     drm/i915: Wait up to 3ms for the pcu to ack the cdclk change
> > > request on SKL
> > > 
> > > increased the timeout to match the spec, but we still see a
> > > timeout on
> > > at least one SKL. A CDCLK change request following the failed one
> > > will
> > > succeed nevertheless, so let's try to increase the timeout to
> > > 10ms.
> > > 
> > > v2:
> > > - Use 1ms poll period instead of 10us. (Chris)
> > 
> > I'm not sure that's what we want. IIRC the spec says no delay
> > between
> > attempts, so I'm not sure this isn't just going to make it more
> > likely
> > to fail.
> 
> Hmm. We're going to be scheduled away eventually, unless we steal the
> cpu for 10ms. To be strict to the spec we would need
> 
> 	preempt_disable();
> 	ret = wait_for_atomic(pcu_ready(), 10);
> 	preempt_enable();
> 
> 	return ret;

Yes, after some testing it looks like when things fail we call
pcu_ready() only once after scheduling away for 3ms and so if that one
call fails we time out. So I think we need preempt_disable(), I updated
the patch adding that.

--Imre


More information about the Intel-gfx mailing list