From: Thomas Meyer <thomas@m3y3r.de>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: jikos@suse.cz,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Pavel Machek <pavel@ucw.cz>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Linux 3.16-rc2
Date: Wed, 02 Jul 2014 18:18:41 +0200 [thread overview]
Message-ID: <1404317921.3910.3.camel@localhost.localdomain> (raw)
In-Reply-To: <20140630100925.GA18836@nuc-i3427.alporthouse.com>
Am Montag, den 30.06.2014, 11:09 +0100 schrieb Chris Wilson:
> On Mon, Jun 30, 2014 at 12:02:20PM +0200, Pavel Machek wrote:
> > On Tue 2014-06-24 13:27:37, Chris Wilson wrote:
> > > On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> > > > Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> > > > > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > > > > > On Tue, 24 Jun 2014, Thomas Meyer <thomas@m3y3r.de> wrote:
> > > > > > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > > > > > > X server.
> > > > > >
> > > > > > This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> > > > > > [1]. Also related [2].
> > > > > >
> > > > > > Chris, any fresh ideas?
> > > > >
> > > > > Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
> > > > > everything we know and have tried is there. Which is not much more than
> > > > > at time of the original incarnation:
> > > > >
> > > > > commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
> > > > > Author: Keith Packard <keithp@keithp.com>
> > > > > Date: Tue Oct 14 17:20:35 2008 -0700
> > > > >
> > > > > i915: Fix up ring initialization to cover G45 oddities
> > > > >
> > > > > G45 appears quite sensitive to ring initialization register writes,
> > > > > sometimes leaving the HEAD register with the START register contents. Check
> > > > > to make sure HEAD is reset correctly when START is written, and fix it up,
> > > > > screaming loudly.
> > > > > -Chris
> > > > >
> > > >
> > > > Hi,
> > > >
> > > > so why not revert 78f2975eec9faff353a6194e854d3d39907bab68 (drm/i915:
> > > > Move all ring resets before setting the HWS page) ?
> > >
> > > Because that patch was in response to a boot time regression.
> >
> > It seems we are in a fairly ugly "fix one board, it breaks another" iterations, right?
> >
> > (BTW, if you apply patch to fix this bug, could you Cc me? I have strange feeling
> > that it will break my setup... Actually, it probably makes sense to Cc all the people
> > who reported problems with ring initialization...
> >
> > What patch caused the boot time regression you are talking about? We need to get
> > list of commits involved in this, and revert the original one...
>
> commit 9991ae787a0c87fe7c783b4b6f4754c3cdbb6213
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date: Wed Apr 2 16:36:07 2014 +0100
>
> drm/i915: Move all ring resets before setting the HWS page
>
> In commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
> Author: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
> Date: Wed Mar 12 16:39:40 2014 +0530
>
> drm/i915: disable rings before HW status page setup
>
> we reordered stopping the rings to do so before we set the HWS register.
> However, there is an extra workaround for g45 to reset the rings twice,
> and for consistency we should apply that workaround before setting the
> HWS to be sure that the rings are truly stopped.
>
> Cc: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>
> commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
> Author: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
> Date: Wed Mar 12 16:39:40 2014 +0530
>
> drm/i915: disable rings before HW status page setup
>
> Rings should be idle before issuing sync_flush
> (in intel_ring_setup_status_page). This patch moves the ring
> disabling before doing the HW status page setup.
>
> Signed-off-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>
Hi,
this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
regression go away on my machine:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 279488a..b896ac8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -459,22 +459,25 @@ static bool stop_ring(struct intel_engine_cs *ring)
{
struct drm_i915_private *dev_priv = to_i915(ring->dev);
- if (!IS_GEN2(ring->dev)) {
- I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
- if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
- DRM_ERROR("%s :timed out trying to stop ring\n", ring->name);
- return false;
- }
- }
-
+// if (!IS_GEN2(ring->dev)) {
+// I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
+// if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
+// DRM_ERROR("%s :timed out trying to stop ring1\n", ring->name);
+// return false;
+// }
+// }
+
+ /* Stop the ring if it's running. */
I915_WRITE_CTL(ring, 0);
I915_WRITE_HEAD(ring, 0);
ring->write_tail(ring, 0);
+ if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000))
+ DRM_ERROR("%s :timed out trying to stop ring2\n", ring->name);
- if (!IS_GEN2(ring->dev)) {
- (void)I915_READ_CTL(ring);
- I915_WRITE_MODE(ring, _MASKED_BIT_DISABLE(STOP_RING));
- }
+// if (!IS_GEN2(ring->dev)) {
+// (void)I915_READ_CTL(ring);
+// I915_WRITE_MODE(ring, _MASKED_BIT_DISABLE(STOP_RING));
+// }
return (I915_READ_HEAD(ring) & HEAD_ADDR) == 0;
}
Chris, any ideas why explicitly stopping the ring before reset, results
in this kind of misbehaviour on my machine on resume from ram?
with kind regards
thomas
next prev parent reply other threads:[~2014-07-02 16:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+55aFxdAhp-esuGiY4VEugiiwcMJgg1r6fPiR9Fb+HOz_5tLg@mail.gmail.com>
2014-06-23 23:07 ` Linux 3.16-rc2 Thomas Meyer
2014-06-24 11:06 ` Jani Nikula
2014-06-24 11:57 ` Chris Wilson
2014-06-24 12:24 ` Thomas Meyer
2014-06-24 12:27 ` Chris Wilson
2014-06-30 10:02 ` Pavel Machek
2014-06-30 10:09 ` Chris Wilson
2014-07-02 16:18 ` Thomas Meyer [this message]
2014-07-07 15:16 ` Daniel Vetter
2014-07-07 15:32 ` Jiri Kosina
2014-07-07 16:04 ` Chris Wilson
2014-07-07 22:15 ` Jiri Kosina
2014-07-08 8:35 ` Daniel Vetter
2014-07-08 8:59 ` Chris Wilson
2014-07-08 12:46 ` Jiri Kosina
2014-07-08 12:55 ` Chris Wilson
2014-07-08 12:59 ` Jiri Kosina
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=1404317921.3910.3.camel@localhost.localdomain \
--to=thomas@m3y3r.de \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jikos@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=torvalds@linux-foundation.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