[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOf5uwk=bafBt2HCTzWs8R0wYS9r1G9uXV92Bx2CK7tMsP-Szw@mail.gmail.com>
Date: Wed, 19 Jun 2024 15:21:52 +0200
From: Michael Nazzareno Trimarchi <michael@...rulasolutions.com>
To: Robin Murphy <robin.murphy@....com>
Cc: Alberto Secondi <albertosecondi@...il.com>, hch@....de, m.szyprowski@...sung.com,
iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
alberto.secondi@...nsula.com, Davide Salaris <davide.salaris@...nsula.com>
Subject: Re: [PATCH] New config added to handle 64-bit systems with 32-bit DMA support
Hi Robin
On Wed, Jun 19, 2024 at 2:46 PM Robin Murphy <robin.murphy@....com> wrote:
>
>
> 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@....com> wrote:
> >>
> >> On 2024-06-19 10:17 am, Alberto Secondi wrote:
> >>> ------ Tessian Warning ------
> >>>
> >>> Be careful, the email's sending address "albertosecondi@...il[.]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@...nsula.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@...gutronix.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@...gutronix.de>
> > Reviewed-by: Frieder Schrempf <frieder.schrempf@...tron.de>
> > Tested-by: Frieder Schrempf <frieder.schrempf@...tron.de>
> > Signed-off-by: Shawn Guo <shawnguo@...nel.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.
>
The patch does not include what kernel version was tested. After we
have this answer that
we can know
Michael
> Thanks,
> Robin.
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@...rulasolutions.com
__________________________________
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@...rulasolutions.com
www.amarulasolutions.com
Powered by blists - more mailing lists