Hello,
On Monday, June 20, 2011 4:31 PM Subash Patel wrote:
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.
I want to move enabling and disabling SYSMMU completely to the runtime_pm framework. As You can notice, the updated SYSMMU driver automatically becomes a parent of respective multimedia device and a child of the power domain to which both belongs. This means that sysmmu will operate only when multimedia device is enabled, what really makes sense. The sysmmu driver will need to be updated not to poke into the registers if it is disabled, but this should be really trivial change.
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?
This was just a first version of dma-mapping and IOMMU integration, just to show the development road and start the discussion. Of course in the final version support for pages larger than 4KiB is highly expected. We can even reuse the recently posted CMA to allocate large pages for IOMMU to improve the performance and make sure that the framework will be able to allocate such pages even if the device is running for long time and memory got fragmented by typically movable pages.
Best regards