From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel@ffwll.ch>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
intel-gfx@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH] drm/i915: Add missing ring_mask to Pineview
Date: Wed, 3 Aug 2016 09:33:42 +0200 [thread overview]
Message-ID: <20160803073342.GD6232@phenom.ffwll.local> (raw)
In-Reply-To: <20160802144729.GB20686@nuc-i3427.alporthouse.com>
On Tue, Aug 02, 2016 at 03:47:29PM +0100, Chris Wilson wrote:
> On Tue, Aug 02, 2016 at 04:34:25PM +0200, Daniel Vetter wrote:
> > On Fri, Jul 29, 2016 at 12:10:30PM +0100, Chris Wilson wrote:
> > > On Fri, Jul 29, 2016 at 10:57:49AM +0200, Daniel Vetter wrote:
> > > > On Fri, Jul 29, 2016 at 11:42:24AM +0300, Joonas Lahtinen wrote:
> > > > > On pe, 2016-07-29 at 00:45 +0100, Chris Wilson wrote:
> > > > > > It appears that we never told Pineview it has a RENDER_RING. This was
> > > > > > all fine until we started using the ring_mask for determining all the
> > > > > > available rings to initialise for legacy ringbuffer submission in commit
> > > > > > 88d2ba2e95c8 ("drm/i915: Unify engine init loop"). Though really it is a
> > > > > > latent bug since the ring_mask inception in commit 73ae478cdf6a
> > > > > > ("drm/i915: Replace has_bsd/blt/vebox with a mask").
> > > > > >
> > > > > > To prevent similar mishaps in future, add a WARN_ON() if we find
> > > > > > ourselves with a device without any rings.
> > > > > >
> > > > > > Fixes: 73ae478cdf6a ("drm/i915: Replace has_bsd/blt/vebox with a mask")
> > > > > > Fixes: 88d2ba2e95c8 ("drm/i915: Unify engine init loop")
> > > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > > > > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > > Cc: Ben Widawsky <ben@bwidawsk.net>
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_pci.c | 1 +
> > > > > > drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
> > > > > > 2 files changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> > > > > > index 949c01686a66..2587b1bd41f4 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > > > > @@ -173,6 +173,7 @@ static const struct intel_device_info intel_pineview_info = {
> > > > > > .gen = 3, .is_g33 = 1, .is_pineview = 1, .is_mobile = 1, .num_pipes = 2,
> > > > > > .need_gfx_hws = 1, .has_hotplug = 1,
> > > > > > .has_overlay = 1,
> > > > > > + .ring_mask = RENDER_RING,
> > > > > > GEN_DEFAULT_PIPEOFFSETS,
> > > > > > CURSOR_OFFSETS,
> > > > > > };
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > > > index 31d43dfa7469..e6422aac2919 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > > > @@ -117,6 +117,7 @@ int intel_engines_init(struct drm_device *dev)
> > > > > > unsigned int i;
> > > > > > int ret;
> > > > > >
> > > > > > + WARN_ON(INTEL_INFO(dev_priv)->ring_mask == 0);
> > > > >
> > > > > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > >
> > > > dim says this also needs a
> > > >
> > > > Cc: drm-intel-fixes@lists.freedesktop.org
> > >
> > > dim says nothing of the sort for me. The bug is only relevant from
> > > 88d2ba2e95c8
> >
> > $ dim fixes 88d2ba2e95c8
>
> What state does dim fixes depend upon? If did not report anything when I
> ran it against the patch before pushing.
3 cases for where the offending commit is:
- It's in a release tag -> cc: stable
- It's in an -rc tag -> cc: fixes
- It tries to make an educate guess for when stuff needs to be
cherry-picked to dinf.
It's not entirely correct. tbh I'm not sure whether dim fixes is a good
idea, or whether we should just pimp the script to figure this out at
cherry-pick time. This is kinda still open and Jani&me are trying to
figure out what is best. Suggestions welcome.
In the end I simply did another scan for Fixes: when cherry-picking to
make sure I didn't miss anything.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2016-08-03 7:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-28 23:45 [PATCH] drm/i915: Add missing ring_mask to Pineview Chris Wilson
2016-07-29 5:51 ` ✗ Ro.CI.BAT: failure for " Patchwork
2016-07-29 15:25 ` Chris Wilson
2016-07-29 8:42 ` [PATCH] " Joonas Lahtinen
2016-07-29 8:57 ` Daniel Vetter
2016-07-29 11:10 ` Chris Wilson
2016-07-29 18:54 ` Ben Widawsky
2016-08-02 14:34 ` Daniel Vetter
2016-08-02 14:47 ` Chris Wilson
2016-08-03 7:33 ` Daniel Vetter [this message]
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=20160803073342.GD6232@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=ben@bwidawsk.net \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.