Hello, On Tuesday, March 29, 2011 4:02 PM Willy POISSON wrote:
> Following to the Warsaw mini-summit action point, I would like to open > the thread to gather > buffer pool & memory manager requirements. > The list of requirement for buffer pool may contain: > - Support physically contiguous and virtual memory > - Support IPC, import/export handles (between > processes/drivers/userland/etc) > - Security(access rights in order to secure no one unauthorized is > allowed to access buffers) > - Cache flush management (by using setdomain and optimize when flushing > is needed) > - Pin/unpin in order to get the actual address to be able to do > defragmentation > - Support pinning in user land in order to allow defragmentation while > buffer is mmapped but not > pined. > - Both a user API and a Kernel API is needed for this module. (Kernel > drivers needs to be able to > resolve buffer handles as well from the memory manager module, and pin/unpin) > - be able to support any platform specific allocator (Separate memory > allocation from management > as allocator is platform dependant) > - Support multiple region domain (Allow to allocate from several memory > domain ex: DDR1, DDR2, > Embedded SRAM to make for ex bandwidth load balancing ...) The above list looks fine. Memory/buffer pools are a large topic that covers at least 3 subsystems: 1. user space api 2. in-kernel buffer manager 3. in-kernel memory allocator Most of the requirements above list can be assigned to one of these subsystems. If would like to focus first on the user space API. This API should provide a generic way to allocate memory buffers. User space should not be aware of the allocator specific parameters of the buffer. User space should not decide whether a physically contiguous buffer is needed or not. The only information that user space should provide is a set or list of devices that the application want use with the allocated buffer. User space might also provide some additional hints about the buffers - like the preferred memory region. Our chip S5PC110 and EXYNOS4 are very similar in terms of integrated multimedia modules, however there is one important difference. The latter has IOMMU module, so multimedia blocks doesn't require physically contiguous buffers. In userspace however we would like to support both with the same API. We have also a very specific requirement for buffers for video codes (chroma buffers and luma buffers must be allocated from different memory banks). The memory bank should be specified at allocation time. The only problem is to define a way the user space API will be able to provide a list of devices that must be able to operate with the allocated buffer. Without some kind of enumeration of all entities that work with buffer pool it might be a bit hard. I would like to avoid the need of hardcoding device names in the user space applications. The in-kernel memory allocator is mainly targeted to systems that require physically contiguous buffers. Currently CMA framework perfectly fits here. A new version will be posted very soon. > Another idea, but not so linked to memory management (more usage of buffers), > would be to have a > common data container (structure to access data) shared by several media > (Imaging, video/still codecs, > graphics, Display...) to ease usage of the data. This container could embed > data type (video frames, > Access Unit) , frames format, pixel format, width, height, pixel aspect > ratio, region of interest, CTS > (composition time stamp), ColorSpace, transparency (opaque, alpha, color > key...), pointer on buffer(s) > handle)... I'm not sure if such idea can be ever implemented in the mainline kernel... IHMO it is too complicated. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
