Re: [PATCH v9] dma-buf: Add ioctls to allow userspace to flush

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux