Hi Catalin, thanks for taking the time. On Tue, 2020-09-08 at 12:14 +0100, Catalin Marinas wrote: > > Also note the usage of 'zone_dma_bits' in the DMA code, which assumes that > > ZONE_DMA's physical address space is always smaller than (1 << > > zone_dma_bits) - > > 1. > > I think part of those uses are broken. dma_direct_supported() does the > right thing and uses the DMA address instead of the physical one. Here > __phys_to_dma() subtracts the dma_pfn_offset, which in my above example > would be (0b10 << (30 - PAGE_SHIFT)). > > dma_direct_optimal_gfp_mask(), OTOH, seems to start ok with a > __dma_to_phys() on the dma_limit but it ends up comparing the physical > address with the DMA mask. This gives the wrong result on arm64 > platforms where RAM starts above 4GB and still expect a ZONE_DMA32. It > should compare *phys_limit with __dma_to_phys(DMA_BIT_MASK(...)). I > guess it ends up bouncing via swiotlb more often.
I'll look into this.
> We assumed such offsets on arm64 since commit d50314a6b070 ("arm64:
> Create non-empty ZONE_DMA when DRAM starts above 4GB").
>
> > > An alternative (and I think we had a patch at some point) is to make it
> > > generic and parse the dma-range in the DT to identify the minimum mask
> > > and set ZONE_DMA accordingly. But this doesn't solve ACPI, so if Linux
> > > can boot with ACPI on RPi4 it would still be broken.
> >
> > ACPI is being worked on by, among others, Jeremy Linton (one of your
> > colleagues
> > I believe).
> >
> > We could always use sane defaults for ACPI and be smarter with DT. Yet,
> > implementing this entails translating nested dma-ranges with the only help
> > of
> > libfdt, which isn't trivial (see devices/of/address.c). IIRC RobH said that
> > it
> > wasn't worth the effort just for a board.
>
> That would have been the ideal, more generic solution. But I agree that
> it's not worth the effort if the only SoC affected is RPi4.
>
> To summarise, I'd like ZONE_DMA to overlap with ZONE_DMA32 (i.e. expand
> zone_dma_bits to 32 and drop ZONE_DMA32) for all SoCs other than RPi4.
> The solutions so far:
>
> 1. Assume that, if RAM starts at 0, we need a zone_dma_bits == 30. This
> also assumes that it's only RPi4 in this category or that any such
> future SoC has a need for 30-bit DMA.
>
> 2. Adjust zone_dma_bits at boot-time only if the SoC is RPi4.
>
> 3. Use the more complex dma-ranges approach to calculate the correct
> zone_dma_bits as a minimum of all dma masks in the DT.
>
> We can discount (3) as not worth the effort. I'd go with (1) (this
> patch) if we can guarantee that no current or future SoC has RAM
> starting at 0 while not needing 30-bit DMA masks. If not, we can go with
> (2) unless others have a better suggestion.
After a quick check at the devices we have for testing at suse it's clear that
(1) is impossible. So I'll push for solution (2).
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
