[Linaro-mm-sig] ION interfaces - support for IOMMU
hdoyu at nvidia.com
Mon Apr 30 05:21:24 UTC 2012
On Sun, 29 Apr 2012 21:56:26 +0200
Nishanth Peethambaran <nishanth.peethu at gmail.com> wrote:
> Hi Rebecca, Doyu,
> I am sending this mail related to the mailchain seen in the link:
> I am not sure where to post the query. If I am supposed to post in a
> mail-list, let me know and
> I shall post it there.
I think that "linaro-mm-sig at lists.linaro.org" would be the best for
further discussion, putting linaro-mm-sig on Cc:.
> I am also trying to use ION for IOMMU and have some comments on ION in
> general and specific to IOMMU usage.
> 1. Isn't 2 heap types sufficient - physically contiguous and non-contiguous?
> We could treat physical carveout and sytem_contig(kmalloc) as two
> implementations of physcially contiguous type
> and add the heaps with separate ids. Order of using them would be
> as ION currently does - order of registration of heap.
> IOMMU heap type also won't be needed as that is just a different
> implementation of system heap (no kernel map at allocation
> time). Please correct me if I am missing something.
> 2. The user space interface does not support exposing a dma_addr_t to
> user space. We could add this using custom ioctl.
> But, shouldn't this be a standard interface. For example, to
> protect/hide the graphics core IP details, platfrom provider would
> prefer to generate graphics core program from user space (license
> requirements) and only pass the final buffer containing
> the program to the driver. If an IOMMU is used, the dma/iommu
> address mapping would be needed in user space to embed
> few pointers in the graphics program.
> 3. With the current ION implementation, how do we keep user space
> code/drivers independent of platform supporting IOMMU or not?
> For example, CMA is supported by the platform but want to restrict
> buffers allocated from CMA only if necessary (to avoid migration
> overheads). How does a client decide whether to request for
> physically contiguous buffers (CMA) ot IOMMU buffers (buddy allocator)
> In one platform, the buffer could be shared with an IP with IOMMU
> support (eg: camera and codec both supporting IOMMU) - CMA not needed.
> In another platform the buffer may have to be shared with an IP
> which works on physical address space. buffer has to be
> shared with an IP which does not support IOMMU(to avoid migrations)
> - we need to use physically contiguous heap(CMA).
> I see dma buf sharing API has a callback to exporter at attachment
> time so that exporter can pass of fail the sharing based on the
> Don't we need something similar and more?
> ION version referred:
> commit 3fe24366a40147d7c776e1f291193fd3b61f217d
> Author: Iliyan Malchev <malchev at google.com>
> Date: Tue Aug 9 14:42:08 2011 -0700
> - Nishanth Peethambaran
More information about the Linaro-mm-sig