Re: [Linaro-mm-sig] [RFC] ARM DMA mapping TODO, v1

[Russell King - ARM Linux]

On Thu, Apr 28, 2011 at 02:28:56PM +0200, Arnd Bergmann wrote:
> On Thursday 28 April 2011, Russell King - ARM Linux wrote:
> > What I'd suggest is that dma_alloc_noncoherent() should be architecture
> > independent, and should call into whatever iommu support the device has
> > to setup an approprite iommu mapping.  IOW, I don't see any need for
> > every architecture to provide its own dma_alloc_noncoherent() allocation
> > function - or indeed every iommu implementation to deal with the
> > allocation issues either.
> 
> Almost all architectures today define dma_alloc_noncoherent to
> dma_alloc_coherent, which is totally fine on architectures
> where cacheable coherent mappings are the default or where
> we don't need to flush individual cache lines for dma_sync_*.

However, dma_alloc_coherent() memory can't be used with the dma_sync_*
API as its return address (unlike other architectures) is not in the
kernel direct mapped memory range.

The only thing valid for dma_sync_* are buffers which have been passed
to the dma_map_* APIs.

Instead, I think what you're referring to is dma_cache_sync(), which is
the API to be used with dma_alloc_noncoherent(), which we don't
implement.

As we have problems with some SMP implementations, and the noncoherent
API doesn't have the idea of buffer ownership, it's rather hard to deal
with the DMA cache implications with the existing API, especially with
the issues of speculative prefetching.  The current usage (looking at
drivers/scsi/53c700.c) doesn't cater for speculative prefetch as the
dma_cache_sync(,,,DMA_FROM_DEVICE) is done well in advance of the DMA
actually happening.

So all in all, I think the noncoherent API is broken as currently
designed - and until we have devices on ARM which use it, I don't see
much point into trying to fix the current thing especially as we'd be
unable to test.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/