diff mbox

[1/3] drm/i915: gen 9 h/w w/a (Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset)

Message ID 1424272568-5920-2-git-send-email-nicholas.hoath@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Nick Hoath Feb. 18, 2015, 3:16 p.m. UTC
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c | 4 +++-
 drivers/gpu/drm/i915/i915_gem.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

Comments

Lespiau, Damien Feb. 18, 2015, 6:19 p.m. UTC | #1
On Wed, Feb 18, 2015 at 03:16:06PM +0000, Nick Hoath wrote:
> Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>

That looks reaaaally drastic and without explanations nor W/A
documentation that looks wrong.

Couldn't it be the virtual addresses that need to be on 32 bits? within
a 64bits PPGTT address space? Also this W/A is listed for BDW/CHV. Right
now, we have no way of telling what kind of buffer we're being asked to
relocate into the address space, so there's no way to selectively ensure
some of those buffers end up with a virtual address that remains in the
lower 4GB.
Daniel Vetter Feb. 23, 2015, 11:34 p.m. UTC | #2
On Wed, Feb 18, 2015 at 06:19:08PM +0000, Damien Lespiau wrote:
> On Wed, Feb 18, 2015 at 03:16:06PM +0000, Nick Hoath wrote:
> > Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
> 
> That looks reaaaally drastic and without explanations nor W/A
> documentation that looks wrong.
> 
> Couldn't it be the virtual addresses that need to be on 32 bits? within
> a 64bits PPGTT address space? Also this W/A is listed for BDW/CHV. Right
> now, we have no way of telling what kind of buffer we're being asked to
> relocate into the address space, so there's no way to selectively ensure
> some of those buffers end up with a virtual address that remains in the
> lower 4GB.

I915_GEM_DOMAIN_INSTRUCTION is commonly used for all indirect state by
mesa, so we could restrict the wa to objects with that reloc. Which means
that all the render/texture crap can still be relocated anywhere, which is
the majority.

Of course that means a full audit of mesa/ddx/libva to make sure we don't
break anything. And if there would be breakage we need to make 48bit
address spaces opt-in.

But yeah restricting all objects and then also applying that restriction
to physical objects is _really_ drastic. So please double-check that this
is about physical addresses and not virtual addresses.
-Daniel
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5804aa5..df9a3a5 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -748,7 +748,9 @@  int i915_driver_load(struct drm_device *dev, unsigned long flags)
 	 * behaviour if any general state is accessed within a page above 4GB,
 	 * which also needs to be handled carefully.
 	 */
-	if (IS_BROADWATER(dev) || IS_CRESTLINE(dev))
+	/* Wa32bitGeneralStateOffset:skl */
+	if (IS_BROADWATER(dev) || IS_CRESTLINE(dev) ||
+		IS_SKYLAKE(dev))
 		dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(32));
 
 	aperture_size = dev_priv->gtt.mappable_end;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dc10d86..00439b5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4430,7 +4430,9 @@  struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
 	}
 
 	mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
-	if (IS_CRESTLINE(dev) || IS_BROADWATER(dev)) {
+	/* Wa32bitInstructionBaseOffset:skl */
+	if (IS_CRESTLINE(dev) || IS_BROADWATER(dev) ||
+			IS_SKYLAKE(dev)) {
 		/* 965gm cannot relocate objects above 4GiB. */
 		mask &= ~__GFP_HIGHMEM;
 		mask |= __GFP_DMA32;