[Linaro-mm-sig] Memory Management Discussion

[Zach Pfeffer]

Speaking of Graphics and Multimedia - we may want to discuss IOMMU
APIs and distributed memory management. These devices are becoming
more prevalent and having a standard way of working with them would be
useful.

I did a little of this work at Qualcomm and pushed some soundly
rejected patches to the kernel, see "mm: iommu: An API to unify IOMMU,
CPU and device memory management."

-Zach

On 19 April 2011 20:52, Clark, Rob <rob at ti.com> wrote:
> On Mon, Apr 18, 2011 at 9:45 AM, Sree Kumar <sreeon at gmail.com> wrote:
>> Thanks Jesse for initiating the mailing list.
>>
>> We need to address the requirements of Graphics and Multimedia Accelerators
>> (IPs).
>> What we really need is a permanent solution (at upstream) which accommodates
>> the following requirements and conforms to Graphics and Multimedia use
>> cases.
>>
>> 1.Mechanism to map/unmap the memory. Some of the IPs’ have the ability to
>> address virtual memory and some can address only physically contiguous
>> address space. We need to address both these cases.
>> 2.Mechanism to allocate and release memory.
>> 3.Method to share the memory (ZERO copy is a MUST for better performance)
>> between different device drivers (example output of camera to multimedia
>> encoder).
>> 4.Method to share the memory with different processes in userspace. The
>> sharing mechanism should include built-in security features.
>>
>> Are there any special requirements from V4L or DRM perspectives?
>
> From DRI perspective.. I guess the global buffer name is restricted to
> a 4 byte integer, unless you change the DRI proto..
>
> Authentication hooks for the driver (on x11 driver side) are for a
> single authentication covering all buffers shared between client and
> server, and is done by 4 byte token exchange between client and
> server.  I've not had time yet to look more closely at the
> authentication aspect of ION.
>
> Those are just things off the top of my head, hopefully someone else
> from X11 world chimes in with whatever else I missed.  But I guess
> most important thing is whether or not it can fit within existing DRI
> protocol.  If it does, then the drivers on client and server side
> could use whatever..
>
> BR,
> -R
>
>
>> Thanks,
>> Sree
>>
>> _______________________________________________
>> Linaro-mm-sig mailing list
>> Linaro-mm-sig at lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>>
>>
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>