On Fri, Sep 02, 2011 at 10:49:44AM -0500, Clark, Rob wrote:
oh, and if the importing driver is bracketing DMA to/from the buffer w/ get/put scatter list, it should even be possible to implement more fancy reallocation or migration stuff later if it is actually needed, without changing dmabuf API. Or at least this is my theory.
The restriction is that get_sglist needs to be called only from a context that could block.
(And maybe needs to return some hint to the importing driver that the buffer location has/hasn't changed? I'm not sure.. if we are returning device addresses thanks to iommu and having passed the 'struct device' ptr to get_sglist(), then all the optimizations of caching the mapping of the buffer is all behind the scenes?)
Yeah, that's the idea. It's only a small step from the 2-step api to something with (implicit) sync objects. The easieast way would be to add a flag to get_scatterlist to tell the core that the corresponding put_scatterlist will happen in a short time. And another flag for attach_device to wait for oustanding dma so that the buffer can be re-allocated. It would obviously still return -EBUSY if there are valid mappings with indefinit lifetime out there. -Daniel