lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAJM55Z_+A1jceB5QWwZ9=roAs7jeAb7E-CEdw3mSOng=jyVDYg@mail.gmail.com> Date: Tue, 31 Oct 2023 07:56:38 -0700 From: Emil Renner Berthing <emil.renner.berthing@...onical.com> To: Andrew Lunn <andrew@...n.ch>, Cristian Ciocaltea <cristian.ciocaltea@...labora.com> Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, Emil Renner Berthing <kernel@...il.dk>, Samin Guo <samin.guo@...rfivetech.com>, Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, Alexandre Torgue <alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>, Richard Cochran <richardcochran@...il.com>, Giuseppe Cavallaro <peppe.cavallaro@...com>, netdev@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org, linux-stm32@...md-mailman.stormreply.com, linux-arm-kernel@...ts.infradead.org, kernel@...labora.com, Emil Renner Berthing <emil.renner.berthing@...onical.com> Subject: Re: [PATCH v2 08/12] riscv: dts: starfive: Add pool for coherent DMA memory on JH7100 boards Andrew Lunn wrote: > On Sun, Oct 29, 2023 at 06:27:08AM +0200, Cristian Ciocaltea wrote: > > From: Emil Renner Berthing <emil.renner.berthing@...onical.com> > > > > 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 <emil.renner.berthing@...onical.com> > > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@...labora.com> > > --- > > .../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; > > + }; > > + };
Powered by blists - more mailing lists