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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux