From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: deepak.s@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: add cherryview specfic forcewake in execlists_elsp_write
Date: Mon, 8 Sep 2014 17:14:23 +0300 [thread overview]
Message-ID: <20140908141423.GA4193@intel.com> (raw)
In-Reply-To: <20140908140243.GZ4193@intel.com>
On Mon, Sep 08, 2014 at 05:02:43PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 09, 2014 at 07:14:16PM +0530, deepak.s@linux.intel.com wrote:
> > From: Deepak S <deepak.s@linux.intel.com>
> >
> > In chv, we have two power wells Render & Media. We need to use
> > corresponsing forcewake count. If we dont follow this we are getting
> > error "*ERROR*: Timed out waiting for forcewake old ack to clear" due to
> > multiple entry into __vlv_force_wake_get.
> >
> > Signed-off-by: Deepak S <deepak.s@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 29 +++++++++++++++++++++++++----
> > 1 file changed, 25 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> > index bd1b28d..bafd38b 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -300,8 +300,18 @@ static void execlists_elsp_write(struct intel_engine_cs *ring,
> > * Instead, we do the runtime_pm_get/put when creating/destroying requests.
> > */
> > spin_lock_irqsave(&dev_priv->uncore.lock, flags);
> > - if (dev_priv->uncore.forcewake_count++ == 0)
> > - dev_priv->uncore.funcs.force_wake_get(dev_priv, FORCEWAKE_ALL);
> > + if (IS_CHERRYVIEW(dev_priv->dev)) {
> > + if (dev_priv->uncore.fw_rendercount++ == 0)
> > + dev_priv->uncore.funcs.force_wake_get(dev_priv,
> > + FORCEWAKE_RENDER);
> > + if (dev_priv->uncore.fw_mediacount++ == 0)
> > + dev_priv->uncore.funcs.force_wake_get(dev_priv,
> > + FORCEWAKE_MEDIA);
>
> This will wake both wells. Is that needed or should we just pick one
> based on the ring?
Also unlike the comment says runtime_pm_get() can't sleep since someone
must already be holding a reference, othwewise we surely can't go
writing any registers. So in theory we should be able to call
gen6_gt_force_wake_get() here, but maybe that would trigger a
might_sleep() warning. the current force wake code duplication (esp.
outside intel_uncore.c) is rather unfortunate and I'd like to see it
killed off. Maybe we just need to pull the rpm get/put outside
gen6_gt_force_wake_get()? I never really liked hiding it there anyway.
>
> > + } else {
> > + if (dev_priv->uncore.forcewake_count++ == 0)
> > + dev_priv->uncore.funcs.force_wake_get(dev_priv,
> > + FORCEWAKE_ALL);
> > + }
> > spin_unlock_irqrestore(&dev_priv->uncore.lock, flags);
> >
> > I915_WRITE(RING_ELSP(ring), desc[1]);
> > @@ -315,8 +325,19 @@ static void execlists_elsp_write(struct intel_engine_cs *ring,
> >
> > /* Release Force Wakeup (see the big comment above). */
> > spin_lock_irqsave(&dev_priv->uncore.lock, flags);
> > - if (--dev_priv->uncore.forcewake_count == 0)
> > - dev_priv->uncore.funcs.force_wake_put(dev_priv, FORCEWAKE_ALL);
> > + if (IS_CHERRYVIEW(dev_priv->dev)) {
> > + if (--dev_priv->uncore.fw_rendercount == 0)
> > + dev_priv->uncore.funcs.force_wake_put(dev_priv,
> > + FORCEWAKE_RENDER);
> > + if (--dev_priv->uncore.fw_mediacount == 0)
> > + dev_priv->uncore.funcs.force_wake_put(dev_priv,
> > + FORCEWAKE_MEDIA);
> > + } else {
> > + if (--dev_priv->uncore.forcewake_count == 0)
> > + dev_priv->uncore.funcs.force_wake_put(dev_priv,
> > + FORCEWAKE_ALL);
> > + }
> > +
> > spin_unlock_irqrestore(&dev_priv->uncore.lock, flags);
> > }
> >
> > --
> > 1.9.1
>
> --
> Ville Syrjälä
> Intel OTC
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-09-08 14:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 13:44 [PATCH] drm/i915: add cherryview specfic forcewake in execlists_elsp_write deepak.s
2014-09-08 14:02 ` Ville Syrjälä
2014-09-08 14:14 ` Ville Syrjälä [this message]
2014-09-08 14:40 ` Daniel Vetter
2014-09-09 16:15 ` Deepak S
2014-09-09 21:25 ` Jesse Barnes
2014-09-10 7:16 ` Daniel Vetter
2014-09-10 15:47 ` Daniel Vetter
2014-09-10 15:51 ` Chris Wilson
2014-09-10 16:38 ` S, Deepak
2014-09-10 16:43 ` [PATCH] rpm Chris Wilson
2014-09-10 16:57 ` Paulo Zanoni
2014-09-10 17:06 ` Chris Wilson
2014-09-10 17:09 ` Ville Syrjälä
2014-09-10 17:15 ` Ville Syrjälä
2014-09-10 17:19 ` Chris Wilson
2014-09-10 18:34 ` [PATCH] drm/i915: Reduce duplicated forcewake logic Chris Wilson
2014-10-01 15:53 ` Tvrtko Ursulin
2014-10-01 16:02 ` Tvrtko Ursulin
2014-10-01 16:45 ` Chris Wilson
2014-11-07 15:46 ` Ville Syrjälä
2014-11-07 18:55 ` Dave Gordon
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=20140908141423.GA4193@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=deepak.s@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox