All of lore.kernel.org
 help / color / mirror / Atom feed
From: Subash Patel <subash.ramaswamy@linaro.org>
To: Inki Dae <inki.dae@samsung.com>
Cc: m.szyprowski@samsung.com, dri-devel@lists.freedesktop.org,
	'Prathyush K' <prathyush.k@samsung.com>
Subject: Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
Date: Fri, 13 Jul 2012 12:27:36 +0530	[thread overview]
Message-ID: <4FFFC6E0.9040108@linaro.org> (raw)
In-Reply-To: <002b01cd60c2$50df3620$f29da260$%dae@samsung.com>

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(-)

  reply	other threads:[~2012-07-13  6:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-11  9:39 [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM Prathyush K
2012-07-11  9:39 ` [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM Prathyush K
2012-07-11  9:39 ` [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node Prathyush K
2012-07-11  9:39 ` [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd Prathyush K
2012-07-13  6:50   ` Inki Dae
2012-07-11  9:40 ` [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops Prathyush K
2012-07-11  9:40 ` [PATCH 5/7] drm/exynos: attach drm device with common drm mapping Prathyush K
2012-07-13  6:53   ` Inki Dae
2012-07-11  9:40 ` [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function Prathyush K
2012-07-13  7:07   ` Inki Dae
2012-07-11  9:40 ` [PATCH 7/7] drm/exynos: Add IOMMU support for mapping gem object Prathyush K
2012-07-13  7:33   ` Inki Dae
2012-07-13  6:39 ` [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM Inki Dae
2012-07-13  6:57   ` Subash Patel [this message]
2012-07-16 13:46     ` Inki Dae
2012-07-17  8:03       ` Marek Szyprowski
2012-07-17  8:58         ` Inki Dae

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FFFC6E0.9040108@linaro.org \
    --to=subash.ramaswamy@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=inki.dae@samsung.com \
    --cc=m.szyprowski@samsung.com \
    --cc=prathyush.k@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.