Hi Daniel, On Tuesday 31 January 2012 11:36:02 Daniel Vetter wrote: > On Tue, Jan 31, 2012 at 10:42:59AM +0100, Laurent Pinchart wrote: > > Hi Sumit, > > > > > On Friday 27 January 2012 10:43:28 Sumit Semwal wrote: > > [snip] > > > > > static inline void dma_buf_unmap_attachment(struct dma_buf_attachment > > > > > > *attach, > > > - struct sg_table *sg) > > > + struct sg_table *sg, enum dma_data_direction > > > write) > > > > On a second thought, would it make sense to store the direction in struct > > dma_buf_attachment in dma_buf_map_attachment(), and pass the value > > directly to the .unmap_dma_buf() instead of requiring the > > dma_buf_unmap_attachment() caller to remember it ? Or is an attachment > > allowed to map the buffer several times with different directions ? > > Current dma api functions already require you to supply the direction > argument on unmap If I understand it correctly, that's mostly because the DMA API doesn't keep track of DMA mappings in a way that it can store the direction on map(), and use it on unmap(). In this case we have an attachment object that we can use to cache the information. > and I think for cpu access I'm also leaning towards an interface where the > importer has to supply the direction argument for both begin_access and > end_access. So for consistency reasons I'm leaning towards adding it to > unmap. I'm OK with keeping the direction as an argument to unmap() if you think that's better. -- Regards, Laurent Pinchart -- 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
