From: Daniel Vetter <daniel@ffwll.ch>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Deepak S <deepak.s@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: add cherryview specfic forcewake in execlists_elsp_write
Date: Wed, 10 Sep 2014 09:16:45 +0200 [thread overview]
Message-ID: <20140910071645.GP15520@phenom.ffwll.local> (raw)
In-Reply-To: <20140909142550.124035ff@jbarnes-t420>
On Tue, Sep 09, 2014 at 02:25:50PM -0700, Jesse Barnes wrote:
> On Tue, 09 Sep 2014 21:45:08 +0530
> Deepak S <deepak.s@intel.com> wrote:
>
> >
> > On Monday 08 September 2014 08:10 PM, Daniel Vetter wrote:
> > > On Mon, Sep 08, 2014 at 05:14:23PM +0300, Ville Syrjälä wrote:
> > >> 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.
> > > Yeah this is just broken design. And if you look at the other wheel
> > > to track outstanding gpu work (requests) then it's not needed at
> > > all.
> > >
> > > But I'm not sure what's the priority of the "rework execlists to use
> > > requests" task is and when (if ever that will happen). Jesse is the
> > > arbiter for this stuff anyway, so adding him.
> > > -Daniel
> >
> > hmm , agreed do we have a reworked execlist? The reason why added
> > this, on chv when i enable execlist, due to incorrect forcewake count
> > is causing multiple entries to forcewake_get resulting in "*ERROR*:
> > Timed out waiting for forcewake old ack to clear" "and Hang.
>
> I'm hoping we can get execlists reworked on top of the request/seqno
> stuff shortly after it lands, but I don't think that's a reason to
> block this fix, since Chris is still busy fixing up the request
> changes.
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-09-10 7:16 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ä
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 [this message]
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=20140910071645.GP15520@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox