On Wed, Mar 6, 2024, at 15:19, Andreas Larsson wrote:
> On 2024-03-05 16:26, Arnd Bergmann wrote:
>> On Tue, Mar 5, 2024, at 16:06, Andreas Larsson wrote:
>>> On 2024-02-24 18:42, Sam Ravnborg via B4 Relay wrote:
>>
>>>> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
>>>> index 734f23daecca..bdbde506c01e 100644
>>>> --- a/arch/sparc/Kconfig
>>>> +++ b/arch/sparc/Kconfig
>>>> @@ -62,7 +62,6 @@ config SPARC32
>>>> select HAVE_UID16
>>>> select LOCK_MM_AND_FIND_VMA
>>>> select OLD_SIGACTION
>>>> - select ZONE_DMA
>>>
>>> This however makes a number of PCI drivers that depend on
>>> ZONE_DMA unselectable.
>>
>> I think that is the correct thing to do then: the only
>> drivers that I see with this dependency are PCI sound cards
>> that apparently rely on DMA to the 16MB ISA range, which is
>> not provided by sparc.
>
> The ZONE_DMA dependency does not seem related to ISA per se. Commit
> 80ab8eae70e5 ("ALSA: Enable CONFIG_ZONE_DMA for smaller PCI DMA masks")
> that started to introduce it did were about ensuring 32-bit masks.
>
> Some of those sound card drivers sets a 24 bit mask, i.e. a 0-16MB
> range, but some among those sets a 28, and 30 bit DMA mask with
> dma_set_mask_and_coherent.
Ah right, I see it now.
> Testing, in a different driver, setting and
> allocating under a 30-bit DMA mask (or even a 28-bit DMA mask depending
> on where the physical memory resides) is possible before removing
> ZONE_DMA, but not after.
I still don't see how that changes anything if
max_zone_pfn[ZONE_DMA] and max_zone_pfn[ZONE_NORMAL] are set
to the same value. Did you test this on a mainline kernel, or
do you have any patches on top that might have set up
the zones differently?
More specifically, what do you see in the boot log for the
size of each zone?
> I am also a bit concerned if removing ZONE_DMA will let DMA be allocated
> in highmem and what that could lead to.
It's not supposed to make a difference, but this is a bit
more complex:
- Any kernel allocation (kmalloc etc) by definition comes from
lowmem, regardless of GFP_DMA/GFP_KERNEL.
- user pages that get mapped using dma_map_sg() or dma_map_page()
can be in highmem, but this should not depend on the presence
of ZONE_DMA
- If you have devices that can only access a subset of the RAM
and there is no IOMMU, you really need to use swiotlb to
make it use bounce buffers, at least for the streaming
(dma_map_*) API. A driver using only the coherent (dma_alloc_*)
API should use ZONE_DMA if ZONE_NORMAL goes beyond the
dma mask.
Arnd
