Discussion starters for ION session at Linux Plumbers Android+Graphics microconf

[Rob Clark]

On Thu, Sep 5, 2013 at 8:49 PM, John Stultz <john.stultz at linaro.org> wrote:
> Hey everyone,
>    In preparation for the Plumbers Android+Graphics microconf, I wanted to
> send out some background documentation to try to get all the context we can
> out there prior to the discussion, as time will be limited and it would be
> best to spend it discussing solutions rather then re-hashing problems and
> requirements.
>
> I'm sure many folks on this list could probably do a better job summarizing
> the issues, but I wanted to get this out there to try to enumerate the
> problems and the different perspectives on the issues that I'm aware of.
>
> The document is on LWN here:
> http://lwn.net/SubscriberLink/565469/9d88daa2282ef6c2/

oh, I had missed that article.. fwiw

"Another possible solution is to allow dma-buf exporters to not
allocate the backing buffers immediately. This would allow multiple
drivers to attach to a dma-buf before the allocation occurs. Then,
when the buffer is first used, the allocation is done; at that time,
the allocator could scan the list of attached drivers and be able to
determine the constraints of the attached devices and allocate memory
accordingly. This would allow user space to not have to deal with any
constraint solving. "

That is actually how dma-buf works today.  And at least with GEM
buffers exported as dma-buf's, the allocation is deferred.  It does
require attaching the buffers in all the devices that will be sharing
the buffer up front (but I suppose you need to know the involved
devices one way or another with any solution, so this approach seems
as good as any).  We *do* still need to spiff up dev->dma_parms a bit
more, and there might be some room for some helpers to figure out the
union of all attached devices constraints, and allocate suitable
backing pages... so perhaps this is one thing we should be talking
about.

At any rate, it might not matter if ION cannot import dma-buf's (as
long as every other device importing does not have to differentiate
between importing dma-buf's that are also ION buffers vs dma-buf's
allocated in some other way).  But to be useful upstream, we'd have to
ensure that existing drm drivers can somehow plug-in their existing
allocation mechanisms in to ION.

BR,
-R

> But I wanted to start a discussion thread here, since the LWN comment
> threads (while *much* better then most comment sections) aren't really the
> right place for this sort of thing.
>
> So please feel free to reply to correct any inaccuracies in my summary,
> provide your thoughts on the various proposed solutions, or suggest new
> solutions that we should also discuss at the micro-conference!
>
> thanks
> -john
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>