With the introduction of the Raspberry Pi 4 we were forced to explicitly
configure CMA's location, since arm64 defaults it into the ZONE_DMA32
memory area, which is not good enough to perform DMA operations on that
device. To bypass this limitation a dedicated CMA DT node was created,
explicitly indicating the acceptable memory range and size.
That said, compatibility between boards is a must on the Raspberry Pi
ecosystem so this creates a common CMA DT node so as for DT overlays to
be able to update CMA's properties regardless of the board being used.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
---
If this doesn't make it into v5.5 I'd be tempted to add:
Fixes: d98a8dbdaec6 ("ARM: dts: bcm2711: force CMA into first GB of memory")
arch/arm/boot/dts/bcm2711.dtsi | 33 +++++++++++++--------------------
arch/arm/boot/dts/bcm283x.dtsi | 13 +++++++++++++
2 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
index 8687534d4528..c8e4041308e0 100644
--- a/arch/arm/boot/dts/bcm2711.dtsi
+++ b/arch/arm/boot/dts/bcm2711.dtsi
@@ -12,26 +12,6 @@ / {
interrupt-parent = <&gicv2>;
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <1>;
- ranges;
-
- /*
- * arm64 reserves the CMA by default somewhere in ZONE_DMA32,
- * that's not good enough for the BCM2711 as some devices can
- * only address the lower 1G of memory (ZONE_DMA).
- */
- linux,cma {
- compatible = "shared-dma-pool";
- size = <0x2000000>; /* 32MB */
- alloc-ranges = <0x0 0x00000000 0x40000000>;
- reusable;
- linux,cma-default;
- };
- };
-
-
soc {
/*
* Defined ranges:
@@ -869,6 +849,19 @@ pin-rts {
};
};
+&rmem {
+ #address-cells = <2>;
+};
+
+&cma {
+ /*
+ * arm64 reserves the CMA by default somewhere in ZONE_DMA32,
+ * that's not good enough for the BCM2711 as some devices can
+ * only address the lower 1G of memory (ZONE_DMA).
+ */
+ alloc-ranges = <0x0 0x00000000 0x40000000>;
+};
+
&i2c0 {
compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c";
interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 839491628e87..6128baed83c2 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -30,6 +30,19 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ rmem: reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ cma: linux,cma {
+ compatible = "shared-dma-pool";
+ size = <0x4000000>; /* 64MB */
+ reusable;
+ linux,cma-default;
+ };
+ };
+
thermal-zones {
cpu_thermal: cpu-thermal {
polling-delay-passive = <0>;
--
2.24.1
Hi Nicolas,
On 10/01/2020 17:29, Nicolas Saenz Julienne wrote:
> With the introduction of the Raspberry Pi 4 we were forced to explicitly
> configure CMA's location, since arm64 defaults it into the ZONE_DMA32
> memory area, which is not good enough to perform DMA operations on that
> device. To bypass this limitation a dedicated CMA DT node was created,
> explicitly indicating the acceptable memory range and size.
>
> That said, compatibility between boards is a must on the Raspberry Pi
> ecosystem so this creates a common CMA DT node so as for DT overlays to
> be able to update CMA's properties regardless of the board being used.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
> ---
>
> If this doesn't make it into v5.5 I'd be tempted to add:
> Fixes: d98a8dbdaec6 ("ARM: dts: bcm2711: force CMA into first GB of memory")
>
> arch/arm/boot/dts/bcm2711.dtsi | 33 +++++++++++++--------------------
> arch/arm/boot/dts/bcm283x.dtsi | 13 +++++++++++++
> 2 files changed, 26 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> index 8687534d4528..c8e4041308e0 100644
> --- a/arch/arm/boot/dts/bcm2711.dtsi
> +++ b/arch/arm/boot/dts/bcm2711.dtsi
> @@ -12,26 +12,6 @@ / {
>
> interrupt-parent = <&gicv2>;
>
> - reserved-memory {
> - #address-cells = <2>;
> - #size-cells = <1>;
> - ranges;
> -
> - /*
> - * arm64 reserves the CMA by default somewhere in ZONE_DMA32,
> - * that's not good enough for the BCM2711 as some devices can
> - * only address the lower 1G of memory (ZONE_DMA).
> - */
> - linux,cma {
> - compatible = "shared-dma-pool";
> - size = <0x2000000>; /* 32MB */
> - alloc-ranges = <0x0 0x00000000 0x40000000>;
> - reusable;
> - linux,cma-default;
> - };
> - };
> -
> -
> soc {
> /*
> * Defined ranges:
> @@ -869,6 +849,19 @@ pin-rts {
> };
> };
>
> +&rmem {
> + #address-cells = <2>;
> +};
> +
> +&cma {
> + /*
> + * arm64 reserves the CMA by default somewhere in ZONE_DMA32,
> + * that's not good enough for the BCM2711 as some devices can
> + * only address the lower 1G of memory (ZONE_DMA).
> + */
> + alloc-ranges = <0x0 0x00000000 0x40000000>;
> +};
> +
> &i2c0 {
> compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c";
> interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> index 839491628e87..6128baed83c2 100644
> --- a/arch/arm/boot/dts/bcm283x.dtsi
> +++ b/arch/arm/boot/dts/bcm283x.dtsi
> @@ -30,6 +30,19 @@ chosen {
> stdout-path = "serial0:115200n8";
> };
>
> + rmem: reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + cma: linux,cma {
> + compatible = "shared-dma-pool";
> + size = <0x4000000>; /* 64MB */
> + reusable;
> + linux,cma-default;
> + };
> + };
> +
> thermal-zones {
> cpu_thermal: cpu-thermal {
> polling-delay-passive = <0>;
>
For what it's worth,
Reviewed-by: Phil Elwell <[email protected]>
Phil
On Fri, 10 Jan 2020 18:29:35 +0100, Nicolas Saenz Julienne <[email protected]> wrote:
> With the introduction of the Raspberry Pi 4 we were forced to explicitly
> configure CMA's location, since arm64 defaults it into the ZONE_DMA32
> memory area, which is not good enough to perform DMA operations on that
> device. To bypass this limitation a dedicated CMA DT node was created,
> explicitly indicating the acceptable memory range and size.
>
> That said, compatibility between boards is a must on the Raspberry Pi
> ecosystem so this creates a common CMA DT node so as for DT overlays to
> be able to update CMA's properties regardless of the board being used.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
> ---
Applied to devicetree/next, thanks!
--
Florian