On Mon, Feb 27, 2012 at 16:43, Tomasz Stanislawski t.stanislaws@samsung.com 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