On 06/12 08:14, S, Deepak wrote: > > > On 6/11/2014 10:26 PM, Ville Syrjälä wrote: > >On Fri, Jun 06, 2014 at 08:03:20AM -0700, Jesse Barnes wrote: > >>On Fri, 6 Jun 2014 11:29:24 +0300 > >>Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> > >>>On Thu, Jun 05, 2014 at 01:49:34PM -0700, Jesse Barnes wrote: > >>>>This may take awhile (~10ms), and we don't need to make noise about it. > >>>> > >>>>References: https://bugs.freedesktop.org/show_bug.cgi?id=75244 > >>>>Tested-by: huax.lu@xxxxxxxxx > >>>>Signed-off-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> > >>>>--- > >>>> drivers/gpu/drm/i915/intel_pm.c | 4 ---- > >>>> 1 file changed, 4 deletions(-) > >>>> > >>>>diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > >>>>index ee27d74..4eebfd8 100644 > >>>>--- a/drivers/gpu/drm/i915/intel_pm.c > >>>>+++ b/drivers/gpu/drm/i915/intel_pm.c > >>>>@@ -3227,10 +3227,6 @@ static void vlv_set_rps_idle(struct drm_i915_private *dev_priv) > >>>> vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, > >>>> dev_priv->rps.min_freq_softlimit); > >>>> > >>>>- if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS)) > >>>>- & GENFREQSTATUS) == 0, 5)) > >>>>- DRM_ERROR("timed out waiting for Punit\n"); > >>>>- > >>> > >>>As I recall the entire point of this was to make sure the frequency > >>>really drops before we allow turning off the clock. I'm not sure if we > >>>can trust that the frequency (and more importantly the voltage) will > >>>drop if we allow turning off the clock before the transition is > >>>complete. > >> > >>well, we may need to increase the timeout then... let's see if that > >>helps with the bug. > > > >FYI I played around with my BYT a bit and it doesn't appear to require > >this "force gfx clock on" part of the workaround. > > > >I was polling VLV_GTLC_SURVIVABILITY_REG and VLV_GTLC_PW_STATUS to make > >sure both render and media wells and the gfx clock remain off, and I > >was also monitoring vnn via svid. While that was going on I just rewrote > >PUNIT_REG_GPU_FREQ_REQ to make Punit change the frequency, and sure > >enough it did, and svid showed me that vnn had also changed. So it > >appears there's no need to have the gfx clock on to change its frequency > >on this BYT. > > > >I wonder if this part of the workaround was only needed on older parts. > >Deepak, any ideas? > > Yes ville, this was added initial for older parts and force gfx > clock was part of the workaround. > We have not verified this on newer parts. Let me check with hw guys > to see if workaround still exits and when this was fixed. > > Thanks > Deepak This is a bit side topic. In the vlv_set_rps_idle, it try to mask the turbo interrupt by writing to GEN6_PMINTRMSK (offset 0xA168). But based on the bspec, the PMIMR for BYT/GEN6 should be 0x44024 (GEN6_PMIMR). Not sure I miss anything. If there offset is wrong, mean the turbo has not mask at all. Regards, Chon Ming > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx