[Linaro-mm-sig] ION interfaces - support for IOMMU

[Hiroshi Doyu]

Hi Nishanth,

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:
> http://lists.linaro.org/pipermail/linaro-mm-sig/2012-January/001009.html
> 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
> receiver.
>    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