Hi folks, I went ahead and checked what is the status of the UMM effort as 2011 is closing to an end. What follows is my attempt to summarise the status, collating the pieces from the latest announcements and changelogs and having discussed it briefly with Jesse and Rob. Feel free to comment if there is something missing or not correct:
A. CMA - Contiguous memory allocator. This is in its v17 incarnation at the moment (a v18 is in preparation but not released yet). v17 shares the code with memory compaction subsystem, not the hotplug like it was before (change has been suggested by Mel Gorman) and there are also a few fixes here and there, like addressing most of the comments from Andrew Morton and Mel Gorman in the rest of the CMA code, fixing broken initialization on ARM systems with DMA zone enabled and rebasing the code on v3.2-rc2 kernel. An issue has been noted in linaro-dev from the TI landing team : without any highmem the code is working great, but with HIGHMEM inclusion of the CMA v17 consistently causes failure during DMA init. This is expected to be fixed soon (perhaps in v18?). In meantime it is suggested using 2G/2G memory split as a workaround (Kernel Features -> Memory split -> 2G/2G user/kernel split). B. dma mapping API - DMA-mapping framework redesign for ARM architecture: this is in the v4 now. It includes a few minor changes since last version. The changes are mainly on the IOMMU mapper, keeping the DMA-mapping redesign patches almost unchanged. The code is rebased onto v3.2-rc4 kernel + IOMMU/next branch to include latest changes from IOMMU kernel tree. This series also contains support for mapping with pages larger than 4KiB using new, extended IOMMU API, and did a general cleanup of the DMA mapping implementation. However it seems that this patchset "attempts to fix everyone at once". It has been suggested that instead of trying to do that the implementation should give sufficient transition period - for example just adding the new methods now and only removing them in the following merge window when all the architectures have had a chance to migrate. C. dmabuf - a DMA-buf object sharing framework: this is now in its 3rd version. The newest version incorporates changes as requested during the review, such as - replacing BUG_ON with WARN_ON at various places, removing mmap() fop and dma_buf_op, also the sg_sync* operations, and documenting that mmap is not allowed for exported buffer, adding error checks, replacing EXPORT_SYMBOL with EXPORT_SYMBOL_GPL and fixing some cosmetic/documentation items. There are still some items under discusion such as userspace mmap support, more advanced (and more strictly specified) coherency models and shared infrastructure for implementing exporters. However, there is a suggestion that these items will become much clearer once we have a few example drivers at hand and a better understanding of what cases need to be handled better. D. Finally some repositories - where can you find the code to try it out: * git://git.linaro.org/people/jessebarker/linaro-mm-sig/linux.git contains (for the moment) 6 branches: + cma-v17 == unadulterated v3.2-rc4 + cma v17 patchset + dma-mapping-v4 == unadulterated v3.2-rc4 + dma-mapping v4 patchset + android-cma-v17 == john stultz's androidization tree based upon unadulterated v3.2-rc4 + cma v17 patchset + android-dma-mapping-v4 == john stultz's androidization tree based upon unadulterated v3.2-rc4 + dma-mapping v4 patchset Also note these repos: - https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf contains patches to enable sharing of buffers between drm and v4l2, Rob commented that it isn't really identified yet which tree to push dmabuf through.. airlied has volunteered to push via drm tree, which is ok - git://git.linaro.org/people/bgaignard/linux-snowball-cma-test.git contains a first version of the CMA testing scripts for LAVA (snowball specific at least for now) Best regards, -- Ilias Biris ilias.bi...@linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
