On 11/25/2016 04:30 AM, Benjamin Gaignard wrote: > Hi Laura, > > Thanks for what you are doing on ION. > As soon that will be ok I will submit again the driver for sti platform. > > After reading your mail I have the feeling that solves cache, > devicetree and legacy support problems will be difficult. > > Since "Unix Device Memory Allocator" claims that it will solve memory > requirements for us, > would it not be more simple to write "standalone" drivers for each > memory type (CMA, carveout, etc..) ? > What I have in mind is a set of kernel allocators sharing a minimum of > code like some ioctl and /dev/allocator/xxx > > The drawback is that we have to start something for scratch but could > it complementary to what you are doing? Yes, that's the direction I was thinking about as well. I expect the Unix Device Allocator to take care of the constraint solving problem and the Ion/kernel portion to focus primarily on enumeration. Thanks, Laura > > Regards, > Benjamin > > 2016-11-18 22:07 GMT+01:00 Laura Abbott <labbott@xxxxxxxxxx>: >> Hi, >> >> At LPC, I proposed a moratorium on new Ion features because of issues >> preventing Ion ever moving out of staging. Among other problems, >> the Ion caching model hasn't made much progress to a solution that >> is widely accepted and there are still problems with devicetree >> support. There were no strong objections to this proposal so I >> propose continuing with a moratorium for at least the next 6 months >> to a year to actually work on a new architecture. If this hasn't >> made much progress by then I plan to hand off Ion to someone else >> to try other approaches. >> >> There's been some discussion about a Unix Device Memory Allocator >> https://github.com/cubanismo/allocator . Ideally, this would be >> a complete replacement for Ion. This means capturing Ion or >> Ion-like requirements. The current proposal mostly focuses on >> userspace requirements and assumes Ion is just acting as an >> enumerator of various memory to allocate. This is a good direction. >> Ideally some of the Ion kernel code could be leveraged for a 'generic >> device memory allocator'. This device allocator should also be >> support use cases such as the SMAF (secure memory allocation >> framework) which has also been a work in progress. >> >> One of the big open problems, as mentioned above, is the caching >> model. Specifying an uncached buffer at allocation time requires >> doing cache operations outside of the DMA framework which makes >> a bunch of maintainers unhappy. None of the arguments I've given >> for justification have really stuck which is a good sign that Ion >> should probably not be doing cache operations. If we ignore the Ion >> page pooling feature, this could be fixed by requiring that drivers >> call dma_buf_map and calling dma_map there. This gets tricker when >> drivers want to call mmap from userspace before passing the buffer >> down to ensure coherency. This model will need some more thought >> and possibly integration with Android. >> >> I'd like to keep using linaro-mm-sig as a mailing list for Ion >> discussion as well as drivers-devel. If it would help to have >> another place for tracking/discussion I can see about setting >> that up as well. >> >> Thanks, >> Laura >> >> _______________________________________________ >> Linaro-mm-sig mailing list >> Linaro-mm-sig@xxxxxxxxxxxxxxxx >> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig > > > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
