[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKMK7uEcukmyyqL6N2XMwMDjGe81NkhmuE1k0QyeJYKF0ufktg@mail.gmail.com>
Date: Mon, 5 Mar 2012 22:31:52 +0100
From: Daniel Vetter <daniel.vetter@...ll.ch>
To: Rob Clark <rob.clark@...aro.org>
Cc: Chris Wilson <chris@...is-wilson.co.uk>,
linaro-mm-sig@...ts.linaro.org,
LKML <linux-kernel@...r.kernel.org>,
DRI Development <dri-devel@...ts.freedesktop.org>,
linux-media@...r.kernel.org
Subject: Re: [Linaro-mm-sig] [PATCH 2/3] dma-buf: add support for kernel cpu access
On Fri, Mar 2, 2012 at 23:53, Rob Clark <rob.clark@...aro.org> wrote:
> nitially the expectation was that userspace would not pass a buffer
> to multiple subsystems for writing (or that if it did, it would get
> the undefined results that one could expect).. so dealing w/
> synchronization was punted.
Imo synchronization should not be part of the dma_buf core, i.e.
userspace needs to ensure that access is synchronized.
begin/end_cpu_access are the coherency brackets (like map/unmap for
device dma). And if userspace asks for a gun and some bullets, the
kernel should just deliver. Even in drm/i915 gem land we don't (and
simply can't) make any promises about concurrent reads/writes/ioctls.
> I expect, though, that one of the next steps is some sort of
> sync-object mechanism to supplement dmabuf
Imo the only reason to add sync objects as explicit things is to make
device-to-device sync more efficient by using hw semaphores and
signalling lines. Or maybe a quick irq handler in the kernel that
kicks of the next device. I don't think we should design these to make
userspace simpler.
Cheers, Daniel
--
Daniel Vetter
daniel.vetter@...ll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists