Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng

[Andy Walls <awalls@radix.net>]

On Mon, 2008-12-01 at 14:45 +0100, Hans Verkuil wrote:
> On Monday 01 December 2008 14:29:53 Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Monday 01 December 2008, Hans Verkuil wrote:
> > > On Monday 01 December 2008 13:31:25 Laurent Pinchart wrote:
> > > > On Monday 01 December 2008, Hans Verkuil wrote:
> > > > > Hi Mauro,
> > > > >
> > > > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
> > > > > for the following:
> > > > >
> > > > > - v4l2: add v4l2_device and v4l2_subdev structs to the v4l2
> > > > > framework. - v4l2-common: add i2c helper functions
> > > > > - cs53l32a: convert to v4l2_subdev.
> > > > > - cx25840: convert to v4l2_subdev.
> > > > > - m52790: convert to v4l2_subdev.
> > > > > - msp3400: convert to v4l2_subdev.
> > > > > - saa7115: convert to v4l2_subdev.
> > > > > - saa7127: convert to v4l2_subdev.
> > > > > - saa717x: convert to v4l2_subdev.
> > > > > - tuner: convert to v4l2_subdev.
> > > > > - upd64031a: convert to v4l2_subdev.
> > > > > - upd64083: convert to v4l2_subdev.
> > > > > - vp27smpx: convert to v4l2_subdev.
> > > > > - wm8739: convert to v4l2_subdev.
> > > > > - wm8775: convert to v4l2_subdev.
> > > > > - ivtv/ivtvfb: convert to v4l2_device/v4l2_subdev.
> > > > >
> > > > > All points raised in reviews are addressed so I think it is
> > > > > time to get this merged so people can start to use it.
> > > >
> > > > Does linuxtv.org and Mercurial provide the necessary
> > > > infrastructure to integrate those changes into the v4l-dvb
> > > > repository while not pushing them upstream yet ? I'd like to see
> > > > more people testing (and breaking and fixing :-)) your changes
> > > > before they reach the mainline kernel.
> > >
> > > That's basically why I want this to go into the v4l-dvb repository:
> > > this makes it easier for people to start working with it. It
> > > doesn't affect existing drivers, except for the i2c driver changes
> > > and those changes are just transforming a big switch to a set of
> > > functions. So I really consider this a pretty low-risk merge.
> > >
> > > If someone is willing to do some testing with my tree in the next
> > > two weeks then I don't mind waiting, but it's been in development
> > > now from early September (if not earlier) and been reviewed several
> > > times. In addition, ivtv has been modified to work with it and that
> > > driver uses more sub-devices by far than any other driver.
> > >
> > > I don't know what more I can do, to be honest.
> >
> > I am all for pushing the changes to the v4l-dvb repository so they
> > can get broader testing. I am, however, a bit more concerned about
> > pushing the changes to Linus yet.
> 
> They will of course go to linux-next and end up in 2.6.29 when the merge 
> window opens. It's obviously not for 2.6.28.
> 
> > Shouldn't it wait until you convert 
> > other drivers and make the v4l2_device (infra)structure more
> > powerful, as you announced you would ? There will probably be API/ABI
> > breakage then, it patches will probably benefit from a few iterations
> > in v4l-dvb before we push them to mainline.
> 
> Yes, I want to add more features to them, but those additions need a lot 
> more thought. Currently the new subdev support is the most important 
> feature of this and the reason is the introduction of v4l2-int-device 
> and soc-camera: both are recent arrivals and neither was reviewed 
> properly. As a result we now see i2c drivers arriving that can only 
> work with v4l2-int-device or with soc-camera infrastructure. This is 
> very undesirable and must be fixed asap. And v4l2_subdev is the way to 
> do this. Existing i2c drivers are not affected and when these changes 
> are in we can start to replace v4l2-int-device.h and to modify 
> soc-camera to use v4l2_subdev as well.
> 
> In addition, these changes make it easier as well to use the new i2c API 
> in bridge drivers (in 2.6.29 the old-style I2C probing will be 
> deprecated, so we need to convert). So we get many benefits with just 
> these changes.
> 
> Of course, I want to add more v4l2 framework support to these new 
> structures, but I don't have any code yet for that anyway, just lots of 
> ideas. Start simple, then expand.

Only if you want small successes (or failures) instead of spectacular
failures. :)

http://en.wikipedia.org/wiki/Gall's_law

Regards,
Andy

> > I don't know if that's possible at all, or if all changes in v4l-dvb
> > are automatically selected for a push to the git repository whenever
> > Mauro triggers the hg->git process.
> 
> Well, they go to linux-next, but is that a problem?
> 
> Regards,
> 
> 	Hans
> 
> >
> > Best regards,
> >
> > Laurent Pinchart
> 
> 
>