Hello Marek, > -----Original Message----- > From: Marek Szyprowski [mailto:m.szyprowski@xxxxxxxxxxx] > Sent: Tuesday, July 17, 2012 5:04 PM > To: 'Inki Dae'; 'Subash Patel' > Cc: 'Prathyush K'; dri-devel@xxxxxxxxxxxxxxxxxxxxx; prathyush@xxxxxxxxxxxx > 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@xxxxxxxxxx] > > > Sent: Friday, July 13, 2012 3:58 PM > > > To: Inki Dae > > > Cc: 'Prathyush K'; dri-devel@xxxxxxxxxxxxxxxxxxxxx; > > prathyush@xxxxxxxxxxxx; > > > m.szyprowski@xxxxxxxxxxx > > > 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@xxxxxxxxxxx] > > > >> Sent: Wednesday, July 11, 2012 6:40 PM > > > >> To: dri-devel@xxxxxxxxxxxxxxxxxxxxx > > > >> Cc: prathyush@xxxxxxxxxxxx; m.szyprowski@xxxxxxxxxxx; > > > > inki.dae@xxxxxxxxxxx; > > > >> subash.ramaswamy@xxxxxxxxxx > > > >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
