Re: [PATCH v3 0/9] Media Controller capture driver for DM365

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Nov 28, 2012 at 08:18:20PM +0100, Hans Verkuil wrote:
> On Wed November 28 2012 18:22:48 Greg Kroah-Hartman wrote:
> > On Wed, Nov 28, 2012 at 10:18:02AM -0200, Mauro Carvalho Chehab wrote:
> > > Em Wed, 28 Nov 2012 12:56:10 +0100
> > > Hans Verkuil <hansverk@cisco.com> escreveu:
> > > 
> > > > On Wed 28 November 2012 12:45:37 Dan Carpenter wrote:
> > > > > 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.

thanks,

greg k-h