Re: [PATCH] drm/i915: Don't complain about stolen conflicts on gen3

From: Daniel Vetter <daniel@ffwll.ch>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "Nikula, Jani" <jani.nikula@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Don't complain about stolen conflicts on gen3
Date: Fri, 5 Dec 2014 21:35:11 +0100	[thread overview]
Message-ID: <20141205203511.GU20350@phenom.ffwll.local> (raw)
In-Reply-To: <20141205103047.266fdedd@jbarnes-t420>

On Fri, Dec 05, 2014 at 10:30:47AM -0800, Jesse Barnes wrote:
> On Fri, 11 Apr 2014 15:55:17 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 
> > Apparently stuff works that way on those machines.
> > 
> > I agree with Chris' concern that this is a bit risky but imo worth a
> > shot in -next just for fun. Afaics all these machines have the pci
> > resources allocated like that by the BIOS, so I suspect that it's all
> > ok.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76983
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71031
> > Tested-by: lu hua <huax.lu@intel.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c index
> > 62ef55ba061c..99d147af173a 100644 ---
> > a/drivers/gpu/drm/i915/i915_gem_stolen.c +++
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -93,7 +93,11 @@ static
> > unsigned long i915_stolen_to_physical(struct drm_device *dev) r =
> > devm_request_mem_region(dev->dev, base + 1, dev_priv->gtt.stolen_size
> > - 1, "Graphics Stolen Memory");
> > -		if (r == NULL) {
> > +		/*
> > +		 * GEN3 firmware likes to smash pci bridges into the
> > stolen
> > +		 * range. Apparently this works.
> > +		 */
> > +		if (r == NULL && !IS_GEN3(dev)) {
> >  			DRM_ERROR("conflict detected with stolen
> > region: [0x%08x - 0x%08x]\n", base, base +
> > (uint32_t)dev_priv->gtt.stolen_size); base = 0;
> 
> 
> Yeah just to allay fears: the decode priority on the GMCH is fixed and
> specific.  The stolen range is demarcated by some regs which the GMCH
> decodes before it tries going out into PCI space.  So it's safe to see
> the stolen range under the bus0 window (probably even under some device
> window down the range) but does make things messier for us.
> 
> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> Looks like the reporter gave a t-b too.

The other t-b from the other bugzilla is missing though:

Tested-by: Paul Menzel <paulepanter@users.sourceforge.net> 
Cc: stable@vger.kernel.org

This regression goes back to

commit eaba1b8f3379b5d100bd146b9a41d28348bdfd09
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jul 4 12:28:35 2013 +0100

    drm/i915: Verify that our stolen memory doesn't conflict

Jani, can you please pick this up for 3.19?

Thanks, 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