Re: [PATCH] New config added to handle 64-bit systems with 32-bit DMA support

[Robin Murphy]

On 2024-06-19 12:43 pm, Michael Nazzareno Trimarchi wrote:
> Hi Robin
>
> On Wed, Jun 19, 2024 at 12:36 PM Robin Murphy <robin.murphy@xxxxxxx> wrote:
> > On 2024-06-19 10:17 am, Alberto Secondi wrote:
> > > ------ Tessian Warning ------
> > >
> > > Be careful, the email's sending address "albertosecondi@gmail[.]com" has never been seen on your company's network before today
> > >
> > > This warning message will be removed if you reply to or forward this email to a recipient outside of your organization.
> > >
> > > ---- Tessian Warning End ----
> > >
> > > From: Alberto Secondi <alberto.secondi@xxxxxxxxxxxx>
> > >
> > > The kernel assumes that 64-bit systems have 64-bit DMA support through
> > > CONFIG_ARCH_DMA_ADDR_T_64BIT. This is not always true; for example, several
> > > iMX8 systems (verified on iMX8MM and iMX8MP) have DMA with only 32-bit support.
> > > This results in several drivers requesting DMA_BIT_MASK(64), which causes
> > > malfunctions, particularly when systems have more than 3GB of DRAM (verified
> > > with the lan743x driver and iMX8 systems with 4GB of DRAM). Therefore, a new
> > > config ARCH_64BIT_HAS_DMA32_ONLY was added to manage 64-bit systems with 32-bit
> > > DMA, which adjusts DMA_BIT_MASK(n) accordingly.
> >
> > No. If a system has devices naturally capable of >32-bit DMA, and memory
> > at >32-bit system physical addresses, but only a 32-bit interconnect in
> > between, that needs to be described properly in Devicetree/ACPI, not
> > hacked around with completely non-portable kernel bodges.
>
> commit 4251a3ac4de9625a284a9c046cc915487e9b2a5e
> Author: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
> Date:   Tue May 4 10:20:51 2021 +0200
>
>      arm64: dts: imx8mm: specify dma-ranges
>
>      DMA addressing capabilities on i.MX8MM are limited by the interconnect,
>      same as on i.MX8MQ. Add dma-ranges to the the peripheral bus to let
>      the kernel know about this.
>
>      Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
>      Reviewed-by: Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>
>      Tested-by: Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>
>      Signed-off-by: Shawn Guo <shawnguo@xxxxxxxxxx>
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index 64aa38fd2b6e0..e7648c3b83905 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -261,6 +261,7 @@ soc@0 {
>                  #address-cells = <1>;
>                  #size-cells = <1>;
>                  ranges = <0x0 0x0 0x0 0x3e000000>;
> +               dma-ranges = <0x40000000 0x0 0x40000000 0xc0000000>;
>                  nvmem-cells = <&imx8mm_uid>;
>                  nvmem-cell-names = "soc_unique_id";
>
>
> Somenthing like this should already do it?

Hmm, indeed... so the question to dig into would be why that's 
apparently not getting picked up by of_dma_get_range() for that device.

Thanks,
Robin.