[lkml]   [2011]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
    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?
    Daniel Vetter
    Mobile: +41 (0)79 365 57 48

     \ /
      Last update: 2011-12-05 19:57    [W:0.023 / U:108.164 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site