On Tue, Jan 24, 2012 at 10:34:38AM +0100, Laurent Pinchart wrote: > > > I'm not sure I would like a callback approach. If we add a sync > > > operation, the exporter could signal to the importer that it must unmap > > > the buffer by returning an appropriate value from the sync operation. > > > Would that be usable for DRM ? > > > > It does seem a bit over-complicated.. and deadlock prone. Is there a > > reason the importer couldn't just unmap when DMA is completed, and the > > exporter give some hint on next map() that the buffer hasn't actually > > moved? > > If the importer unmaps the buffer completely when DMA is completed, it will > have to map it again for the next DMA transfer, even if the > dma_buf_map_attachement() calls returns an hint that the buffer hasn't moved. > > What I want to avoid here is having to map/unmap buffers to the device IOMMU > around each DMA if the buffer doesn't move. To avoid that, the importer needs > to keep the IOMMU mapping after DMA completes if the buffer won't move until > the next DMA transfer, but that information isn't available when the first DMA > completes. The exporter should cache the iommu mapping for all attachments. The driver would the only need to adjust the dma address - I was kinda hoping this would be little enough overhead that we could just ignore it, at least for the moment (especially for hw that can only deal with contigious buffers). The issue with adding explicit support for evicting buffers is that it's hilariously deadlock-prone, especially when both sides are exporters (dev1 waits for dev2 to finish processing buffer A while dev2 waits for dev1 to finish with buffer B ...). Before we don't have a solid buffer sharing between gpus (i.e. prime) I don't think it makes sense to add these extension to dma_buf. -Daniel -- Daniel Vetter Mail: daniel@xxxxxxxx Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
