[Linaro-mm-sig] [RFC] dma-shared-buf: Add buffer sharing framework
daniel at ffwll.ch
Thu Sep 8 20:28:49 UTC 2011
On Thu, Sep 08, 2011 at 12:39:41PM -0500, Clark, Rob wrote:
> On Thu, Sep 8, 2011 at 10:55 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Thu, Sep 08, 2011 at 08:45:43PM +0530, Sumit Semwal wrote:
> >> On 8 September 2011 19:48, Clark, Rob <rob at ti.com> wrote:
> >> > actually, all I think we needed was to add 'struct device *' to
> >> > get_scatterlist (and maybe doesn't hurt for put).. I'm not entirely
> >> > sure why we need create/attach_device? The create fxn especially
> >> > seems wrong.. what if you are the 2nd device to import the buffer?
> >> >
> >> Ah... I guess I misunderstood your 'it seems like a sane approach' to mean
> >> you agree with the 2-step process suggested by Daniel :) - my bad!
> > On re-reading Rob's response I think there's a misunderstanding. I don't
> > want a create function in the dma_buf_ops. The create would be a generic
> > dma_buf subsystem function that (like in the patch) allocates the struct
> > and properly registers the fd and what not else. The attach_device would
> > then be the only new function in dma_buf_ops.
> > The confusion probably stems from my other proposal to hide these function
> > pointers behind small inline helpers for the in-kernel api.
> I guess/assume that what you are trying to get to is a way to
> differentiate between "I am done DMA'ing to the buffer now, but will
> likely use it again (ie. feel free to cache the mapping)", and "I am
> done forever w/ the buffer (don't bother caching)"?
Hm, no, I haven't really thought much about the release side. dri2/gem
doesn't have any automatic caching of shared buffers, btw, that's all done
manually (i.e. in the higher levels like the mesa/ddx drivers) by keeping
track of recently shared buffers (and hanging onto them for as long as
possible without creating havoc on the other side).
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
More information about the Linaro-mm-sig