From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Stéphane Marchesin" <marcheu@chromium.org>
Cc: Ben Widawsky <ben@bwidawsk.net>,
intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Don't load context at driver init time on SNB
Date: Tue, 13 Aug 2013 11:11:02 +0300 [thread overview]
Message-ID: <20130813081102.GD7159@intel.com> (raw)
In-Reply-To: <CADMs+9ZZCxxhy4W37JFDxJvC8YNoyrENVqTP+FiH5CBq-7rzpA@mail.gmail.com>
On Mon, Aug 12, 2013 at 10:33:37AM -0700, Stéphane Marchesin wrote:
> On Fri, Aug 9, 2013 at 9:55 PM, Ben Widawsky <ben@bwidawsk.net> wrote:
> > On Fri, Aug 09, 2013 at 08:32:54PM -0700, Stéphane Marchesin wrote:
> >> This is a partial revert of b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
> >> (drm/i915: load boot context at driver init time)
> >>
> >> This bit breaks hardware video decode for me after resume.
> >>
> >> Signed-off-by: Stéphane Marchesin <marcheu@chromium.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 f895d15..ffa4ab2 100644
> >> --- a/drivers/gpu/drm/i915/intel_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >> @@ -4614,10 +4614,6 @@ static void gen6_init_clock_gating(struct drm_device *dev)
> >> ILK_DPARBUNIT_CLOCK_GATE_ENABLE |
> >> ILK_DPFDUNIT_CLOCK_GATE_ENABLE);
> >>
> >> - /* WaMbcDriverBootEnable:snb */
> >> - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) |
> >> - GEN6_MBCTL_ENABLE_BOOT_FETCH);
> >> -
> >> g4x_disable_trickle_feed(dev);
> >>
> >> /* The default value should be 0x200 according to docs, but the two
> >
> > I was looking at this a bit with Stéphane. One thing we both see is that
> > the bit isn't sticking as it should. Clearly doing the write is having
> > an effect, but something is seriously wrong. Writing the bit manually
> > with IGT does make the bit stick.
> >
> > Stéphane, could you try to write the bit with IGT before and after
> > resume, and see if it helps?
>
> It doesn't seem to stick, and so seems to have no effect.
>
> The confusing thing is that video decode works fine before suspend,
> even though that reg is 0. And after resume, it is broken, and that
> reg is still 0. So something else is going on. Maybe this reg is
> write-once-ever?
BSpec says "This Bit is cleared by the Hardware once the Boot fetch is
complete."
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2013-08-13 8:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-10 3:32 [PATCH] drm/i915: Don't load context at driver init time on SNB Stéphane Marchesin
2013-08-10 4:55 ` Ben Widawsky
2013-08-12 17:33 ` Stéphane Marchesin
2013-08-13 8:11 ` Ville Syrjälä [this message]
2013-08-14 17:41 ` Stéphane Marchesin
2013-08-20 17:38 ` Jesse Barnes
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=20130813081102.GD7159@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ben@bwidawsk.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=marcheu@chromium.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