| Message ID | 1439588061-18064-14-git-send-email-paulo.r.zanoni@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Aug 14, 2015 at 06:34:18PM -0300, Paulo Zanoni wrote:
> The spec says we just can't use it.
But what about when we inherit a framebuffer at that address?
-Chris
On Sat, Aug 15, 2015 at 09:30:18AM +0100, Chris Wilson wrote: > On Fri, Aug 14, 2015 at 06:34:18PM -0300, Paulo Zanoni wrote: > > The spec says we just can't use it. > > But what about when we inherit a framebuffer at that address? Indeed. I asked the same question several times during the past attempts at this, and even tried to outline a potential solution at least once [1] Also limiting it to BDW is insufficient. CHV needs it too. [1] http://lists.freedesktop.org/archives/intel-gfx/2014-July/049924.html
On Wed, Aug 19, 2015 at 02:55:34PM +0300, Ville Syrjälä wrote: > On Sat, Aug 15, 2015 at 09:30:18AM +0100, Chris Wilson wrote: > > On Fri, Aug 14, 2015 at 06:34:18PM -0300, Paulo Zanoni wrote: > > > The spec says we just can't use it. > > > > But what about when we inherit a framebuffer at that address? > > Indeed. I asked the same question several times during the past attempts > at this, and even tried to outline a potential solution at least once [1] Paulo's only patching the insert_node_in_range allocator, for fbcon takeover we use reserve_node. I think this patch seems to do what you want it to do, no need for fancier schemes. -Daniel
On Wed, Aug 26, 2015 at 09:48:51AM +0200, Daniel Vetter wrote: > On Wed, Aug 19, 2015 at 02:55:34PM +0300, Ville Syrjälä wrote: > > On Sat, Aug 15, 2015 at 09:30:18AM +0100, Chris Wilson wrote: > > > On Fri, Aug 14, 2015 at 06:34:18PM -0300, Paulo Zanoni wrote: > > > > The spec says we just can't use it. > > > > > > But what about when we inherit a framebuffer at that address? > > > > Indeed. I asked the same question several times during the past attempts > > at this, and even tried to outline a potential solution at least once [1] > > Paulo's only patching the insert_node_in_range allocator, for fbcon > takeover we use reserve_node. I think this patch seems to do what you want > it to do, no need for fancier schemes. Hmm. Indeed. It's a somewhat surprising place to find such a check, but it does solve the preallocated vs. normal issue. It does mean we may end up with some corruption in the fbdev bo but I suppose that's short lived enough that we can ignore it. It could use a comment as to why we put the check there instead of totally removing the first page from the stolen mm. Otherwise someone might decide to clean it up and break things. Also lacking the w/a name and some explanation why it's needed. And as I mentioned before, CHV needs to be included. SKL/BXT only have it listed for early steppings, so I think we can ignore those.
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index 824334d..a292ea1 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -51,6 +51,9 @@ int i915_gem_stolen_insert_node_in_range(struct drm_i915_private *dev_priv, if (!drm_mm_initialized(&dev_priv->mm.stolen)) return -ENODEV; + if (IS_BROADWELL(dev_priv) && start < 4096) + start = 4096; + mutex_lock(&dev_priv->mm.stolen_lock); ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, node, size, alignment, start, end,
The spec says we just can't use it. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> --- drivers/gpu/drm/i915/i915_gem_stolen.c | 3 +++ 1 file changed, 3 insertions(+)