From: Emil Renner Berthing <[email protected]>
The StarFive JH7100 SoC has non-coherent device DMAs, but most drivers
expect to be able to allocate coherent memory for DMA descriptors and
such. However on the JH7100 DDR memory appears twice in the physical
memory map, once cached and once uncached:
0x00_8000_0000 - 0x08_7fff_ffff : Off chip DDR memory, cached
0x10_0000_0000 - 0x17_ffff_ffff : Off chip DDR memory, uncached
To use this uncached region we create a global DMA memory pool there and
reserve the corresponding area in the cached region.
However the uncached region is fully above the 32bit address limit, so add
a dma-ranges map so the DMA address used for peripherals is still in the
regular cached region below the limit.
Link: https://github.com/starfive-tech/JH7100_Docs/blob/main/JH7100%20Data%20Sheet%20V01.01.04-EN%20(4-21-2021).pdf
Signed-off-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
.../boot/dts/starfive/jh7100-common.dtsi | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
index b93ce351a90f..504c73f01f14 100644
--- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
@@ -39,6 +39,30 @@ led-ack {
label = "ack";
};
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ dma-reserved {
+ reg = <0x0 0xfa000000 0x0 0x1000000>;
+ no-map;
+ };
+
+ linux,dma {
+ compatible = "shared-dma-pool";
+ reg = <0x10 0x7a000000 0x0 0x1000000>;
+ no-map;
+ linux,dma-default;
+ };
+ };
+
+ soc {
+ dma-ranges = <0x00 0x80000000 0x00 0x80000000 0x00 0x7a000000>,
+ <0x00 0xfa000000 0x10 0x7a000000 0x00 0x01000000>,
+ <0x00 0xfb000000 0x00 0xfb000000 0x07 0x85000000>;
+ };
};
&gpio {
--
2.42.0
On Sun, Oct 29, 2023 at 06:27:08AM +0200, Cristian Ciocaltea wrote:
> From: Emil Renner Berthing <[email protected]>
>
> The StarFive JH7100 SoC has non-coherent device DMAs, but most drivers
> expect to be able to allocate coherent memory for DMA descriptors and
> such. However on the JH7100 DDR memory appears twice in the physical
> memory map, once cached and once uncached:
>
> 0x00_8000_0000 - 0x08_7fff_ffff : Off chip DDR memory, cached
> 0x10_0000_0000 - 0x17_ffff_ffff : Off chip DDR memory, uncached
>
> To use this uncached region we create a global DMA memory pool there and
> reserve the corresponding area in the cached region.
>
> However the uncached region is fully above the 32bit address limit, so add
> a dma-ranges map so the DMA address used for peripherals is still in the
> regular cached region below the limit.
>
> Link: https://github.com/starfive-tech/JH7100_Docs/blob/main/JH7100%20Data%20Sheet%20V01.01.04-EN%20(4-21-2021).pdf
> Signed-off-by: Emil Renner Berthing <[email protected]>
> Signed-off-by: Cristian Ciocaltea <[email protected]>
> ---
> .../boot/dts/starfive/jh7100-common.dtsi | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> index b93ce351a90f..504c73f01f14 100644
> --- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> @@ -39,6 +39,30 @@ led-ack {
> label = "ack";
> };
> };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + dma-reserved {
> + reg = <0x0 0xfa000000 0x0 0x1000000>;
If i'm reading this correctly, this is at the top of the first 4G of
RAM. But this is jh7100-common.dtsi. Is it guaranteed that all boards
derived from this have at least 4G? What happens is a board only has
2G?
It might also be worth putting a comment here about the memory being
mapped twice. In the ARM world that would be illegal, so its maybe not
seen that often. Yes, the commit message explains that, but when i
look at the code on its own, it is less obvious.
> + no-map;
> + };
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + reg = <0x10 0x7a000000 0x0 0x1000000>;
> + no-map;
> + linux,dma-default;
> + };
> + };
Cristian Ciocaltea wrote:
> From: Emil Renner Berthing <[email protected]>
>
> The StarFive JH7100 SoC has non-coherent device DMAs, but most drivers
> expect to be able to allocate coherent memory for DMA descriptors and
> such. However on the JH7100 DDR memory appears twice in the physical
> memory map, once cached and once uncached:
>
> 0x00_8000_0000 - 0x08_7fff_ffff : Off chip DDR memory, cached
> 0x10_0000_0000 - 0x17_ffff_ffff : Off chip DDR memory, uncached
>
> To use this uncached region we create a global DMA memory pool there and
> reserve the corresponding area in the cached region.
>
> However the uncached region is fully above the 32bit address limit, so add
> a dma-ranges map so the DMA address used for peripherals is still in the
> regular cached region below the limit.
Adding these nodes to the device tree won't actually do anything without
enabling CONFIG_DMA_GLOBAL_POOL as is done here:
https://github.com/esmil/linux/commit/e14ad9ff67fd51dcc76415d4cc7f3a30ffcba379
>
> Link: https://github.com/starfive-tech/JH7100_Docs/blob/main/JH7100%20Data%20Sheet%20V01.01.04-EN%20(4-21-2021).pdf
> Signed-off-by: Emil Renner Berthing <[email protected]>
> Signed-off-by: Cristian Ciocaltea <[email protected]>
> ---
> .../boot/dts/starfive/jh7100-common.dtsi | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> index b93ce351a90f..504c73f01f14 100644
> --- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> @@ -39,6 +39,30 @@ led-ack {
> label = "ack";
> };
> };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + dma-reserved {
> + reg = <0x0 0xfa000000 0x0 0x1000000>;
> + no-map;
> + };
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + reg = <0x10 0x7a000000 0x0 0x1000000>;
> + no-map;
> + linux,dma-default;
> + };
> + };
> +
> + soc {
> + dma-ranges = <0x00 0x80000000 0x00 0x80000000 0x00 0x7a000000>,
> + <0x00 0xfa000000 0x10 0x7a000000 0x00 0x01000000>,
> + <0x00 0xfb000000 0x00 0xfb000000 0x07 0x85000000>;
> + };
> };
>
> &gpio {
> --
> 2.42.0
>
Andrew Lunn wrote:
> On Sun, Oct 29, 2023 at 06:27:08AM +0200, Cristian Ciocaltea wrote:
> > From: Emil Renner Berthing <[email protected]>
> >
> > The StarFive JH7100 SoC has non-coherent device DMAs, but most drivers
> > expect to be able to allocate coherent memory for DMA descriptors and
> > such. However on the JH7100 DDR memory appears twice in the physical
> > memory map, once cached and once uncached:
> >
> > 0x00_8000_0000 - 0x08_7fff_ffff : Off chip DDR memory, cached
> > 0x10_0000_0000 - 0x17_ffff_ffff : Off chip DDR memory, uncached
> >
> > To use this uncached region we create a global DMA memory pool there and
> > reserve the corresponding area in the cached region.
> >
> > However the uncached region is fully above the 32bit address limit, so add
> > a dma-ranges map so the DMA address used for peripherals is still in the
> > regular cached region below the limit.
> >
> > Link: https://github.com/starfive-tech/JH7100_Docs/blob/main/JH7100%20Data%20Sheet%20V01.01.04-EN%20(4-21-2021).pdf
> > Signed-off-by: Emil Renner Berthing <[email protected]>
> > Signed-off-by: Cristian Ciocaltea <[email protected]>
> > ---
> > .../boot/dts/starfive/jh7100-common.dtsi | 24 +++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > index b93ce351a90f..504c73f01f14 100644
> > --- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > +++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > @@ -39,6 +39,30 @@ led-ack {
> > label = "ack";
> > };
> > };
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + dma-reserved {
> > + reg = <0x0 0xfa000000 0x0 0x1000000>;
>
> If i'm reading this correctly, this is at the top of the first 4G of
> RAM. But this is jh7100-common.dtsi. Is it guaranteed that all boards
> derived from this have at least 4G? What happens is a board only has
> 2G?
Yes, both the BeagleV Starlight and StarFive VisionFive V1 boards have at least
4G of ram and there won't be any more boards with this SoC. It was a test chip
for the JH7110 after all.
There aren't really any limitations on where this pool could be placed, so I
just chose to wedge it between ranges reserved for graphics by the bootloader.
If anyone has a better idea please go ahead and change it.
>
> It might also be worth putting a comment here about the memory being
> mapped twice. In the ARM world that would be illegal, so its maybe not
> seen that often. Yes, the commit message explains that, but when i
> look at the code on its own, it is less obvious.
>
> > + no-map;
> > + };
> > +
> > + linux,dma {
> > + compatible = "shared-dma-pool";
> > + reg = <0x10 0x7a000000 0x0 0x1000000>;
> > + no-map;
> > + linux,dma-default;
> > + };
> > + };
On 10/31/23 16:40, Emil Renner Berthing wrote:
> Cristian Ciocaltea wrote:
>> From: Emil Renner Berthing <[email protected]>
>>
>> The StarFive JH7100 SoC has non-coherent device DMAs, but most drivers
>> expect to be able to allocate coherent memory for DMA descriptors and
>> such. However on the JH7100 DDR memory appears twice in the physical
>> memory map, once cached and once uncached:
>>
>> 0x00_8000_0000 - 0x08_7fff_ffff : Off chip DDR memory, cached
>> 0x10_0000_0000 - 0x17_ffff_ffff : Off chip DDR memory, uncached
>>
>> To use this uncached region we create a global DMA memory pool there and
>> reserve the corresponding area in the cached region.
>>
>> However the uncached region is fully above the 32bit address limit, so add
>> a dma-ranges map so the DMA address used for peripherals is still in the
>> regular cached region below the limit.
>
> Adding these nodes to the device tree won't actually do anything without
> enabling CONFIG_DMA_GLOBAL_POOL as is done here:
>
> https://github.com/esmil/linux/commit/e14ad9ff67fd51dcc76415d4cc7f3a30ffcba379
Should I pick this up for v3 or maybe it would be better to be handled
as part of your ccache series?
Thanks,
Cristian
>>
>> Link: https://github.com/starfive-tech/JH7100_Docs/blob/main/JH7100%20Data%20Sheet%20V01.01.04-EN%20(4-21-2021).pdf
>> Signed-off-by: Emil Renner Berthing <[email protected]>
>> Signed-off-by: Cristian Ciocaltea <[email protected]>
>> ---
>> .../boot/dts/starfive/jh7100-common.dtsi | 24 +++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
>> index b93ce351a90f..504c73f01f14 100644
>> --- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
>> +++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
>> @@ -39,6 +39,30 @@ led-ack {
>> label = "ack";
>> };
>> };
>> +
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + dma-reserved {
>> + reg = <0x0 0xfa000000 0x0 0x1000000>;
>> + no-map;
>> + };
>> +
>> + linux,dma {
>> + compatible = "shared-dma-pool";
>> + reg = <0x10 0x7a000000 0x0 0x1000000>;
>> + no-map;
>> + linux,dma-default;
>> + };
>> + };
>> +
>> + soc {
>> + dma-ranges = <0x00 0x80000000 0x00 0x80000000 0x00 0x7a000000>,
>> + <0x00 0xfa000000 0x10 0x7a000000 0x00 0x01000000>,
>> + <0x00 0xfb000000 0x00 0xfb000000 0x07 0x85000000>;
>> + };
>> };
>>
>> &gpio {
>> --
>> 2.42.0
>>