All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Hans de Goede <hdegoede@redhat.com>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Len Brown <lenb@kernel.org>,
	"russianneuromancer @ ya . ru" <russianneuromancer@ya.ru>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	linux-i2c@vger.kernel.org
Subject: Re: [RFC 3/4] drm/i915: valleyview: Make intel_set_rps get FORCEWAKE_MEDIA
Date: Mon, 2 Jan 2017 17:08:34 +0200	[thread overview]
Message-ID: <20170102150834.GB31595@intel.com> (raw)
In-Reply-To: <20170102150225.GA31595@intel.com>

On Mon, Jan 02, 2017 at 05:02:25PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 02, 2017 at 02:53:59PM +0000, Chris Wilson wrote:
> > On Mon, Jan 02, 2017 at 04:40:05PM +0200, Ville Syrjälä wrote:
> > > On Mon, Jan 02, 2017 at 02:21:58PM +0000, Chris Wilson wrote:
> > > > On Mon, Jan 02, 2017 at 04:10:49PM +0200, Ville Syrjälä wrote:
> > > > > On Mon, Jan 02, 2017 at 11:37:59AM +0000, Chris Wilson wrote:
> > > > > > On Sun, Jan 01, 2017 at 09:48:53PM +0100, Hans de Goede wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On 01-01-17 21:24, Chris Wilson wrote:
> > > > > > > >On Sun, Jan 01, 2017 at 09:14:02PM +0100, Hans de Goede wrote:
> > > > > > > >>All callers of valleyview_set_rps() get at least FORCEWAKE_MEDIA, except
> > > > > > > >>for intel_set_rps(). Since intel_set_rps can for example be called from
> > > > > > > >>sysfs store functions, there is no guarantee this is already done, so add
> > > > > > > >>an intel_uncore_forcewake_get(FORCEWAKE_MEDIA) call to intel_set_rps.
> > > > > > > >>
> > > > > > > >>Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > > > > > >>---
> > > > > > > >> drivers/gpu/drm/i915/intel_pm.c | 9 +++++++--
> > > > > > > >> 1 file changed, 7 insertions(+), 2 deletions(-)
> > > > > > > >>
> > > > > > > >>diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > >>index 4b12637..cc4fbd7 100644
> > > > > > > >>--- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > >>+++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > >>@@ -5096,9 +5096,14 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
> > > > > > > >>
> > > > > > > >> void intel_set_rps(struct drm_i915_private *dev_priv, u8 val)
> > > > > > > >> {
> > > > > > > >>-	if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > > > > >>+	if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > > > > > > >>+		/* Wake up the media well, as that takes a lot less
> > > > > > > >>+		 * power than the Render well.
> > > > > > > >>+		 */
> > > > > > > >>+		intel_uncore_forcewake_get(dev_priv, FORCEWAKE_MEDIA);
> > > > > > > >> 		valleyview_set_rps(dev_priv, val);
> > > > > > > >
> > > > > > > >Both powerwells are woken for rps. (Taking one but not the other has no
> > > > > > > >benefit, and very misleading.)
> > > > > > > 
> > > > > > > The comment on why FORCEWAKE_MEDIA is used + code is copy pasted from the
> > > > > > > existing code in vlv_set_rps_idle().
> > > > > > 
> > > > > > It's not correct there either...
> > > > > 
> > > > > Why not? If the render well is in rc6 already we don't want to waste
> > > > > power by waking it. The only reason we have to wake up *something* is
> > > > > so that the gpll frequency actually gets changed.
> > > > 
> > > > If the register write requires the powerwell, the mmio access will take
> > > > the powerwell.
> > > 
> > > The register write doesn't require a power well. It's a sideband access.
> > > The punit will simply not change the GPLL frequency if the GPLL is
> > > currently not running (which will/can happen when all power wells are
> > > asleep). That in itself doesn't sound too back (why change the
> > > frequency if the thing isn't even running, right?). But the real problem
> > > is that the punit will not let the voltage on the rail to drop
> > > either until the new frequency gets programmed into the GPLL. Hence if
> > > the GPU goes idle before we've dropped the GPLL frequency to the
> > > minimum value, we will waste power by having a needlessly high voltage.
> > > 
> > > Originally we tried to avoid this problem via vlv_force_gfx_clock(),
> > > which should just force the GPLL to turn on without powering on
> > > any power wells. But that caused some spurious WARNs or something
> > > IIRC, so we had to come up with another workaround. And since powering
> > > either well is sufficient we chose to use the cheaper media well.
> > 
> > That explains set_idle() (and would be a better comment that the one
> > there). But not set_rps(), since there we don't care if the write is
> > delayed until the GPU is next active.
> 
> I don't see any forcewakes in set_rps()

Ah, it was this patch which wants to add that. And indeed that doesn't
make sense.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-01-02 15:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-01 20:13 [RFC 0/4] Coordinate pmic i2c bus and i915 punit accesses Hans de Goede
2017-01-01 20:14 ` [RFC 1/4] x86/platform/intel/iosf_mbi: Add a mutex for punit access Hans de Goede
2017-01-02 14:12   ` Ville Syrjälä
2017-01-02 14:21     ` Hans de Goede
2017-01-13  9:26       ` Ville Syrjälä
2017-01-13 10:34         ` Jarkko Nikula
2017-01-13 10:51           ` Ville Syrjälä
2017-01-13 11:12             ` Jarkko Nikula
2017-01-13 12:20               ` Ville Syrjälä
2017-01-13 16:06         ` Hans de Goede
2017-01-13 16:30           ` Ville Syrjälä
2017-01-15 11:10             ` Hans de Goede
2017-01-01 20:14 ` [RFC 2/4] i2c: designware-baytrail: Take punit lock on bus acquire Hans de Goede
2017-01-01 20:14 ` [RFC 3/4] drm/i915: valleyview: Make intel_set_rps get FORCEWAKE_MEDIA Hans de Goede
2017-01-01 20:24   ` [Intel-gfx] " Chris Wilson
2017-01-01 20:48     ` Hans de Goede
2017-01-02 11:37       ` [Intel-gfx] " Chris Wilson
2017-01-02 12:40         ` Hans de Goede
2017-01-02 14:10         ` Ville Syrjälä
2017-01-02 14:21           ` Chris Wilson
2017-01-02 14:40             ` Ville Syrjälä
2017-01-02 14:53               ` [Intel-gfx] " Chris Wilson
2017-01-02 15:02                 ` Ville Syrjälä
2017-01-02 15:08                   ` Ville Syrjälä [this message]
2017-01-01 20:14 ` [RFC 4/4] drm/i915: valleyview: Take punit lock when modifying punit settings Hans de Goede

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=20170102150834.GB31595@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=hdegoede@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=russianneuromancer@ya.ru \
    /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.