[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM

[Inki Dae]

Hello Marek,


> -----Original Message-----
> From: Marek Szyprowski [mailto:m.szyprowski at samsung.com]
> Sent: Tuesday, July 17, 2012 5:04 PM
> To: 'Inki Dae'; 'Subash Patel'
> Cc: 'Prathyush K'; dri-devel at lists.freedesktop.org; prathyush at chromium.org
> Subject: RE: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
> 
> Hello,
> 
> On Monday, July 16, 2012 3:47 PM Inki Dae wrote:
> 
> > > -----Original Message-----
> > > From: Subash Patel [mailto:subash.ramaswamy at linaro.org]
> > > Sent: Friday, July 13, 2012 3:58 PM
> > > To: Inki Dae
> > > Cc: 'Prathyush K'; dri-devel at lists.freedesktop.org;
> > prathyush at chromium.org;
> > > m.szyprowski at 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 at samsung.com]
> > > >> Sent: Wednesday, July 11, 2012 6:40 PM
> > > >> To: dri-devel at lists.freedesktop.org
> > > >> Cc: prathyush at chromium.org; m.szyprowski at samsung.com;
> > > > inki.dae at samsung.com;
> > > >> subash.ramaswamy at 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?
> 

Yes, it does. we need DMA_ATTR_FORCE_CONGIGUOUS feature so that the CMA can
guarantee fully physically contiguous memory allocation in some case.

Thanks,
Inki Dae

> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center