From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subash Patel Subject: Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM Date: Fri, 13 Jul 2012 12:27:36 +0530 Message-ID: <4FFFC6E0.9040108@linaro.org> References: <1341999603-28316-1-git-send-email-prathyush.k@samsung.com> <002b01cd60c2$50df3620$f29da260$%dae@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-gh0-f177.google.com (mail-gh0-f177.google.com [209.85.160.177]) by gabe.freedesktop.org (Postfix) with ESMTP id 4D765A102C for ; Thu, 12 Jul 2012 23:57:41 -0700 (PDT) Received: by ghbf11 with SMTP id f11so3548233ghb.36 for ; Thu, 12 Jul 2012 23:57:41 -0700 (PDT) In-Reply-To: <002b01cd60c2$50df3620$f29da260$%dae@samsung.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Inki Dae Cc: m.szyprowski@samsung.com, dri-devel@lists.freedesktop.org, 'Prathyush K' List-Id: dri-devel@lists.freedesktop.org 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 > >> The proposed method is to create a common IOMMU mapping during drm init. >> This >> mapping is then attached to all of the drm devices including the drm >> device. >> [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM >> >> During the probe of drm fimd, the driver retrieves a 'sysmmu' field >> in the device node for fimd. If such a field exists, the driver retrieves >> the >> platform device of the sysmmu device. This sysmmu is set as the sysmmu >> for fimd. The common mapping created is then attached to fimd. >> This needs to be done for all the other devices (hdmi, vidi etc). >> [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node >> [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd >> >> During DRM's probe which happens last, the common mapping is set to its >> archdata >> and iommu ops are set as its dma ops. This requires a modification in the >> dma-mapping framework so that the iommu ops can be visible to all drivers. >> [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops >> [PATCH 5/7] drm/exynos: attach drm device with common drm mapping >> >> Currently allocation and free use the iommu framework by calling >> dma_alloc_writecombine and dma_free_writecombine respectively. >> For mapping the buffers to user space, the mmap functions assume that >> the buffer is contiguous. This is modified by calling >> dma_mmap_writecombine. >> [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function >> [PATCH 7/7] Add IOMMU support for mapping gem object >> >> The device tree based patches are based on Leela's patch which was posted >> last week for adding DT support to DRM FIMD. The patch to add sysmmu >> field is for reference only and will be posted to the device tree >> mailing list. Same with the rename and export iommu_ops patch. >> >> These patches are tested on Exynos5250 SMDK board and tested with modetest >> from libdrm tests. >> >> Prathyush K (7): >> drm/exynos: create common IOMMU mapping for DRM >> ARM: EXYNOS5: add sysmmu field to fimd device node >> drm/exynos: add IOMMU support to drm fimd >> ARM: dma-mapping: rename and export iommu_ops >> drm/exynos: attach drm device with common drm mapping >> drm/exynos: Add exynos drm specific fb_mmap function >> drm/exynos: Add IOMMU support for mapping gem object >> >> arch/arm/boot/dts/exynos5250.dtsi | 1 + >> arch/arm/include/asm/dma-mapping.h | 1 + >> arch/arm/mm/dma-mapping.c | 5 ++- >> drivers/gpu/drm/exynos/exynos_drm_core.c | 3 ++ >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 30 ++++++++++++++++ >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 +++++ >> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 16 ++++++++ >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 >> ++++++++++++++++++++++++++++- >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 ++++++++---------- >> 9 files changed, 133 insertions(+), 22 deletions(-)