Hi,
On Thursday 24 February 2011 15:48:20 Kyungmin Park wrote:
On Thu, Feb 24, 2011 at 10:17 PM, Hans Verkuil hverkuil@xs4all.nl wrote:
On Tuesday, February 22, 2011 03:44:19 Clark, Rob wrote:
On Fri, Feb 18, 2011 at 10:39 AM, Robert Fekete wrote:
Hi,
In order to expand this knowledge outside of Linaro I took the Liberty of inviting both linux-media@vger.kernel.org and gstreamer-devel@lists.freedesktop.org. For any newcomer I really recommend to do some catch-up reading on http://lists.linaro.org/pipermail/linaro-dev/2011-February/thread.html ("v4l2 vs omx for camera" thread) before making any comments. And sign up for Linaro-dev while you are at it :-)
To make a long story short: Different vendors provide custom OpenMax solutions for say Camera/ISP. In the Linux eco-system there is V4L2 doing much of this work already and is evolving with mediacontroller as well. Then there is the integration in Gstreamer...Which solution is the best way forward. Current discussions so far puts V4L2 greatly in favor of OMX. Please have in mind that OpenMAX as a concept is more like GStreamer in many senses. The question is whether Camera drivers should have OMX or V4L2 as the driver front end? This may perhaps apply to video codecs as well. Then there is how to in best of ways make use of this in GStreamer in order to achieve no copy highly efficient multimedia pipelines. Is gst-omx the way forward?
just fwiw, there were some patches to make v4l2src work with userptr buffers in case the camera has an mmu and can handle any random non-physically-contiguous buffer.. so there is in theory no reason why a gst capture pipeline could not be zero copy and capture directly into buffers allocated from the display
V4L2 also allows userspace to pass pointers to contiguous physical memory. On TI systems this memory is usually obtained via the out-of-tree cmem module.
Certainly a more general way to allocate buffers that any of the hw blocks (display, imaging, video encoders/decoders, 3d/2d hw, etc) could use, and possibly share across-process for some zero copy DRI style rendering, would be nice. Perhaps V4L2_MEMORY_GEM?
There are two parts to this: first of all you need a way to allocate large buffers. The CMA patch series is available (but not yet merged) that does this. I'm not sure of the latest status of this series.
Still ARM maintainer doesn't agree these patches since it's not solve the ARM memory different attribute mapping problem. but try to send the CMA v9 patch soon.
We need really require the physical memory management module. Each chip vendors use the their own implementations. Our approach called it as CMA, others called it as cmem, carveout, hwmon and so on.
I think Laurent's approaches is similar one.
Just for the record, my global buffers pool RFC didn't try to solve the contiguous memory allocation problem. It aimed at providing drivers (and applications) with an API to allocate and use buffers. How the memory is allocated is outside the scope of the global buffers pool, CMA makes perfect sense for that.
We will try it again to merge CMA.