On Wed, Feb 18, 2015 at 03:16:06PM +0000, Nick Hoath wrote:
> Signed-off-by: Nick Hoath <nicholas.hoath@xxxxxxxxx>
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.
--
Damien
> ---
> drivers/gpu/drm/i915/i915_dma.c | 4 +++-
> drivers/gpu/drm/i915/i915_gem.c | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> 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;
> --
> 2.1.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
