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? Regards, Benjamin 2016-11-18 22:07 GMT+01:00 Laura Abbott <labb...@redhat.com>: > 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-...@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
