All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "S, Deepak" <deepak.s@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/vlv: drop punit freq staus read after setting idle
Date: Wed, 11 Jun 2014 19:56:11 +0300	[thread overview]
Message-ID: <20140611165611.GM27580@intel.com> (raw)
In-Reply-To: <20140606080320.20fcd778@jbarnes-desktop>

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@linux.intel.com> 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@intel.com
> > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> > > ---
> > >  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?

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2014-06-11 16:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 20:49 [PATCH] drm/i915/vlv: drop punit freq staus read after setting idle Jesse Barnes
2014-06-06  8:29 ` Ville Syrjälä
2014-06-06 15:03   ` Jesse Barnes
2014-06-11 16:56     ` Ville Syrjälä [this message]
2014-06-12  2:44       ` S, Deepak
2014-06-12  7:37         ` Lee, Chon Ming
2014-06-12  8:08           ` Daniel Vetter
2014-06-12  8:11           ` Ville Syrjälä
2014-06-12  8:19             ` Lee, Chon Ming
2014-06-12 18:15         ` S, Deepak
2014-06-12 18:40           ` Ville Syrjälä
2014-06-12 18:41             ` S, Deepak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140611165611.GM27580@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=deepak.s@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jbarnes@virtuousgeek.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.