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

[Robin Murphy <robin.murphy@arm.com>]

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@arm.com> 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@abinsula.com>
>>>
>>> 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@pengutronix.de>
> 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@pengutronix.de>
>      Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>      Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>      Signed-off-by: Shawn Guo <shawnguo@kernel.org>
> 
> 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.