On Wed November 28 2012 20:30:21 Greg Kroah-Hartman wrote:

On Wed, Nov 28, 2012 at 08:18:20PM +0100, Hans Verkuil wrote:

quoted

On Wed November 28 2012 18:22:48 Greg Kroah-Hartman wrote:

quoted

On Wed, Nov 28, 2012 at 10:18:02AM -0200, Mauro Carvalho Chehab wrote:

quoted

Em Wed, 28 Nov 2012 12:56:10 +0100
Hans Verkuil [off-list ref] escreveu:

quoted

On Wed 28 November 2012 12:45:37 Dan Carpenter wrote:

quoted

I wish people wouldn't submit big patches right before the merge
window opens...  :/ It's better to let it sit in linux-next for a
couple weeks so people can mess with it a bit.

It's been under review for quite some time now, and the main change since
the last posted version is that this is now moved to staging/media.

So it is not yet ready for prime time, but we do want it in to simplify
the last remaining improvements needed to move it to drivers/media.

"last remaining improvements"? I didn't review the patchset, but
the TODO list seems to have several pending stuff there:

+- User space interface refinement
+        - Controls should be used when possible rather than private ioctl
+        - No enums should be used
+        - Use of MC and V4L2 subdev APIs when applicable
+        - Single interface header might suffice
+        - Current interface forces to configure everything at once
+- Get rid of the dm365_ipipe_hw.[ch] layer
+- Active external sub-devices defined by link configuration; no strcmp
+  needed
+- More generic platform data (i2c adapters)
+- The driver should have no knowledge of possible external subdevs; see
+  struct vpfe_subdev_id
+- Some of the hardware control should be refactorede
+- Check proper serialisation (through mutexes and spinlocks)
+- Names that are visible in kernel global namespace should have a common
+  prefix (or a few)

From the above comments, both Kernelspace and Userspace APIs require 
lots of work.

And that's why it is in staging. Should a long TODO list now suddenly
prevent staging from being used? In Barcelona we discussed this and the
only requirement we came up was was that it should compile.

Yes, that's all I care about in staging, but as I stated, I don't
maintain drivers/staging/media/ that area is under Mauro's control
(MAINTAINERS even says this), and I'm a bit leery of going against the
wishes of an existing subsystem maintainer for adding staging drivers
that tie into their subsystem.

So if you get Mauro's approval, I'll be glad to queue it up.

Just for the record, my comments were addressed to Mauro, not to you.
I should have stated that in my mail explicitly. As you said, it's
Mauro's decision.

Regards,

	Hans