Hi Marek,
In function: dma_alloc_coherent()->arm_iommu_alloc_attrs()->__iommu_alloc_buffer()
I have following questions:
a) Before we come to this point, we would have enabled SYSMMU in a call to arm_iommu_init(). Shouldnt the SYSMMU be enabled after call to __iommu_alloc_buffer(), but before __iommu_create_mapping()? If in case the __iommu_alloc_buffer() fails, we dont disable the SYSMMU.
b) For huge buffer sizes, the pressure on SYSMMU would be very high. Cant we have option to dictate the page size for the IOMMU from driver in such cases? Should it always be the size of system pages?
Regards, Subash SISO-SLG
On 05/25/2011 01:05 PM, Marek Szyprowski wrote:
Hello,
Folloing the discussion about the driver for IOMMU controller for Samsung Exynos4 platform and Arnd's suggestions I've decided to start working on redesign of dma-mapping implementation for ARM architecture. The goal is to add support for IOMMU in the way preffered by the community :)
Some of the ideas about merging dma-mapping api and iommu api comes from the following threads: http://www.spinics.net/lists/linux-media/msg31453.html http://www.spinics.net/lists/arm-kernel/msg122552.html http://www.spinics.net/lists/arm-kernel/msg124416.html
They were also discussed on Linaro memory management meeting at UDS (Budapest 9-12 May).
I've finaly managed to clean up a bit my works and present the initial, very proof-of-concept version of patches that were ready just before Linaro meeting.
What have been implemented:
- Introduced arm_dma_ops
dma_map_ops from include/linux/dma-mapping.h suffers from the following limitations:
- lack of start address for sync operations
- lack of write-combine methods
- lack of mmap to user-space methods
- lack of map_single method
For the initial version I've decided to use custom arm_dma_ops. Extending common interface will take time, until that I wanted to have something already working.
dma_{alloc,free,mmap}_{coherent,writecombine} have been consolidated into dma_{alloc,free,mmap}_attrib what have been suggested on Linaro meeting. New attribute for WRITE_COMBINE memory have been introduced.
- moved all inline ARM dma-mapping related operations to
arch/arm/mm/dma-mapping.c and put them as methods in generic arm_dma_ops structure. The dma-mapping.c code deinitely needs cleanup, but this is just a first step.
- Added very initial IOMMU support. Right now it is limited only to
dma_alloc_attrib, dma_free_attrib and dma_mmap_attrib. It have been tested with s5p-fimc driver on Samsung Exynos4 platform.
- Adapted Samsung Exynos4 IOMUU driver to make use of the introduced
iommu_dma proposal.
This patch series contains only patches for common dma-mapping part. There is also a patch that adds driver for Samsung IOMMU controller on Exynos4 platform. All required patches are available on:
git://git.infradead.org/users/kmpark/linux-2.6-samsung dma-mapping branch
Git web interface: http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/...
Future:
- Add all missing operations for IOMMU mappings (map_single/page/sg,
sync_*)
- Move sync_* operations into separate function for better code sharing
between iommu and non-iommu dma-mapping code
- Splitting out dma bounce code from non-bounce into separate set of
dma methods. Right now dma-bounce code is compiled conditionally and spread over arch/arm/mm/dma-mapping.c and arch/arm/common/dmabounce.c.
- Merging dma_map_single with dma_map_page. I haven't investigated
deeply why they have separate implementation on ARM. If this is a requirement then dma_map_ops need to be extended with another method.
Fix dma_alloc to unmap from linear mapping.
Convert IO address space management code from gen-alloc to some
simpler bitmap based solution.
- resolve issues that might araise during discussion& comments
Please note that this is very early version of patches, definitely NOT intended for merging. I just wanted to make sure that the direction is right and share the code with others that might want to cooperate on dma-mapping improvements.
Best regards