Hello,
On Monday, July 16, 2012 3:47 PM Inki Dae wrote:
-----Original Message----- From: Subash Patel [mailto:subash.ramaswamy@linaro.org] Sent: Friday, July 13, 2012 3:58 PM To: Inki Dae Cc: 'Prathyush K'; dri-devel@lists.freedesktop.org;
prathyush@chromium.org;
m.szyprowski@samsung.com Subject: Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
On 07/13/2012 12:09 PM, Inki Dae wrote:
-----Original Message----- From: Prathyush K [mailto:prathyush.k@samsung.com] Sent: Wednesday, July 11, 2012 6:40 PM To: dri-devel@lists.freedesktop.org Cc: prathyush@chromium.org; m.szyprowski@samsung.com;
inki.dae@samsung.com;
subash.ramaswamy@linaro.org Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
The dma-mapping framework needs a IOMMU mapping to be created for the device which allocates/maps/frees the non-contig buffer. In the DRM framework, a gem buffer is created by the DRM virtual device and not directly by any of the physical devices (FIMD, HDMI etc). Each gem
object
can be set as a framebuffer to one or many of the drm devices. So a gem object cannot be allocated for any one device. All the DRM devices
should
be able to access this buffer.
It's good to use unified iommu table so I agree to your opinion but we
don't
decide whether we use dma mapping api or not. now dma mapping api has
one
issue. in case of using iommu with dma mapping api, we couldn't use physically contiguous memory region with iommu. for this, there is a case that we should use physically contiguous memory region with iommu. it is because
we
sometime may use mfc(hw video codec) with secure zone such as ARM
TrustZone.
Then, it needs physically contiguous memory region.
Thanks, Inki Dae
I agree. In the mainline code, as of now only the arm_dma_ops has the support allocating from the CMA. But in the function arm_iommu_alloc_attrs(), there is no way to know if the device had declared a contiguous memory range. The reason, we don't store that cookie into the device during the dma_declare_contiguous(). So is it advisable to store such information like mapping(in the iommu operations) in the device.archdata?
Regards, Subash
There was my missing point. dma mapping api with iommu tries to allocate pages contiguously if possible. as HW Video codec above, there is the case that physically contiguous memory region is need necessarily but it seems like that now dma mapping api doesn't guarantee fully physically contiguous memory region(for example, if physically contiguous memory allocation is failed then it should return an error so that we can check it)
Marek, for this, could you please give us comments?
If I understand right, you want to be able to allocate both physically contiguous and physically discontiguous memory buffers for the same device with IOMMU. This can be achieved by adding a new attribute to dma-mapping subsystem, let's call it DMA_ATTR_FORCE_CONTIGUOUS, which forces dma-mapping to allocate the buffer from the CMA area or reserved memory (depending on what is available) instead of assembling it from individual pages.
Would it solve your problem?
Best regards