On Thu, May 28, 2015 at 04:24:47PM +0100, Michel Thierry wrote:
> We already set this limit for the GGTT.
> 
> This is a temporary patch until a full replacement of size_t variables
> (inadequate in 32-bit kernel) is in place.
> 
> Regression from:
>       commit a4e0bedca678c81eea4cd79a4bd502335639f73a
>       Author: Michel Thierry <[email protected]>
>       Date:   Wed Apr 8 12:13:35 2015 +0100
> 
>               drm/i915: Use complete address space in true PPGTT
> 
> Suggested-by: Daniel Vetter <[email protected]>
> Cc: Mika Kuoppala <[email protected]>
> Signed-off-by: Michel Thierry <[email protected]>
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 17b7df0..ffecb87 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -951,7 +951,15 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
>       gen8_initialize_pd(&ppgtt->base, ppgtt->scratch_pd);
>  
>       ppgtt->base.start = 0;
> +
> +#ifdef CONFIG_X86_32
> +     /* Limit 32b platforms to GGTT size (2GB) */

Forgot the comment about why the limit is inplace and when it can be
lifted. Remember comments are for *why* not *what*.

> +     struct drm_i915_private *dev_priv = ppgtt->base.dev->dev_private;

Fancy new fangled C.

> +     ppgtt->base.total = dev_priv->gtt.base.total;
        ppgtt->base.total = to_i915(ppgtt->base.dev)->gtt.base.total;

> +#else
>       ppgtt->base.total = 1ULL << 32;
> +#endif

Better yet would be:
        ppgtt->base.total = 1ULL << 32;
        if (IS_ENABLED(CONFIG_X86_32)) {
                /* While we have a proliferation of size_t variables
                 * we cannot represent the full ppgtt size on 32bit,
                 * so limit it to the same size as the GGTT (currently
                 * 2GiB).
                 */
                 ppgtt->base.total = to_i915(ppgtt->base.dev)->gtt.base.total;
        }

However, I am afraid that it will become obsolete but be forgotten to be
removed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to