On Mon, Mar 14, 2016 at 05:21:10PM -0300, Tiago Vignatti wrote:
> On 03/05/2016 06:34 AM, Daniel Vetter wrote:
> >On Mon, Feb 29, 2016 at 03:02:09PM +0000, Chris Wilson wrote:
> >>On Mon, Feb 29, 2016 at 03:54:19PM +0100, Daniel Vetter wrote:
> >>>On Thu, Feb 25, 2016 at 06:01:22PM +0000, Chris Wilson wrote:
> >>>>On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vignatti wrote:
> >>>>>+static long dma_buf_ioctl(struct file *file,
> >>>>>+ unsigned int cmd, unsigned long arg)
> >>>>>+{
> >>>>>+ struct dma_buf *dmabuf;
> >>>>>+ struct dma_buf_sync sync;
> >>>>>+ enum dma_data_direction direction;
> >>>>>+
> >>>>>+ dmabuf = file->private_data;
> >>>>>+
> >>>>>+ switch (cmd) {
> >>>>>+ case DMA_BUF_IOCTL_SYNC:
> >>>>>+ if (copy_from_user(&sync, (void __user *) arg, sizeof(sync)))
> >>>>>+ return -EFAULT;
> >>>>>+
> >>>>>+ if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
> >>>>>+ return -EINVAL;
> >>>>>+
> >>>>>+ switch (sync.flags & DMA_BUF_SYNC_RW) {
> >>>>>+ case DMA_BUF_SYNC_READ:
> >>>>>+ direction = DMA_FROM_DEVICE;
> >>>>>+ break;
> >>>>>+ case DMA_BUF_SYNC_WRITE:
> >>>>>+ direction = DMA_TO_DEVICE;
> >>>>>+ break;
> >>>>>+ case DMA_BUF_SYNC_RW:
> >>>>>+ direction = DMA_BIDIRECTIONAL;
> >>>>>+ break;
> >>>>>+ default:
> >>>>>+ return -EINVAL;
> >>>>>+ }
> >>>>>+
> >>>>>+ if (sync.flags & DMA_BUF_SYNC_END)
> >>>>>+ dma_buf_end_cpu_access(dmabuf, direction);
> >>>>>+ else
> >>>>>+ dma_buf_begin_cpu_access(dmabuf, direction);
> >>>>
> >>>>We forgot to report the error back to userspace. Might as well fixup the
> >>>>callchain to propagate error from end-cpu-access as well. Found after
> >>>>updating igt/gem_concurrent_blit to exercise dmabuf mmaps vs the GPU.
> >>>
> >>>EINTR? Do we need to make this ABI - I guess so? Tiago, do you have
> >>>patches? See drmIoctl() in libdrm for what's needed on the userspace side
> >>>if my guess is right.
> >>
> >>EINTR is the easiest, but conceivably we could also get EIO and
> >>currently EAGAIN.
> >>
> >>I am also seeing some strange timing dependent (i.e. valgrind doesn't
> >>show up anything client side and the tests then pass) failures (SIGSEGV,
> >>SIGBUS) with !llc.
> >
> >Tiago, ping. Also probably a gap in igt coverage besides the kernel side.
> >-Daniel
>
> Hey guys! I'm back from vacation now. I'll take a look on it in the
> next days and then come back to you.
An unpolished version:
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=b83483e87438f870d8209a44a1843235555a1d54
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
