[EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework

[John Stultz]

On Tue, Mar 5, 2019 at 10:05 AM Andrew F. Davis <afd at ti.com> wrote:
> On 3/4/19 7:16 PM, John Stultz wrote:
> > The current patchset against v5.0 (with hikey960 patches), which
> > includes the flags and other suggested changes is here:
> >   https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
> >
> > W/ userland support here:
> >   https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
> >
> > I'm hoping to send this out for a real RFC in the next few days. So
> > Andrew, if you can check it out and make sure it suits you ok I'd
> > appreciate it!
> >
>
> Nothing at a high level, couple little things I can just point out when
> you RFC, I think this is in good shape for a real RFC.

Ok.  Hopefully I can get it sent out later today.

> I'd say hold off on it for now. My problem is that caching is not
> something you can really switch at runtime. A heap's backing memory is
> either cached or not. This an issue Brian and I had discussed a bit on
> the other thread.
>
> Basically if you have a carveout heap for instance, if in DT you have
> the reserved-memory node marked "no-map" then it will be non-cached and
> you cannot ever make it cached, you could try to hand out cached
> userspace mappings on mmap() but those pages will not have a valid
> struct *page so most of the dma_sync_* stuff will break. Same is true
> the other way, if it is cached, the kernel will always have valid cached
> entries of that memory as the kernel logic address area, so handing out
> non-cached mappings to userspace breaks aliased mapping attribute rules
> on ARM (and probably dangerous on other ARCHs).
>
> In the end you only have heaps that have cached or heaps with non-cached
> memory, but cannot switch based on a flag at runtime.

Ok. This is convincing. I'll drop that flag for now.

thanks
-john