[RFC] Support for H.264/MPEG4 encoder (VPU) in i.MX27.

[javier Martin]

On 8 June 2012 11:23, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Fri, Jun 08, 2012 at 11:02:31AM +0200, javier Martin wrote:
>> Hi,
>> I've checked this matter with a colleague and we have several reasons
>> to doubt that the i.MX27 and the i.MX53 can share the same driver for
>> their Video Processing Units (VPU):
>>
>> 1. The VPU in the i.MX27 is a "codadx6" with support for H.264, H.263
>> and MPEG4-Part2 [1]. Provided Freescale is using the same IP provider
>> for i.MX53 and looking at the features that the VPU in this SoC
>> supports (1080p resolution, VP8) we are probably dealing with a "coda
>> 9 series" [2].
>>
>> 2. An important part of the functionality for controlling the
>> "codadx6" is implemented using software messages between the main CPU
>> and the VPU, this means that a different firmware loaded in the VPU
>> can substantially change the way it is handled. As previously stated,
>> i.MX27 and i.MX53 have different IP blocks and because of this, those
>> messages will be very different.
>>
>> For these reasons we suggest that we carry on developing different
>> drivers for the i.MX27 and the i.MX53. Though it's true that both
>> drivers could share some overhead given by the use of mem2mem
>> framework, I don't think this is a good enough reason the merge them.
>>
>> By the way, driver for the VPU in the i.MX27 will be called
>> "codadx6"[3], I suggest you call your driver "coda9" to avoid
>> confusion.
>
> Well, our driver works on i.MX27 and i.MX5. Yes, it needs some
> abstraction for different register layouts and different features, but
> the cores behave sufficiently similar that it makes sense to share the
> code in a single driver.

Hi Sascha,

>From our point of view the current situation is the following:
We have a very reliable driver for the VPU which is not mainline but
it's been used for two years in our products. This driver only
supports encoding in the i.MX27 chip.
In parallel, you have a a multichip driver in progress which is not
mainline either, not fully V4L2 compatible and not tested for i.MX27.
[1]
At the same time, we have a driver in progress for i.MX27 encoding
only which follows V4L2 mem2mem framework. [2].

The first thing to decide would be which of both drivers we take as a
base for final mainline developing.
In our view, cleaning up driver from Pengutronix [1] would imply a lot
of effort of maintaining code that we cannot really test (i.MX5,
i.MX6) whereas if we continue using [2] we would have something valid
for i.MX27 much faster. Support for decoding and other chips could be
added later.

The second thing would be whether we keep on developing or whether we
should wait for you to have something in mainline. We have already
allocated resources to the development of the driver and long-term
testing to achieve product level reliability. Pengutronix does not
seem to be committed to developing the features relevant to our
product (lack of YUV420 support for i.MX27 camera driver[6]) nor
committed to any deadline (lack of answers or development on dmaengine
for i.MX27[4][5]). Moreover, development effort is only 50% of the
cost and we would still have to spend a lot of time checking the video
stream manually in different real-rife conditions (only extensive
testing allowed us to catch the "P frame marked as IDR" bug [7]).

As a conclusion we propose that we keep on developing our driver for
encoding in the i.MX27 VPU under the following conditions:
- We will provide a more generic name for the driver than "codadx6",
maybe something as "imx_vpu".
- We will do an extra effort and will study your code in [1] in order
to provide a modular approach that makes adding new functionality (new
chips or decoding) as easy as possible while making obvious that
further patches do not break support for encoding in the i.MX27.

Does it sound reasonable for you?

Regards.

[1] git://git.pengutronix.de/git/imx/gst-plugins-fsl-vpu.git
[2] https://github.com/jmartinc/video_visstrim/tree/mx27-codadx6/drivers/media/video/codadx6
[3] http://www.spinics.net/lists/linux-media/msg37920.html
[4] http://www.spinics.net/lists/arm-kernel/msg159196.html
[5] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/087842.html
[6] http://patchwork.linuxtv.org/patch/8826/
[7] http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/49166

-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com