Hi Javier On Tue, 6 Sep 2011, javier Martin wrote: > Hi, > we are planning to add support to H.264/MPEG4 encoder inside the > i.MX27 to v4l2. It is mainly a hardware module that has the following > features: > > - It needs two input buffers (current frame and previous frame). > - It produces a third buffer as output, containing the encoded frame, > and generates an IRQ when that happens. > - Previous three buffers need contiguous physical memory addresses and > probably some alignment requirements. > - It needs an external firmware to be loaded in another contiguous > memory buffer. > > I would like to know what is your opinion on this, what v4l2 framework > should we use to deal with it, etc... I guess Multi Format Codec 5.1 > driver for s5pv210 and exynos4 SoC is the most similar piece of HW > I've found so far but it has not yet entered mainline [1] > > Note that mx2_camera driver is still using soc-camera framework and > soc-camera doesn't seem to be ready for integration with pad level API > [2]. For that reason we think we could develop this VPU driver > separately. (The following is my understanding and opinion, all corrections welcome) The MC API is important, when data can be passed directly between modules, using some internal busses. I.e., if you could just configure your VPU to receive the data directly from the camera capture module, without the use of memory buffers, then yes, you would want an MC-like API, and an ability to connect the camera module to the VPU using pads and links and configure each entity from the user-space separately, maintaining the format compatibility along the links. In your case, however, the VPU uses memory buffers. I.e., what you want is some zero-copy buffer passing from the camera module to the VPU. I don't think the MC API is very helpful in this situation. With the currently available options you want to use USERPTR buffers and pass them from the source to the sink in your user-space application. There are also some buffer-sharing options approaching, but as long as this is just one application, that tosses buffers between two devices, you, probably, don't need those very much either. So, this looks like a "simple" mem2mem driver case to me. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
