[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-19 Thread Marcus Lorentzon
On 03/19/2012 05:56 PM, Alan Cox wrote: >> display controller will be reading the front buffer, but the GPU >> > might also need to read that front buffer. So perhaps adding >> > "read-only"& "read-write" access flags to prepare could also be >> > interpreted as shared& exclusive accesses, if

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-19 Thread Marcus Lorentzon
On 03/19/2012 05:56 PM, Alan Cox wrote: display controller will be reading the front buffer, but the GPU > might also need to read that front buffer. So perhaps adding > "read-only"& "read-write" access flags to prepare could also be > interpreted as shared& exclusive accesses, if we went do

[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Marcus Lorentzon
On 03/15/2012 02:32 AM, Rob Clark wrote: > From: Rob Clark > [snip] > In all cases, the mmap() call is allowed to fail, and the associated > dma_buf_ops are optional (mmap() will fail if at least the mmap() > op is not implemented by the exporter, but in either case the > {prepare,finish}_access()

[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Rob Clark
On Fri, Mar 16, 2012 at 5:50 AM, Marcus Lorentzon wrote: > On 03/15/2012 02:32 AM, Rob Clark wrote: >> >> From: Rob Clark >> [snip] >> >> In all cases, the mmap() call is allowed to fail, and the associated >> dma_buf_ops are optional (mmap() will fail if at least the mmap() >> op is not implement

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Rob Clark
On Fri, Mar 16, 2012 at 5:50 AM, Marcus Lorentzon wrote: > On 03/15/2012 02:32 AM, Rob Clark wrote: >> >> From: Rob Clark >> [snip] >> >> In all cases, the mmap() call is allowed to fail, and the associated >> dma_buf_ops are optional (mmap() will fail if at least the mmap() >> op is not implement

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Marcus Lorentzon
On 03/15/2012 02:32 AM, Rob Clark wrote: From: Rob Clark [snip] In all cases, the mmap() call is allowed to fail, and the associated dma_buf_ops are optional (mmap() will fail if at least the mmap() op is not implemented by the exporter, but in either case the {prepare,finish}_access() ops are op

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Rebecca Schultz Zavin
This looks perfect to me and will close really the last remaining blocking issue for converting ion to be a dma-buf exporter. Assuming there are no major objections to this I'll post some patches to the list next week that make that change to ion. Looking forward to meeting in the middle on this!

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Rebecca Schultz Zavin
This looks perfect to me and will close really the last remaining blocking issue for converting ion to be a dma-buf exporter. Assuming there are no major objections to this I'll post some patches to the list next week that make that change to ion. Looking forward to meeting in the middle on this!

[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-15 Thread Abhinav Kochhar
do we need to pass the dmabuf object to dmabuf->ops->mmap(dmabuf, file, vma)? as file->private_data can retrieve the dmabuf object. *"dmabuf = file->private_data"* *removing dmabuf from the function arguments will keep it consistent with basic "mmap" definitions: * *"static int _mmap(struct

[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-15 Thread Rebecca Schultz Zavin
This looks perfect to me and will close really the last remaining blocking issue for converting ion to be a dma-buf exporter. Assuming there are no major objections to this I'll post some patches to the list next week that make that change to ion. Looking forward to meeting in the middle on this!

[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-15 Thread Rebecca Schultz Zavin
This looks perfect to me and will close really the last remaining blocking issue for converting ion to be a dma-buf exporter. Assuming there are no major objections to this I'll post some patches to the list next week that make that change to ion. Looking forward to meeting in the middle on this!

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-15 Thread Rob Clark
On Thu, Mar 15, 2012 at 2:16 AM, Abhinav Kochhar wrote: > do we need to pass the dmabuf object to dmabuf->ops->mmap(dmabuf, file, > vma)? > > as file->private_data can retrieve the dmabuf object. > > "dmabuf = file->private_data" > > removing dmabuf from the function arguments will keep it consist

[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-15 Thread Rob Clark
On Thu, Mar 15, 2012 at 2:16 AM, Abhinav Kochhar wrote: > do we need to pass the dmabuf object to dmabuf->ops->mmap(dmabuf, file, > vma)? > > as file->private_data can retrieve the dmabuf object. > > "dmabuf = file->private_data" > > removing dmabuf from the function arguments will keep it consist

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-15 Thread Abhinav Kochhar
do we need to pass the dmabuf object to dmabuf->ops->mmap(dmabuf, file, vma)? as file->private_data can retrieve the dmabuf object. *"dmabuf = file->private_data"* *removing dmabuf from the function arguments will keep it consistent with basic "mmap" definitions: * *"static int _mmap(struct