On Thu, Jan 26, 2012 at 1:37 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Wed, Jan 25, 2012 at 06:02:41PM +0100, Tomasz Stanislawski wrote:
Hi Sumit,
On 12/26/2011 10:23 AM, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
[snip]
+struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
- enum dma_data_direction);
+void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *);
I think that you should add enum dma_data_direction as an argument unmap function. It was mentioned that the dma_buf_attachment should keep cached and mapped sg_table for performance reasons. The field dma_buf_attachment::priv seams to be a natural place to keep this sg_table. To map a buffer the exporter calls dma_map_sg. It needs dma direction as an argument. The problem is that dma_unmap_sg also needs this argument but dma direction is not available neither in dma_buf_unmap_attachment nor in unmap callback. Therefore the exporter is forced to embed returned sg_table into a bigger structure where dma direction is remembered. Refer to function vb2_dc_dmabuf_ops_map at
Oops, makes sense. I've totally overlooked that we need to pass in the dma direction also for the unmap call to the dma subsystem. Sumit, can you stitch together that small patch?
Right, of course. I will do that by tomorrow; it is a bank holiday today here in India, so.
regards, ~Sumit.
-Daniel
Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48