On 04/12/2017 01:12 PM, Chris Wilson wrote:
> On Wed, Apr 12, 2017 at 12:57:00PM -0700, Laura Abbott wrote:
>> On 04/12/2017 12:38 PM, Chris Wilson wrote:
>>> On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
Both the read/write are missing the dma_buf_begin_cpu_access calls.
On Wed, Apr 12, 2017 at 12:57:00PM -0700, Laura Abbott wrote:
> On 04/12/2017 12:38 PM, Chris Wilson wrote:
> > On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
> >> Both the read/write are missing the dma_buf_begin_cpu_access calls.
> >> When I add those these seem to work well enough
On 04/12/2017 12:38 PM, Chris Wilson wrote:
> On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
>> On 04/07/2017 02:25 PM, Chris Wilson wrote:
>>> It is expected that processes will pass dma-buf fd between drivers, and
>>> only using the fd themselves for mmaping and synchronisation ioc
On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
> On 04/07/2017 02:25 PM, Chris Wilson wrote:
> > It is expected that processes will pass dma-buf fd between drivers, and
> > only using the fd themselves for mmaping and synchronisation ioctls.
> > However, it may be convenient for an a
On 04/07/2017 02:25 PM, Chris Wilson wrote:
> It is expected that processes will pass dma-buf fd between drivers, and
> only using the fd themselves for mmaping and synchronisation ioctls.
> However, it may be convenient for an application to read/write into the
> dma-buf, for instance a test case
