On Thu, Jan 26, 2012 at 1:37 AM, Daniel Vetter <daniel@xxxxxxxx> 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@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
