On 7/25/19 8:50 AM, Christoph Hellwig wrote: > On Wed, Jul 24, 2019 at 11:46:01AM -0400, Andrew F. Davis wrote: >> https://patchwork.kernel.org/patch/10863957/ >> >> It's actually a more simple heap type IMHO, but the logic inside is >> incompatible with the system/CMA heaps, if you move any of their code >> into the core framework then this heap stops working. Leading to out of >> tree hacks on the core to get it back functional. I see the same for the >> "complex" heaps with ION. > > Well, this mostly is just another allocator (gen_pool). And given that > the whole dma-buf infrastucture assumes things are backed by pages we > really shouldn't need much more than an alloc and a free callback (and > maybe the pgprot to map it) and handle the rest in common code. > But that's just it, dma-buf does not assume buffers are backed by normal kernel managed memory, it is up to the buffer exporter where and when to allocate the memory. The memory backed by this SRAM buffer does not have the normal struct page backing. So moving the map, sync, etc functions to common code would fail for this and many other heap types. This was a major problem with Ion that prompted this new design. Each heap type may need to do something different depending on its backing memory, moving everything to common code that is common to System and CMA heaps is would lead those being the only upstreamable heaps. Andrew _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
