dma-mapping: support for DMA_ATTR_NON_CONSISTENT DMA attribute
mike.looijmans at topic.nl
Sun Jun 28 23:44:50 PDT 2015
On 29-06-15 07:24, Sylvain Munaut wrote:
>> ... and then using the *streaming* API dma_sync_* calls on it. That
>> is invalid, and will lead to undefined results on implementations of
>> dma_alloc_coherent() which return remapped memory (as for older ARMs.)
>> This is an abuse of the API.
> Ok, fine, but then
> _How_ do I do it properly ? From a driver module, how do I allocate a
> large chunk ( > 4M so no alloc_pages and no kmalloc ) of contiguous
> memory that's cacheable and that I can use with the streaming API ?
To the best of my knowledge, and after asking around here, the only answer
I've so far been able to get is that alloc_pages (and hence, kmalloc) is the
method to call.
It would be nice if there were a dma_alloc_streaming() interface, which might
just translate to kalloc directly, but it would at least get rid of all the
obscurities of allocating DMA memory.
I fell into the same pit as Sylvain here, initially I was also allocating with
I submitted a patch to amend the dma documentation a while ago, but never got
a response, so I probably sent it to the wrong group.
> Or alternatively, what are the correct "sync points" that the doc refers to ?
> """ By using this API, you are guaranteeing to the platform that you
> have all the correct and necessary sync points for this memory in the
> driver should it choose to return non-consistent memory."""
> I had assumed it was the dma_sync_* calls, but apparently not.
I think the answer is "the dma_sync_* calls plus whatever it is your DMA
controller hardware needs to do"
If that's the case, where should I send the documentation patch?
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans at topicproducts.com
Please consider the environment before printing this e-mail
More information about the linux-arm-kernel