[Linaro-mm-sig] Memory Management Discussion

[Zach Pfeffer]

I think we should. We need a better allocator, in-part, because of all
of these SoC engines.

On 19 April 2011 23:38, Kyungmin Park <kmpark at infradead.org> wrote:
> On Wed, Apr 20, 2011 at 1:30 PM, Zach Pfeffer <zach.pfeffer at linaro.org> wrote:
>> 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
>> manager discussion.
>
> Now we're working on the suggested method, DMA APIs for IOMMUs. So can
> you discuss it together?
> http://www.spinics.net/lists/linux-media/msg31524.html
>
>>
>> On 19 April 2011 23:19, Kyungmin Park <kmpark at infradead.org> wrote:
>>> Please see the following URLs
>>> https://lkml.org/lkml/2011/4/19/172
>>>
>>> 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
>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> Linaro-mm-sig mailing list
>>>> Linaro-mm-sig at lists.linaro.org
>>>> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>>>>
>>>
>>
>