Messages in this thread | | | From | "Semwal, Sumit" <> | Date | Thu, 26 Jan 2012 11:05:30 +0530 | Subject | Re: [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism |
| |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |