Re: [PATCH v6 RESED 1/2] dma: replace zone_dma_bits by zone_dma_limit

[Robin Murphy]

On 2024-08-29 2:42 pm, Neil Armstrong wrote:
> Hi,
>
> On 11/08/2024 09:09, Baruch Siach wrote:
> > From: Catalin Marinas <catalin.marinas@xxxxxxx>
> >
> > Hardware DMA limit might not be power of 2. When RAM range starts above
> > 0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
> > can not encode this limit.
> >
> > Use plain address for DMA zone limit.
> >
> > Since DMA zone can now potentially span beyond 4GB physical limit of
> > DMA32, make sure to use DMA zone for GFP_DMA32 allocations in that case.
> >
> > Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx>
> > Co-developed-by: Baruch Siach <baruch@xxxxxxxxxx>
> > Signed-off-by: Baruch Siach <baruch@xxxxxxxxxx>
> > ---
> >   arch/arm64/mm/init.c       | 30 +++++++++++++++---------------
> >   arch/powerpc/mm/mem.c      |  5 ++++-
> >   arch/s390/mm/init.c        |  2 +-
> >   include/linux/dma-direct.h |  2 +-
> >   kernel/dma/direct.c        |  6 +++---
> >   kernel/dma/pool.c          |  4 ++--
> >   kernel/dma/swiotlb.c       |  6 +++---
> >   7 files changed, 29 insertions(+), 26 deletions(-)
>
> <snip>
>
> This change breaks the Qualcomm SM8550-HDK boot since next-20240826.
> It doesn't affect SM8550-QRD or other similar SoCs like SM8650 or SM8450.
> The last CI run on next-20240828 can be found at:
> https://git.codelinaro.org/linaro/qcomlt/ci/staging/cdba-tester/-/pipelines/100936
>
> SM8550-HDK boot log:
> https://git.codelinaro.org/linaro/qcomlt/ci/staging/cdba-tester/-/jobs/165617
[...]

Yeah, a 35-bit ZONE_DMA is sure to make stuff go wrong:

> [    0.000000] Zone ranges:
> [    0.000000]   DMA      [mem 0x0000000080000000-0x0000000affffffff]
> [    0.000000]   DMA32    empty
> [    0.000000]   Normal   empty

Compared to before:

[    0.000000]   DMA      [mem 0x0000000080000000-0x00000000ffffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000000100000000-0x0000000affffffff]

This'll be because the SoC DT is describing a general non-restrictive range:
		dma-ranges = <0 0 0 0 0x10 0>;

Which proves we need more information than 
{acpi,of}_dma_get_max_cpu_address() are currently able to give us, 
because what zone_dma_limit actually wants to be is the *minimum* of the 
lowest highest CPU address of any DMA range, and the lowest CPU address 
of any DMA range + 2^32. I was thinking it had all ended up looking a 
bit too easy... :)

I think v1 of the fix[1] might actually work out for this, albeit still 
for the wrong reasons - if so, I concede that maybe at this point it 
might be safest to go back to that one as a quick short-term fix (with a 
big fat comment to say so) rather than try to rush the proper solution 
or revert everything.

Thanks,
Robin.

[1] 
https://lore.kernel.org/linux-arm-kernel/731d204f5f556ad61bbaf004b1d984f83c90b4f5.1724748249.git.baruch@xxxxxxxxxx/