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.
Well, on non-coherent architectures, dma_sync_* are cache flushes, I don't see the point of doing those on a non-cachable mapping anyways.
The only thing valid for dma_sync_* are buffers which have been passed to the dma_map_* APIs.
Right, at least that's our expectation on powerpc as well.
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.
Too may confusing APIs....
Ben.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/