On Mon, Feb 27, 2012 at 16:43, Tomasz Stanislawski <t.stanislaws@xxxxxxxxxxx> wrote: > The documentation of DMABUF says fallowing words about map_dma_buf callback. > > "It is one of the buffer operations that must be implemented by the > exporter. It should return the sg_table containing scatterlist for this > buffer, mapped into caller's address space." > > The scatterlist returned by drm_prime_pages_to_sg is not mapped to any > device. The map_dma_buf callback should call dma_map_sg for caller device, > which is attachment->dev. Otherwise the implementation is not consistent > with the DMABUF spec. > > I think that it should be chosen to change implementation in map_dma_buf in > DRM drivers or to drop mentioned sentence from the DMABUF spec. > > I bear to the second solution because IMO there is no reliable way of > mapping a scatterlist to importer device by an exporter. The dma_map_sg > could be used but not all drivers makes use of DMA framework. Yep, drm/gem dma_buf integration is in violation of the spec here, and imo the spec is right. To fix this we need to extend dma_buf to also cover use-cases it currently can't work in (like cpu access). See http://cgit.freedesktop.org/~danvet/drm/log/?h=dma_buf-cpu-access for my wip rfc to make that possible. We obviously need to fix up the drm prime stuff before merging, so the current emphasis for these rfc's is on getting the lifecycles and similar stuff right for integration buffer-sharing with gem (and not yet so much actually getting at the data). Yours, Daniel -- Daniel Vetter daniel.vetter@xxxxxxxx - +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
