On Sat, Mar 17, 2012 at 3:17 PM, Alan Cox alan@lxorguk.ukuu.org.uk wrote:
dma-buf file descriptor. Userspace access to the buffer should be bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to give the exporting driver a chance to deal with cache synchronization and such for cached userspace mappings without resorting to page
There should be flags indicating if this is necessary. We don't want extra syscalls on hardware that doesn't need it. The other question is what info is needed as you may only want to poke a few pages out of cache and the prepare/finish on its own gives no info.
Well, there isn't really a convenient way to know, for some random code that is just handed a dmabuf fd, what the flags are without passing around an extra param in userspace. So I'd tend to say, just live with the syscall even if it is a no-op (because if you are doing sw access to the buffer, that is anyways some slow/legacy path). But I'm open to suggestions.
As far as just peeking/poking a few pages, that is where some later ioctls or additional params could come in, to give some hints. But I wanted to keep it simple to start.
E.g. If another device was writing to the buffer, the prepare ioctl could block until that device had finished accessing that buffer.
How do you avoid deadlocks on this ? We need very clear ways to ensure things always complete in some form given multiple buffer owner/requestors and the fact this API has no "prepare-multiple-buffers" support.
Probably some separate synchronization is needed.. I'm not really sure if prepare/finish (or map/unmap on kernel side) is a the right way to handle that.
BR, -R
Alan _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel