On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airlied@gmail.com wrote:
But then we'd need a different set of accessors for every different drm/v4l/etc driver, wouldn't we?
Not any more different than you need for this, you just have a new interface that you request a sw object from, then mmap that object, and underneath it knows who owns it in the kernel.
oh, ok, so you are talking about a kernel level interface, rather than userspace..
but I guess in this case I don't quite see the difference. It amounts to which fd you call mmap (or ioctl[*]) on.. If you use the dmabuf fd directly then you don't have to pass around a 2nd fd.
[*] there is nothing stopping defining some dmabuf ioctls (such as for synchronization).. although the thinking was to keep it simple for first version of dmabuf
BR, -R
mmap just feels wrong in this API, which is a buffer sharing API not a buffer mapping API.
I guess if sharing a buffer between multiple drm devices, there is nothing stopping you from having some NOT_DMABUF_MMAPABLE flag you pass when the buffer is allocated, then you don't have to support dmabuf->mmap(), and instead mmap via device and use some sort of DRM_CPU_PREP/FINI ioctls for synchronization..
Or we could make a generic CPU accessor that we don't have to worry about.
Dave.