RE: [PATCH 1/2] dma-mapping: check dma_mask for streaming mapping allocs

From: David Laight
Date: Wed Feb 23 2022 - 09:57:40 EST


From: Christoph Hellwig
> Sent: 23 February 2022 14:26
>
> On Wed, Feb 23, 2022 at 08:28:13AM +0800, Baoquan He wrote:
> > Could you tell more why this is wrong? According to
> > Documentation/core-api/dma-api.rst and DMA code, __dma_alloc_pages() is
> > the core function of dma_alloc_pages()/dma_alloc_noncoherent() which are
> > obviously streaming mapping,
>
> Why are they "obviously" streaming mappings?
>
> > why do we need to check
> > dev->coherent_dma_mask here? Because dev->coherent_dma_mask is the subset
> > of dev->dma_mask, it's safer to use dev->coherent_dma_mask in these
> > places? This is confusing, I talked to Hyeonggon in private mail, he has
> > the same feeling.
>
> Think of th coherent_dma_mask as dma_alloc_mask. It is the mask for the
> DMA memory allocator. dma_mask is the mask for the dma_map_* routines.

I suspect it is all to allow for things like:
- A 64bit system with memory above 4G.
- A device that can only generate 32bit addresses.
- Some feature of the memory system (or bus bridges) that restricts
cache snooping to the low 1G of address space.

So dma_alloc_coherent() has to allocate memory below 1G.
The dma_map functions have to use bounce-buffers for addresses
above 4G.
dma_alloc_noncoherent() can allocate anything below 4G and so
avoid bounce buffers later on.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)