Re: [PATCH] drm/etnaviv: Always init gpu->memory_base

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 26, 2016 at 04:25:13PM +0200, Marek Vasut wrote:
> The content of gpu->memory_base should point to start of RAM, not zero.
> 
> Signed-off-by: Marek Vasut <marex@xxxxxxx>
> Cc: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
> Cc: Christian Gmeiner <christian.gmeiner@xxxxxxxxx>
> Cc: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx>
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index ff6aa5d..a168532 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -588,6 +588,8 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>  			gpu->memory_base = PHYS_OFFSET;
>  		else
>  			gpu->memory_base = dma_mask - SZ_2G + 1;
> +	} else {
> +		gpu->memory_base = PHYS_OFFSET;
>  	}

The code is correct as-is.  Etnaviv GPUs are not without their own
weirdness.

For MC1.0 3D GPUs (eg, GC600 as found on Dove), there is an issue
where _most_ GPU accesses go through a memory offsetting via the
memory base, but accesses by the tiler do not: they bypass the
memory base offsetting.

We have two options to work around that:

1. Maintain two GPU address spaces, and mark relocations according
   to their use.  This is error prone: we would have to have the
   kernel verify the relocation type is valid for the load state
   address to avoid obvious security issues, and the maintanence
   of these different address spaces becomes more complex.

2. Force the address offset to zero so all GPU accesses map through
   the same method irrespective of which GPU block is performing the
   access.

We've chosen (2) because it is much simpler, and less error prone,
plus it fits with the platforms that we're aware of at the moment.
I did push for the relocations to have an additional member which
can be used to flag the type of the relocation if necessary in the
future without changing the interface structure layouts, so we do
have that option if we really need to do it - but we'd all prefer
to avoid it.

Also, iirc, the GPU tiler with MC1.0 is unable to access addresses
>= 2GiB no matter what - if you do have a 3D GPU with MC1.0, and
you have physical memory above 2GiB... there's no currently known
solution... you lose.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux