public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Chris Wilson" <chris@chris-wilson.co.uk>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915: Reorder hw init to avoid executing with invalid context/mm state
Date: Fri, 5 Dec 2014 15:58:40 +0100	[thread overview]
Message-ID: <20141205145840.GS20350@phenom.ffwll.local> (raw)
In-Reply-To: <20141205143846.GJ13586@nuc-i3427.alporthouse.com>

On Fri, Dec 05, 2014 at 02:38:46PM +0000, Chris Wilson wrote:
> On Fri, Dec 05, 2014 at 04:31:35PM +0200, Ville Syrjälä wrote:
> > On Fri, Dec 05, 2014 at 02:15:22PM +0000, Chris Wilson wrote:
> > > Currently we initialise the rings, add the first context switch to the
> > > ring and execute our golden state then enable (aliasing or full) ppgtt.
> > > However, as we enable ppgtt using direct MMIO but load the PD using
> > > MI_LRI, we end up executing the context switch and golden render state
> > > with an invalid PD generating page faults. To solve this issue, first do
> > > the ppgtt PD setup, then set the default context and write the commands
> > > to run the render state into the ring, before we activate the ring. This
> > > allows us to be sure that the register state is valid before we begin
> > > execution.
> > > 
> > > This was spotted when writing the seqno/request conversion, but only with
> > > the ERROR capture did I realise that it was a necessity now.
> > > 
> > > RFC: cleanup the error handling in i915_gem_init_hw.
> > > 
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem.c         | 20 ++++++++++----------
> > >  drivers/gpu/drm/i915/intel_ringbuffer.c |  9 ++++++---
> > >  2 files changed, 16 insertions(+), 13 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > > index c1c11418231b..c13842d3cbc9 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -4796,15 +4796,15 @@ i915_gem_init_hw(struct drm_device *dev)
> > >  	 */
> > >  	init_unused_rings(dev);
> > >  
> > > -	for_each_ring(ring, dev_priv, i) {
> > > -		ret = ring->init_hw(ring);
> > > -		if (ret)
> > > -			return ret;
> > > -	}
> > > -
> > >  	for (i = 0; i < NUM_L3_SLICES(dev); i++)
> > >  		i915_gem_l3_remap(&dev_priv->ring[RCS], i);
> > 
> > This is going to assume ring->head/tail are already valid?
> 
> We write into the ring obj, not the ring itself, which should be setup
> during the various intel_init_engine, i.e. the backing storage is
> independent of the actual registers.

But there's still intel_ring_advance which calls ->write_tail all over the
place. So we drop all these mmio writes into nirvana since we'll reset the
ring later on?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2014-12-05 14:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 14:15 [PATCH 1/2] drm/i915: Detect page faults during hangcheck Chris Wilson
2014-12-05 14:15 ` [PATCH 2/2] drm/i915: Reorder hw init to avoid executing with invalid context/mm state Chris Wilson
2014-12-05 14:31   ` Ville Syrjälä
2014-12-05 14:38     ` Chris Wilson
2014-12-05 14:53       ` Ville Syrjälä
2014-12-05 16:26         ` Chris Wilson
2014-12-05 17:03           ` Ville Syrjälä
2015-01-21 10:12             ` Chris Wilson
2015-01-21 11:21               ` Ville Syrjälä
2014-12-05 14:58       ` Daniel Vetter [this message]
2014-12-05 16:23         ` Chris Wilson
2014-12-05 21:01           ` Daniel Vetter
2015-01-20 14:55   ` Mika Kuoppala
2015-01-21 10:09     ` Chris Wilson
2014-12-05 21:03 ` [PATCH 1/2] drm/i915: Detect page faults during hangcheck Daniel Vetter
2015-01-21 10:05   ` Chris Wilson

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=20141205145840.GS20350@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /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