Hey Rob,
Op 13-07-12 17:38, Rob Clark schreef:
> ...
> +/**
> + * dma_buf_attach_fence - Attach a fence to a dma-buf.
> + *
> + * @buf: the dma-buf to attach to
> + * @fence: the fence to attach
> + *
> + * A fence can only be attached to a single dma-buf. The dma-buf takes
> + * ownership of the
On Fri, Jul 13, 2012 at 4:44 PM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 13-07-12 20:52, Rob Clark schreef:
>> On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey wrote:
>>> My other thought is around atomicity. Could this be extended to
>>> (safely) allow for hardware devices which might want to access
Hey,
Op 13-07-12 20:52, Rob Clark schreef:
> On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey wrote:
>> My other thought is around atomicity. Could this be extended to
>> (safely) allow for hardware devices which might want to access
>> multiple buffers simultaneously? I think it probably can with
>
On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey wrote:
> My other thought is around atomicity. Could this be extended to
> (safely) allow for hardware devices which might want to access
> multiple buffers simultaneously? I think it probably can with
> some tweaks to the interface? An atomic function
From: Rob Clark
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU
oh, btw, this should be an [RFC]
On Wed, Jul 11, 2012 at 5:29 PM, Rob Clark wrote:
> From: Rob Clark
>
> A dma-fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call
