On Fri, Feb 12, 2016 at 03:50:02PM +0100, David Herrmann wrote: > Hi > > On Thu, Feb 11, 2016 at 11:04 PM, Tiago Vignatti > <tiago.vignatti@xxxxxxxxx> wrote: > > From: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > The userspace might need some sort of cache coherency management e.g. when CPU > > and GPU domains are being accessed through dma-buf at the same time. To > > circumvent this problem there are begin/end coherency markers, that forward > > directly to existing dma-buf device drivers vfunc hooks. Userspace can make use > > of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence would be > > used like following: > > - mmap dma-buf fd > > - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write > > to mmap area 3. SYNC_END ioctl. This can be repeated as often as you > > want (with the new data being consumed by the GPU or say scanout device) > > - munmap once you don't need the buffer any more > > > > v2 (Tiago): Fix header file type names (u64 -> __u64) > > v3 (Tiago): Add documentation. Use enum dma_buf_sync_flags to the begin/end > > dma-buf functions. Check for overflows in start/length. > > v4 (Tiago): use 2d regions for sync. > > v5 (Tiago): forget about 2d regions (v4); use _IOW in DMA_BUF_IOCTL_SYNC and > > remove range information from struct dma_buf_sync. > > v6 (Tiago): use __u64 structured padded flags instead enum. Adjust > > documentation about the recommendation on using sync ioctls. > > v7 (Tiago): Alex' nit on flags definition and being even more wording in the > > doc about sync usage. > > v9 (Tiago): remove useless is_dma_buf_file check. Fix sync.flags conditionals > > and its mask order check. Add <linux/types.h> include in dma-buf.h. > > > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > Cc: David Herrmann <dh.herrmann@xxxxxxxxx> > > Cc: Sumit Semwal <sumit.semwal@xxxxxxxxxx> > > Reviewed-by: Stéphane Marchesin <marcheu@xxxxxxxxxxxx> > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > > Signed-off-by: Tiago Vignatti <tiago.vignatti@xxxxxxxxx> > > --- > > > > I left SYNC_START and SYNC_END exclusive, just how the logic was before. If we > > see an useful use case, maybe like the way David said, to store two frames > > next to each other in the same BO, we can patch up later fairly easily. > > > > About the ioctl direction, just like Ville pointed, we're doing only > > copy_from_user at the moment and seems that _IOW is all we need. So I also > > didn't touch anything on that. > > Fair enough. > > All I have left are comments on coding-style, and I'll refrain from > verbalizing them.. (gnah, it is so tempting). > > Reviewed-by: David Herrmann <dh.herrmann@xxxxxxxxx> Merged to drm-misc, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
