On Wed, Aug 7, 2013 at 12:23 AM, John Stultz john.stultz@linaro.org wrote:

On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark robdclark@gmail.com wrote:

...

well, let's divide things up into two categories:

1. the arrangement and format of pixels.. ie. what userspace would

need to know if it mmap's a buffer. This includes pixel format, stride, etc. This should be negotiated in userspace, it would be crazy to try to do this in the kernel.

2. the physical placement of the pages. Ie. whether it is contiguous

or not. Which bank the pages in the buffer are placed in, etc. This is not visible to userspace. This is the purpose of the attach step, so you know all the devices involved in sharing up front before allocating the backing pages. (Or in the worst case, if you have a "late attacher" you at least know when no device is doing dma access to a buffer and can reallocate and move the buffer.) A long time

One concern I know the Android folks have expressed previously (and correct me if its no longer an objection), is that this attach time in-kernel constraint solving / moving or reallocating buffers is likely to hurt determinism. If I understood, their perspective was that userland knows the device path the buffers will travel through, so why not leverage that knowledge, rather then having the kernel have to sort it out for itself after the fact.

If you know the device path, then attach the buffer at all the devices before you start using it. Problem solved.. kernel knows all devices before pages need be allocated ;-)

BR, -R