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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
