diff mbox series

arm64: dts: fast models: Switch to dynamically allocated VRAM

Message ID 20200423234903.226369-1-pcc@google.com (mailing list archive)
State New, archived
Headers show
Series arm64: dts: fast models: Switch to dynamically allocated VRAM | expand

Commit Message

Peter Collingbourne April 23, 2020, 11:49 p.m. UTC
According to the Fast Models Reference Manual, FVP has 32MB of video
RAM, However, even 32MB is not sufficient for some applications,
such as Android, which requires around 100-200MB when textures are
allocated in VRAM via DRM.

FVP supports DMA between DRAM and the graphics device. Therefore,
use a dynamically allocated region of reserved memory to provide
a sufficient amount of video RAM. The allocation is of size 256MB,
which ought to be enough for anyone.

Although this means that the designated VRAM ends up being left unused,
FVP allows the size of DRAM to be configurable, so this should not
be a problem in practice.

Signed-off-by: Peter Collingbourne <pcc@google.com>
---
 arch/arm64/boot/dts/arm/fvp-base-revc.dts | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

Comments

Sudeep Holla April 24, 2020, 1:20 p.m. UTC | #1
On Thu, Apr 23, 2020 at 04:49:03PM -0700, Peter Collingbourne wrote:
> According to the Fast Models Reference Manual, FVP has 32MB of video
> RAM, However, even 32MB is not sufficient for some applications,
> such as Android, which requires around 100-200MB when textures are
> allocated in VRAM via DRM.
>
> FVP supports DMA between DRAM and the graphics device. Therefore,
> use a dynamically allocated region of reserved memory to provide
> a sufficient amount of video RAM. The allocation is of size 256MB,
> which ought to be enough for anyone.
>
> Although this means that the designated VRAM ends up being left unused,
> FVP allows the size of DRAM to be configurable, so this should not
> be a problem in practice.
>
> Signed-off-by: Peter Collingbourne <pcc@google.com>
> ---
>  arch/arm64/boot/dts/arm/fvp-base-revc.dts | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> index 66381d89c1ce..57641f16f22e 100644
> --- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> +++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> @@ -103,11 +103,9 @@ reserved-memory {
>  		#size-cells = <2>;
>  		ranges;
>
> -		/* Chipselect 2,00000000 is physically at 0x18000000 */
> -		vram: vram@18000000 {
> -			/* 8 MB of designated video RAM */
> +		vram: vram {
>  			compatible = "shared-dma-pool";
> -			reg = <0x00000000 0x18000000 0 0x00800000>;

I am not sure if it is valid to just specify the size without the reg
field. The reverse is valid IIUC. Moreover I assume the idea is to populate
the reg field based on the model parameters ? If so, who can't the reg
and size field be modified instead of deleting here and adding it elsewhere.

--
Regards,
Sudeep
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
index 66381d89c1ce..57641f16f22e 100644
--- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
+++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
@@ -103,11 +103,9 @@  reserved-memory {
 		#size-cells = <2>;
 		ranges;
 
-		/* Chipselect 2,00000000 is physically at 0x18000000 */
-		vram: vram@18000000 {
-			/* 8 MB of designated video RAM */
+		vram: vram {
 			compatible = "shared-dma-pool";
-			reg = <0x00000000 0x18000000 0 0x00800000>;
+			size = <0 0x10000000>;
 			no-map;
 		};
 	};