On Mon, Dec 05, 2011 at 05:18:48PM +0000, Arnd Bergmann wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
- /* allow allocator to take care of cache ops */
- void (*sync_sg_for_cpu) (struct dma_buf *, struct device *);
- void (*sync_sg_for_device)(struct dma_buf *, struct device *);
I don't see how this works with multiple consumers: For the streaming DMA mapping, there must be exactly one owner, either the device or the CPU. Obviously, this rule needs to be extended when you get to multiple devices and multiple device drivers, plus possibly user mappings. Simply assigning the buffer to "the device" from one driver does not block other drivers from touching the buffer, and assigning it to "the cpu" does not stop other hardware that the code calling sync_sg_for_cpu is not aware of.
The only way to solve this that I can think of right now is to mandate that the mappings are all coherent (i.e. noncachable on noncoherent architectures like ARM). If you do that, you no longer need the sync_sg_for_* calls.
Woops, totally missed the addition of these. Can somebody explain to used to rather coherent x86 what we need these for and the code-flow would look like in a typical example. I was kinda assuming that devices would bracket their use of a buffer with the attachment_map/unmap calls and any cache coherency magic that might be needed would be somewhat transparent to users of the interface?
The map call gets the dma_data_direction parameter, so it should be able to do the right thing. And because we keep the attachement around, any caching of mappings should be possible, too.
Yours, Daniel
PS: Slightly related, because it will make the coherency nightmare worse, afaict: Can we kill mmap support?