On Fri, Jun 08, 2012 at 01:32:27PM +0200, javier Martin wrote: > On 8 June 2012 11:23, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > On Fri, Jun 08, 2012 at 11:02:31AM +0200, javier Martin wrote: > > 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". Since we already know that this is a codadx6 we should name it codadx instead of anything vpu specific. I also suggest codadx instead of anything more specific like codadx6 since we should rather motivate people to merge other coda cores into this driver. > - 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. This sounds like a plan. I am happy that you are willing to keep an eye on our driver. It would be a pity to have unnecessary barriers for merging codadx9 stuff later. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- 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
