* [PATCH] drm/i915: Don't complain about stolen conflicts on gen3 @ 2014-04-11 13:55 Daniel Vetter 2014-12-05 18:30 ` Jesse Barnes 0 siblings, 1 reply; 4+ messages in thread From: Daniel Vetter @ 2014-04-11 13:55 UTC (permalink / raw) To: Intel Graphics Development; +Cc: Daniel Vetter 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; -- 1.8.5.2 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] drm/i915: Don't complain about stolen conflicts on gen3 2014-04-11 13:55 [PATCH] drm/i915: Don't complain about stolen conflicts on gen3 Daniel Vetter @ 2014-12-05 18:30 ` Jesse Barnes 2014-12-05 20:35 ` Daniel Vetter 0 siblings, 1 reply; 4+ messages in thread From: Jesse Barnes @ 2014-12-05 18:30 UTC (permalink / raw) To: Daniel Vetter; +Cc: Nikula, Jani, Intel Graphics Development, stable 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. Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] drm/i915: Don't complain about stolen conflicts on gen3 2014-12-05 18:30 ` Jesse Barnes @ 2014-12-05 20:35 ` Daniel Vetter 2014-12-08 12:46 ` Jani Nikula 0 siblings, 1 reply; 4+ messages in thread From: Daniel Vetter @ 2014-12-05 20:35 UTC (permalink / raw) To: Jesse Barnes Cc: Nikula, Jani, Daniel Vetter, Intel Graphics Development, stable 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] drm/i915: Don't complain about stolen conflicts on gen3 2014-12-05 20:35 ` Daniel Vetter @ 2014-12-08 12:46 ` Jani Nikula 0 siblings, 0 replies; 4+ messages in thread From: Jani Nikula @ 2014-12-08 12:46 UTC (permalink / raw) To: Daniel Vetter, Jesse Barnes Cc: Daniel Vetter, Intel Graphics Development, stable On Fri, 05 Dec 2014, Daniel Vetter <daniel@ffwll.ch> wrote: > 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? Pushed to drm-intel-next-fixes, thanks for the patch and review. BR, Jani. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-12-08 12:46 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-04-11 13:55 [PATCH] drm/i915: Don't complain about stolen conflicts on gen3 Daniel Vetter 2014-12-05 18:30 ` Jesse Barnes 2014-12-05 20:35 ` Daniel Vetter 2014-12-08 12:46 ` Jani Nikula
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox