Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

[Mauro Carvalho Chehab <mchehab@redhat.com>]

It seems that there are too many miss understandings or maybe we're just
talking the same thing on different ways.

So, instead of answering again, let's re-start this discussion on a
different way.

One of the requirements that it was discussed a lot on both mailing
lists and on the Media Controllers meetings that we had (or, at least
in the ones where I've participated) is that:

	"A pure V4L2 userspace application, knowing about video device
	 nodes only, can still use the driver. Not all advanced features 
	 will be available."

This is easily said than done. Also, different understandings can be
obtained by a simple phrase like that.

The solution for this problem is to make a compliance profile that
drivers need to implement. We should define such profile, change
the existing drivers to properly implement it and enforce it for the
newcoming drivers.

Btw, I think we should also work on a profile for other kinds of hardware
as well, but the thing is that, as some things can now be implemented
using two different API's, we need to define the minimal requirements
for the V4L2 implementation.


For me, the above requirement means that, at least, the following features
need to be present:

1) The media driver should properly detect the existing hardware and
should expose the available sensors for capture via the V4L2 API.

For hardware development kits, it should be possible to specify the
hardware sensor(s) at runtime via some tool at the v4l-utils tree 
(or on another tree hosted at linuxtv.org or clearly indicated at
the Kernel tree Documentation files) or via a modprobe parameter.

2) Different sensors present at the hardware may be exposed either
via S_INPUT or, if they're completely independent, via two different
node interface;

3) The active sensor basic controls to adjust color, bright, aperture time
and exposition time, if the hardware directly supports them;

4) The driver should implement the streaming ioctls and/or the read() method;

5) It should be possible to configure the frame rate, if the sensor supports it;

6) It should be possible to configure the crap area, if the sensor supports it.

7) It should be possible to configure the format standard and resolution

...
(the above list is not exhaustive. It is just a few obvious things that are
clear to me - I'm almost sure that I've forgot something).

We'll also end by having some optional requirements, like the DV timings ioctls
that also needs to be covered by the SoC hardware profile.

In practice, the above requirements should be converted into a list of features
and ioctl's that needs to be implemented on every SoC driver that implements
a capture or output video streaming device.

My suggestion is that we should start the discussions by filling the macro
requirements. Once we agree on that, we can make a list of the V4L and MC
ioctl's and convert them into a per-ioctl series of requirements.

Regards,
Mauro