Re: More DMA API junk

[James Bottomley <James.Bottomley@SteelEye.com>]

On Mon, 2004-03-15 at 22:32, Benjamin Herrenschmidt wrote:
> So dma_cache_sync() is specifically for use on space returned
> by dma_alloc_noncoherent (and not dma_map_*).

Yes.

> So on a platform
> like mine where we use non-cacheable memory for allocating coherent
> space, we can indeed nop this one out. But then, is this also the
> case for dma_sync_single_range() which seem to be documented as
> beeing part of the "non-coherent" extension to the DMA API ? In
> which case, where is the difference between
> dma_sync_single_range() and dma_cache_sync()

dma_sync_single_range is an extension of dma_sync_single that allows you
only to do a partial sync (because on platforms like PA, syncs grow in
expense linearly with size).  So, if you're snooping data in a ten page
mapping, and you're only interested in sixteen bytes, you only need sync
those sixteen bytes. 

On your platform, dma_sync_single_range() has a defined meaning for
streaming mappings.  dma_cache_sync will be a nop, so they're not
interchangeable.

> That is confusing then. We should remove this dma_addr_t argument,
> as there is no simple way for me to tell from a physical address if
> that was mapped in kernel space as cacheable or non-cacheable.

You're confused about what it's used for.  It's designed only to be
called on memory allocated by dma_alloc_noncoherent() and tells you if
that API actually returned coherent memory or not.  This was designed
for ARM which has a limited range of allocateable coherent memory and
then would need to fail dma_alloc_coherent() or, in the case of
dma_alloc_noncoherent() begin handing out ordinary kmalloc'd memory.

James