[Linaro-mm-sig] Memory Management Discussion
zach.pfeffer at linaro.org
Wed Apr 20 04:30:54 UTC 2011
Yeah. I wanted to list VCMM it since it seemed to get a lot of
feedback. It did everything wrong and seemed to generate a lot of "you
should do it this way" traffic, which should help the unified memory
On 19 April 2011 23:19, Kyungmin Park <kmpark at infradead.org> wrote:
> Please see the following URLs
> We (Me, Michal, Marek) tried it based on yours. but some peoples
> doesn't like it.
> Thank you,
> Kyungmin Park
> On Wed, Apr 20, 2011 at 1:12 PM, Zach Pfeffer <zach.pfeffer at linaro.org> wrote:
>> 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
>> 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."
>> 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
>>>> What we really need is a permanent solution (at upstream) which accommodates
>>>> the following requirements and conforms to Graphics and Multimedia use
>>>> 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
>>>> 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..
>>>> Linaro-mm-sig mailing list
>>>> Linaro-mm-sig at lists.linaro.org
>>> Linaro-mm-sig mailing list
>>> Linaro-mm-sig at lists.linaro.org
>> Linaro-mm-sig mailing list
>> Linaro-mm-sig at lists.linaro.org
More information about the Linaro-mm-sig