The update to the wiki based upon the ELC talk has those 3, but breaks up the mapping into separate in-kernel and user-space mapping issues. Oh, and in the discussion, I think we were referring to buffer flows as configuration, but it seems the same to me. At any rate, I think we've captured the ideas and some of the mechanisms that address them (or attempt to). Could use more detail, though.
cheers, Jesse
On Wed, Apr 20, 2011 at 2:24 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
That's true.
I think there's some value in splitting the discussion up into 3 areas:
Allocation Mapping Buffer flows
There seems to be a general design disconnect between the way Linux deals with buffer mapping (one mapper at a time, buffers are mapped and unmapped as they flow through the system) and the way users actually want things to work (sharing a global buffer that one entity writes to and another reads without unmapping each time).
Perhaps there's a solution that will give users the allusion of shared mappings while ensuring correctness if those mappings are different (something on-demand perhaps).
-Zach
On 20 April 2011 10:13, Jordan Crouse jcrouse@codeaurora.org wrote:
On 04/19/2011 10:12 PM, Zach Pfeffer 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
As we talked during the meeting at ELC, IOMMU is important, but I think that there is broad agreement to consolidate (eventually) on the standard APIs. I still think that the memory allocation problem is the more interesting one because it affects everybody equally, MMU or not. Not that I want to shut down debate or anything, I just don't want to distract us from the larger problem that we face.
Jordan
On 19 April 2011 20:52, Clark, Robrob@ti.com wrote:
On Mon, Apr 18, 2011 at 9:45 AM, Sree Kumarsreeon@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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
-- Jordan Crouse Qualcomm Innovation Center Qualcomm Innovation Center is a member of Code Aurora Forum
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig