[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - radio: remove uaccess include - omap24xxcam: don't set vfl_type. This should fix the daily build (for probably 10 seconds :-) ). Thanks, Hans diffstat: radio/radio-aimslab.c|1 - radio/radio-aztech.c |1 - radio/radio-cadet.c |1 - radio/radio-gemtek-pci.c |1 - radio/radio-gemtek.c |1 - radio/radio-maestro.c|1 - radio/radio-maxiradio.c |1 - radio/radio-rtrack2.c|1 - radio/radio-sf16fmi.c|1 - radio/radio-sf16fmr2.c |1 - radio/radio-terratec.c |1 - radio/radio-trust.c |1 - radio/radio-typhoon.c|1 - radio/radio-zoltrix.c|1 - video/omap24xxcam.c |1 - 15 files changed, 15 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - omap2: add OMAP2 camera driver. - v4l2-int-if: add three new ioctls for std handling and routing - v4l: add new tvp514x I2C video decoder driver Thanks to Nokia and TI for these drivers! Regards, Hans diffstat: b/linux/drivers/media/video/omap24xxcam-dma.c | 601 b/linux/drivers/media/video/omap24xxcam.c | 1908 ++ b/linux/drivers/media/video/omap24xxcam.h | 593 b/linux/drivers/media/video/tvp514x.c | 1569 + b/linux/drivers/media/video/tvp514x_regs.h| 297 b/linux/include/media/tvp514x.h | 118 + linux/drivers/media/video/Kconfig | 18 linux/drivers/media/video/Makefile|4 linux/include/media/v4l2-int-device.h |6 9 files changed, 5114 insertions(+) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
On Tuesday 02 December 2008 18:21:00 Mauro Carvalho Chehab wrote: > On Tue, 2 Dec 2008 17:58:35 +0100 > > Laurent Pinchart <[EMAIL PROTECTED]> wrote: > > > Are you meaning marking this as experimental at Kconfig? This > > > seems too complex, since we'll need to test for some var on every > > > driver that were converted, providing two KABI options for each > > > converted driver (the legacy and the v4l2_device way). This > > > doesn't seem to be a good idea, since will add a lot of extra > > > complexity to debug bugs. > > > > Not at the Kconfig level, just in the documentation (and possible > > headers). > > Ah, ok. Good point. > > > This is a work in progress. Hans wants the changes to go mainline > > to get broader testing, which is a valid reason, but I'd like to > > make sure people understand that more changes are coming. > > Maybe instead we should have a TODO list somewhere with the > programmed changes, especially at the subsystem core. Sure, I can add some comments outlining future developments in v4l2-device.h and v4l2-subdev.h. The v4l2-framework document can point to those headers (headers are easier to keep in sync when new features arrive than documentation). But I'll wait with this until I get Mauro's review back, just in case there are more changes for me to do. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
On Tue, 2 Dec 2008 17:58:35 +0100 Laurent Pinchart <[EMAIL PROTECTED]> wrote: > > Are you meaning marking this as experimental at Kconfig? This seems too > > complex, since we'll need to test for some var on every driver that were > > converted, providing two KABI options for each converted driver (the legacy > > and the v4l2_device way). This doesn't seem to be a good idea, since will > > add a lot of extra complexity to debug bugs. > > Not at the Kconfig level, just in the documentation (and possible headers). Ah, ok. Good point. > This is a work in progress. Hans wants the changes to go mainline to get > broader testing, which is a valid reason, but I'd like to make sure people > understand that more changes are coming. Maybe instead we should have a TODO list somewhere with the programmed changes, especially at the subsystem core. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
Hi Hans, On Monday 01 December 2008, Hans Verkuil wrote: > On Monday 01 December 2008 15:24:43 Laurent Pinchart wrote: [snip] > > In a few months time (probably even earlier) the v4l2_device > > structure will be reworked (and possible renamed). I'm fine with it > > going to linux-next now if we agree on the following. > > > > - We should only advocate v4l2_device usage for subdevices-aware > > video devices. Porting all drivers to v4l2_device is currently > > pointless and will only make future transitions more difficult. > > Agreed. For now it is only relevant for drivers that use subdevices. > > > - v4l2_device should be marked as experimental. I don't want to hear > > any API/ABI breakage argument in a few months time when the framework > > will evolve. > > Am I overlooking something? This API is a kernel API, not a public API. > Hence if I (or anyone else for that matter) make future changes then it > is my responsibility to adapt all other drivers that are affected at > the same time. I don't see how any of this could break compatibility. > Except for out-of-kernel drivers, of course. But that's the risk that > they always run. You're right. It might be useful to state that the API is a work in progress in the documentation, but I'll let you decide on that. > Marking this API as experimental seems pointless to me. It either works > and so is available for use or it doesn't and then it is a plain old > bug that needs to be fixed. I also know already that there will be > changes as e.g. sensors require a new ops category and v4l2_device > might need a notifier callback as well. However, I'm not going to > implement that until there is also a driver that uses it (adding > functionality to an internal API just because it might be needed in the > future is a really bad idea). Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
Hi Mauro, On Monday 01 December 2008, Mauro Carvalho Chehab wrote: > Hi Hans, > > On Mon, 1 Dec 2008 15:24:43 +0100 > > Laurent Pinchart <[EMAIL PROTECTED]> wrote: [snip] > > In a few months time (probably even earlier) the v4l2_device structure > > will be reworked (and possible renamed). > > Hmm... why? it would be better to try to have the KABI changes for it at > the same kernel release if possible. Because Hans is working on more changes. > > I'm fine with it going to linux-next now if > > we agree on the following. > > > > - We should only advocate v4l2_device usage for subdevices-aware video > > devices. Porting all drivers to v4l2_device is currently pointless and > > will only make future transitions more difficult. > > This makes sense to me. > > > - v4l2_device should be marked as experimental. I don't want to hear any > > API/ABI breakage argument in a few months time when the framework will > > evolve. > > Are you meaning marking this as experimental at Kconfig? This seems too > complex, since we'll need to test for some var on every driver that were > converted, providing two KABI options for each converted driver (the legacy > and the v4l2_device way). This doesn't seem to be a good idea, since will > add a lot of extra complexity to debug bugs. Not at the Kconfig level, just in the documentation (and possible headers). This is a work in progress. Hans wants the changes to go mainline to get broader testing, which is a valid reason, but I'd like to make sure people understand that more changes are coming. Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi, On Tue, Dec 2, 2008 at 11:58 AM, Trilok Soni <[EMAIL PROTECTED]> wrote: > Hi Mauro, > >> >> This is one of the lack of the features on mercurial. It doesn't have a meta >> tag for committer. On mercurial, the -hg user and the author should be the >> same >> person. >> >> Since we want to identify the patch origin (e.g. whose v4l/dvb maintainer got >> the patch), we use the internal "user" meta-tag as the committer, and an >> extra >> tag, at the patch description for the author (From:). >> >> When creating the -git patch, the "From:" tag is replaced, by script, for >> "Author:", I add my SOB there, and, I add myself as the -git committer (on >> git >> we have both meta-tags). > > Isn't it good time to move v4l2-dvb tree to GIT? I am not aware of any > hg-to-git repo. converter, but I can check with hg and git community. > It could be difficult at first, but I am very confident that there are > many GIT users here than mercurial, and yes your v4l-dvb maintenance > process might change due move from GIT, but atleast you will not have > to internal user meta-data per patch. OK, there are tools to convert mercurial to git repo. http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-8870e1c81cc93f9a7a7acb5e969924ee60182d6b http://hedonismbot.wordpress.com/2008/10/16/hg-fast-export-convert-mercurial-repositories-to-git-repositories/ -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, > > This is one of the lack of the features on mercurial. It doesn't have a meta > tag for committer. On mercurial, the -hg user and the author should be the > same > person. > > Since we want to identify the patch origin (e.g. whose v4l/dvb maintainer got > the patch), we use the internal "user" meta-tag as the committer, and an extra > tag, at the patch description for the author (From:). > > When creating the -git patch, the "From:" tag is replaced, by script, for > "Author:", I add my SOB there, and, I add myself as the -git committer (on git > we have both meta-tags). Isn't it good time to move v4l2-dvb tree to GIT? I am not aware of any hg-to-git repo. converter, but I can check with hg and git community. It could be difficult at first, but I am very confident that there are many GIT users here than mercurial, and yes your v4l-dvb maintenance process might change due move from GIT, but atleast you will not have to internal user meta-data per patch. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
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 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Mon, 1 Dec 2008 23:44:52 +0530 "Trilok Soni" <[EMAIL PROTECTED]> wrote: > Hi Hans, > > On Mon, Dec 1, 2008 at 7:21 PM, Hans Verkuil <[EMAIL PROTECTED]> wrote: > > Hi Mauro, > > > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the > > following: > > > > I don't understand "hg" version control tool, but commit shows your > name as author of this patch, whereas the patch I had sent was having > --author field as Sakari Ailus. Could you please check this? Thanks. > > authorHans Verkuil <[EMAIL PROTECTED]> This is one of the lack of the features on mercurial. It doesn't have a meta tag for committer. On mercurial, the -hg user and the author should be the same person. Since we want to identify the patch origin (e.g. whose v4l/dvb maintainer got the patch), we use the internal "user" meta-tag as the committer, and an extra tag, at the patch description for the author (From:). When creating the -git patch, the "From:" tag is replaced, by script, for "Author:", I add my SOB there, and, I add myself as the -git committer (on git we have both meta-tags). Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Monday 01 December 2008 19:14:52 Trilok Soni wrote: > Hi Hans, > > On Mon, Dec 1, 2008 at 7:21 PM, Hans Verkuil <[EMAIL PROTECTED]> wrote: > > Hi Mauro, > > > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for > > the following: > > I don't understand "hg" version control tool, but commit shows your > name as author of this patch, whereas the patch I had sent was having > --author field as Sakari Ailus. Could you please check this? Thanks. > > authorHans Verkuil <[EMAIL PROTECTED]> > Mon Dec 01 14:49:58 2008 +0100 (4 hours ago) > changeset 97682b81e03d16ed > manifest 2b81e03d16ed > parent 9767 7100e78482d7 > tag tip The hg author field is just whoever committed it into the mercurial repository, but what will show up when merged into the kernel are the From: and SoB fields. Actually, those were wrong as I had you as author (From:) instead of Sakari. I've changed that now. It looks like this now: omap2: add OMAP2 camera driver. From: Sakari Ailus <[EMAIL PROTECTED]> Add a driver for the OMAP2 camera block. OMAP2 is used in e.g. Nokia N800/N810 internet tablet. This driver uses the V4L2 internal ioctl interface. Priority: normal Signed-off-by: Sakari Ailus <[EMAIL PROTECTED]> Signed-off-by: Trilok Soni <[EMAIL PROTECTED]> Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]> Should be fine now, thanks for the heads up. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Hans, On Mon, Dec 1, 2008 at 7:21 PM, Hans Verkuil <[EMAIL PROTECTED]> wrote: > Hi Mauro, > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the > following: > I don't understand "hg" version control tool, but commit shows your name as author of this patch, whereas the patch I had sent was having --author field as Sakari Ailus. Could you please check this? Thanks. author Hans Verkuil <[EMAIL PROTECTED]> Mon Dec 01 14:49:58 2008 +0100 (4 hours ago) changeset 9768 2b81e03d16ed manifest2b81e03d16ed parent 9767 7100e78482d7 tag tip -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
On Monday 01 December 2008 16:06:43 Mauro Carvalho Chehab wrote: > Hi Hans, > > On Mon, 1 Dec 2008 15:24:43 +0100 > > Laurent Pinchart <[EMAIL PROTECTED]> wrote: > > > > 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. > > > > I would say 2.6.29 is a bit early, but I can live with that. > > It also seems a bit early to me, but it may work. I'll try to > schedule some time this week for a deep review. Much appreciated. > > > 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. > > IMO, this is one of the top priorities: the old-style i2c used on > some bridge drivers like saa7134 and cx88 are causing malfunctions > that can't be easily solved. I would like to see a fix for this for > 2.6.29. Using v4l2_i2c_new_subdev or v4l2_i2c_new_probed_subdev should make it much easier to switch over. It certainly simplified it for ivtv. > > > 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. > > > > > > > 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? > > I only send Linus the patches that are already ok, but I generally > prefer to postpone a merge for the end of a merge window, when the > patch is not meant to be at the next version. > > > In a few months time (probably even earlier) the v4l2_device > > structure will be reworked (and possible renamed). > > Hmm... why? it would be better to try to have the KABI changes for it > at the same kernel release if possible. I would like to state again that I have no plans to rename it. There is a chance that it will be used by the dvb subsystem as well in the future, but that's not going to happen any time soon. But should that happen, then we might consider renaming it to media_device/media_subdev. However, right now it is very much v4l2 specific code. I think it more likely that if this is used in dvb then it would be for v4l2 functionality, not dvb functionality. There will definitely be future additions since this is only the first step. Things on my list: better framework support for controls, v4l2_prio handling, adding a similar v4l2_fh struct for filehandle-specific data and the media controller which has been discussed in earlier RFCs and that requires these fundamental data structs to be in place first. Replacing the v4l2-int-device.h API with v4l2_subdev and adding support for sensor drivers to the v4l2_subdev ops will also no doubt require additions. But I want to do this step by step. It's just humanly impossible to go for a Big Bang here. Each time something gets added there must be at least one driver actually using it so you have some confidence in the change. Just integrating these simple v4l2_device and v4l2_subdev structs will take a fair amount of time. Regards, Hans > > I'm fine with it going to linux-next now if > > we agree on the following. > > > > - We should only advocate v4l2_device usage for subdevices-aware > > video devices. Porting all drivers to v4l2_device is currently > > pointless and will only make future transitions more difficult. > > This makes sense to me. > > > - v4l2_device should be marked as experimental. I don't want to > > hear any API/ABI breakage argument in a few months time when the > > framework will evolve. > > Are you meaning marking this as experimental at Kconfig? This seems > too complex, since we'll need to test for some var on every driver > that were converted, providing two KABI options for each converted > driver (the legacy and the v4l2_device way). This doesn't seem to be > a good idea, since will add a lot of extra complexity to debug bugs. > > Cheers, > Mauro -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
Hi Hans, On Mon, 1 Dec 2008 15:24:43 +0100 Laurent Pinchart <[EMAIL PROTECTED]> wrote: > > > 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. > > I would say 2.6.29 is a bit early, but I can live with that. It also seems a bit early to me, but it may work. I'll try to schedule some time this week for a deep review. > > 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. IMO, this is one of the top priorities: the old-style i2c used on some bridge drivers like saa7134 and cx88 are causing malfunctions that can't be easily solved. I would like to see a fix for this for 2.6.29. > > 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. > > > > > 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? I only send Linus the patches that are already ok, but I generally prefer to postpone a merge for the end of a merge window, when the patch is not meant to be at the next version. > In a few months time (probably even earlier) the v4l2_device structure will > be > reworked (and possible renamed). Hmm... why? it would be better to try to have the KABI changes for it at the same kernel release if possible. > I'm fine with it going to linux-next now if > we agree on the following. > - We should only advocate v4l2_device usage for subdevices-aware video > devices. Porting all drivers to v4l2_device is currently pointless and will > only make future transitions more difficult. This makes sense to me. > - v4l2_device should be marked as experimental. I don't want to hear any > API/ABI breakage argument in a few months time when the framework will > evolve. Are you meaning marking this as experimental at Kconfig? This seems too complex, since we'll need to test for some var on every driver that were converted, providing two KABI options for each converted driver (the legacy and the v4l2_device way). This doesn't seem to be a good idea, since will add a lot of extra complexity to debug bugs. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
On Monday 01 December 2008 15:24:43 Laurent Pinchart wrote: > Hi Hans, > > On Monday 01 December 2008, Hans Verkuil wrote: > > On Monday 01 December 2008 14:29:53 Laurent Pinchart wrote: > > > 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. > > I would say 2.6.29 is a bit early, but I can live with that. > > > > 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. > > Agreed. > > > 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. > > Ok. > > > 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. > > > > > 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? > > In a few months time (probably even earlier) the v4l2_device > structure will be reworked (and possible renamed). I'm fine with it > going to linux-next now if we agree on the following. > > - We should only advocate v4l2_device usa
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
Hi Hans, On Monday 01 December 2008, Hans Verkuil wrote: > On Monday 01 December 2008 14:29:53 Laurent Pinchart wrote: > > 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. I would say 2.6.29 is a bit early, but I can live with that. > > 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. Agreed. > 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. Ok. > 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. > > > 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? In a few months time (probably even earlier) the v4l2_device structure will be reworked (and possible renamed). I'm fine with it going to linux-next now if we agree on the following. - We should only advocate v4l2_device usage for subdevices-aware video devices. Porting all drivers to v4l2_device is currently pointless and will only make future transitions more difficult. - v4l2_device should be marked as experimental. I don't want to hear any API/ABI breakage argument in a few months time when the f
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - omap2: add OMAP2 camera driver. Thanks, Hans diffstat: b/linux/drivers/media/video/omap24xxcam-dma.c | 601 b/linux/drivers/media/video/omap24xxcam.c | 1908 ++ b/linux/drivers/media/video/omap24xxcam.h | 593 linux/drivers/media/video/Kconfig |7 linux/drivers/media/video/Makefile|3 5 files changed, 3112 insertions(+) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
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. > 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
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. 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. 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. Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
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. Regards, Hans > > > Reviewed-by: Laurent Pinchart <[EMAIL PROTECTED]> > > Reviewed-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> > > Reviewed-by: Andy Walls <[EMAIL PROTECTED]> > > Reviewed-by: David Brownell <[EMAIL PROTECTED]> > > > > Once this is in I'll start on converting the other i2c drivers. > > Best regards, > > Laurent Pinchart -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
On Monday 01 December 2008 13:27:07 Mauro Carvalho Chehab wrote: > On Mon, 1 Dec 2008 12:46:08 +0100 > > Hans Verkuil <[EMAIL PROTECTED]> 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. > > > > Reviewed-by: Laurent Pinchart <[EMAIL PROTECTED]> > > Reviewed-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> > > Reviewed-by: Andy Walls <[EMAIL PROTECTED]> > > Reviewed-by: David Brownell <[EMAIL PROTECTED]> > > > > Once this is in I'll start on converting the other i2c drivers. > > Hmm.. wouldn't this break the other drivers that use the converted > i2c drivers (for example saa7115 and msp3400 are used for other > drivers, like em28xx and bttv). No, see v4l2_subdev_command() in v4l2-subdev.c: this adds the required backwards compatibility. It can be removed once everyone uses the new calling convention, but until that time it will take care of this. That's the nice thing about it: you can do the conversion step by step without worrying about breaking existing drivers. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
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. > Reviewed-by: Laurent Pinchart <[EMAIL PROTECTED]> > Reviewed-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> > Reviewed-by: Andy Walls <[EMAIL PROTECTED]> > Reviewed-by: David Brownell <[EMAIL PROTECTED]> > > Once this is in I'll start on converting the other i2c drivers. Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
On Mon, 1 Dec 2008 12:46:08 +0100 Hans Verkuil <[EMAIL PROTECTED]> 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. > > Reviewed-by: Laurent Pinchart <[EMAIL PROTECTED]> > Reviewed-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> > Reviewed-by: Andy Walls <[EMAIL PROTECTED]> > Reviewed-by: David Brownell <[EMAIL PROTECTED]> > > Once this is in I'll start on converting the other i2c drivers. Hmm.. wouldn't this break the other drivers that use the converted i2c drivers (for example saa7115 and msp3400 are used for other drivers, like em28xx and bttv). Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ng
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. Reviewed-by: Laurent Pinchart <[EMAIL PROTECTED]> Reviewed-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> Reviewed-by: Andy Walls <[EMAIL PROTECTED]> Reviewed-by: David Brownell <[EMAIL PROTECTED]> Once this is in I'll start on converting the other i2c drivers. Thanks, Hans diffstat: b/linux/Documentation/video4linux/v4l2-framework.txt | 362 b/linux/drivers/media/video/v4l2-device.c| 86 + b/linux/drivers/media/video/v4l2-subdev.c| 108 ++ b/linux/include/media/v4l2-device.h | 109 ++ b/linux/include/media/v4l2-subdev.h | 188 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/cs53l32a.c | 186 ++-- linux/drivers/media/video/cx25840/cx25840-audio.c| 14 linux/drivers/media/video/cx25840/cx25840-core.c | 459 ++ linux/drivers/media/video/cx25840/cx25840-core.h |7 linux/drivers/media/video/cx25840/cx25840-firmware.c |2 linux/drivers/media/video/cx25840/cx25840-vbi.c |2 linux/drivers/media/video/ivtv/ivtv-controls.c | 16 linux/drivers/media/video/ivtv/ivtv-driver.c | 220 + linux/drivers/media/video/ivtv/ivtv-driver.h | 52 - linux/drivers/media/video/ivtv/ivtv-fileops.c| 44 - linux/drivers/media/video/ivtv/ivtv-gpio.c | 354 +--- linux/drivers/media/video/ivtv/ivtv-gpio.h |3 linux/drivers/media/video/ivtv/ivtv-i2c.c| 340 +-- linux/drivers/media/video/ivtv/ivtv-i2c.h| 13 linux/drivers/media/video/ivtv/ivtv-ioctl.c | 73 - linux/drivers/media/video/ivtv/ivtv-routing.c| 12 linux/drivers/media/video/ivtv/ivtv-streams.c| 13 linux/drivers/media/video/ivtv/ivtv-vbi.c| 17 linux/drivers/media/video/ivtv/ivtvfb.c | 91 +- linux/drivers/media/video/m52790.c | 172 ++- linux/drivers/media/video/msp3400-driver.c | 408 + linux/drivers/media/video/msp3400-driver.h |7 linux/drivers/media/video/msp3400-kthreads.c | 34 linux/drivers/media/video/saa7115.c | 829 +-- linux/drivers/media/video/saa7127.c | 425 + linux/drivers/media/video/saa717x.c | 600 +++-- linux/drivers/media/video/tuner-core.c | 403 + linux/drivers/media/video/upd64031a.c| 193 ++-- linux/drivers/media/video/upd64083.c | 176 ++-- linux/drivers/media/video/v4l2-common.c | 170 +++ linux/drivers/media/video/vp27smpx.c | 134 ++- linux/drivers/media/video/wm8739.c | 198 ++-- linux/drivers/media/video/wm8775.c | 217 +++- linux/include/media/v4l2-common.h| 41 40 files changed, 4098 insertions(+), 2682 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
