Debug code in HG repositories

Debug code in HG repositories

[Oliver Endriss]

Hi guys,

are you aware that there is a lot of '#if 0' code in the HG repositories
which is not in GIT?

When drivers were submitted to the kernel from HG, the '#if 0' stuff was
stripped, unless it was marked as 'keep'...

This was fine, when development was done with HG.

As GIT is being used now, that code will be lost, as soon as the HG
repositories have been removed...

Any opinions how this should be handled?

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: Debug code in HG repositories

[Devin Heitmueller]

On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
> Hi guys,
>
> are you aware that there is a lot of '#if 0' code in the HG repositories
> which is not in GIT?
>
> When drivers were submitted to the kernel from HG, the '#if 0' stuff was
> stripped, unless it was marked as 'keep'...
>
> This was fine, when development was done with HG.
>
> As GIT is being used now, that code will be lost, as soon as the HG
> repositories have been removed...
>
> Any opinions how this should be handled?
>
> CU
> Oliver

I complained about this months ago.  The problem is that when we were
using HG, the HG repo was a complete superset of what went into Git
(including development/debug code).  But now that we use Git, neither
is a superset of the other.

If you base your changes on Git, you have to add back in all the
portability code (and any "#if 0" you added as the maintainer for
development/debugging).  Oh, and regular users cannot test any of your
changes because they aren't willing to upgrade their entire kernel.

If you base your changes on Hg, nothing merges cleanly when submitted
upstream so your patches get rejected.

Want to know why we are seeing regressions all over the place?
Because *NOBODY* is testing the code until after the kernel goes
stable (since while many are willing to install a v4l-dvb tree, very
few will are willing to upgrade their entire kernel just to test one
driver).  We've probably lost about 98% of our user base of testers.

Oh, and users have to git clone 500M+ of data, and not everybody in
the world has bandwidth fast enough to make that worth their time (it
took me several hours last time I did it).

Anyway, I've beaten this horse to death and it's fallen on deaf ears.
Merge overhead has reached the point where it's just not worth my
time/effort to submit anything upstream anymore.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Debug code in HG repositories

[Hans Verkuil]

On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
> On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
> > Hi guys,
> >
> > are you aware that there is a lot of '#if 0' code in the HG repositories
> > which is not in GIT?
> >
> > When drivers were submitted to the kernel from HG, the '#if 0' stuff was
> > stripped, unless it was marked as 'keep'...
> >
> > This was fine, when development was done with HG.
> >
> > As GIT is being used now, that code will be lost, as soon as the HG
> > repositories have been removed...
> >
> > Any opinions how this should be handled?
> >
> > CU
> > Oliver
> 
> I complained about this months ago.  The problem is that when we were
> using HG, the HG repo was a complete superset of what went into Git
> (including development/debug code).  But now that we use Git, neither
> is a superset of the other.
> 
> If you base your changes on Git, you have to add back in all the
> portability code (and any "#if 0" you added as the maintainer for
> development/debugging).  Oh, and regular users cannot test any of your
> changes because they aren't willing to upgrade their entire kernel.
> 
> If you base your changes on Hg, nothing merges cleanly when submitted
> upstream so your patches get rejected.
> 
> Want to know why we are seeing regressions all over the place?
> Because *NOBODY* is testing the code until after the kernel goes
> stable (since while many are willing to install a v4l-dvb tree, very
> few will are willing to upgrade their entire kernel just to test one
> driver).  We've probably lost about 98% of our user base of testers.

Have you tried Mauro's media_build tree? I had to use it today to test a
driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
promote this more. I could add backwards compatibility builds to my daily
build script that uses this in order to check for which kernel versions
this compiles if there is sufficient interest.

> Oh, and users have to git clone 500M+ of data, and not everybody in
> the world has bandwidth fast enough to make that worth their time (it
> took me several hours last time I did it).

Currently the media_build tree copies the drivers from a git tree. Which, as
you say, can be a big problem for non-developers. But all it really needs are
the media drivers. So perhaps it might be a good idea to make a daily snapshot
of the drivers and make it available for download on linuxtv.org. That archive
is only 3.5 MB, so much easier to download.

> Anyway, I've beaten this horse to death and it's fallen on deaf ears.
> Merge overhead has reached the point where it's just not worth my
> time/effort to submit anything upstream anymore.

The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
much work. Any attempt to work from the hg tree is doomed. The media_build
seems to be a viable alternative. As a developer you still have to go through
the painful process of cloning the git repo, but it is a one time thing. Once
it's cloned then you only have to follow the new commits, which is much, much
faster.

And regarding regressions: I'm amazed how few regressions we have considering
the furious rate of development. The media subsystem is still one of the most
active subsystems in the kernel and probably will remain so for the forseeable
future as well.

It would be a shame not to submit patches upstream, that never ends well in
the long run.

With respect to '#if 0': for the most part I'd say: good riddance. In my
many years of experience as a SW engineer I have never seen anyone actually
turn on '#if 0' code once it's been in the code for more than, say, a year.
Usually people just leave it there because they are too lazy to remove it,
or they don't understand what it is for and are too scared to remove it.

If it is code partially implementing a feature that needs more work, then
it may sound like a good idea to keep it. However, after it's in the code for
more than a year, then nobody remembers what the code was about and what still
had to be done to make it work. And it's hell to figure that out after such a
long time. Never put such code in the mainline. Keep it in a branch if you
have to.

Anyway, if there is some '#if 0' code that you want to preserve in git, then
you have to make a patch to add it. But you probably will have to have very
good reasons for adding '#if 0' code to the mainline.

Regards,

	Hans

Re: Debug code in HG repositories

[Theodore Kilgore]

On Fri, 7 Jan 2011, Hans Verkuil wrote:

> On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
> > On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
> > > Hi guys,
> > >
> > > are you aware that there is a lot of '#if 0' code in the HG repositories
> > > which is not in GIT?
> > >
> > > When drivers were submitted to the kernel from HG, the '#if 0' stuff was
> > > stripped, unless it was marked as 'keep'...
> > >
> > > This was fine, when development was done with HG.
> > >
> > > As GIT is being used now, that code will be lost, as soon as the HG
> > > repositories have been removed...
> > >
> > > Any opinions how this should be handled?
> > >
> > > CU
> > > Oliver
> > 
> > I complained about this months ago.  The problem is that when we were
> > using HG, the HG repo was a complete superset of what went into Git
> > (including development/debug code).  But now that we use Git, neither
> > is a superset of the other.
> > 
> > If you base your changes on Git, you have to add back in all the
> > portability code (and any "#if 0" you added as the maintainer for
> > development/debugging).  Oh, and regular users cannot test any of your
> > changes because they aren't willing to upgrade their entire kernel.
> > 
> > If you base your changes on Hg, nothing merges cleanly when submitted
> > upstream so your patches get rejected.
> > 
> > Want to know why we are seeing regressions all over the place?
> > Because *NOBODY* is testing the code until after the kernel goes
> > stable (since while many are willing to install a v4l-dvb tree, very
> > few will are willing to upgrade their entire kernel just to test one
> > driver).  We've probably lost about 98% of our user base of testers.
> 
> Have you tried Mauro's media_build tree? I had to use it today to test a
> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
> promote this more. I could add backwards compatibility builds to my daily
> build script that uses this in order to check for which kernel versions
> this compiles if there is sufficient interest.
> 
> > Oh, and users have to git clone 500M+ of data, and not everybody in
> > the world has bandwidth fast enough to make that worth their time (it
> > took me several hours last time I did it).
> 
> Currently the media_build tree copies the drivers from a git tree. Which, as
> you say, can be a big problem for non-developers. But all it really needs are
> the media drivers. So perhaps it might be a good idea to make a daily snapshot
> of the drivers and make it available for download on linuxtv.org. That archive
> is only 3.5 MB, so much easier to download.
> 
> > Anyway, I've beaten this horse to death and it's fallen on deaf ears.
> > Merge overhead has reached the point where it's just not worth my
> > time/effort to submit anything upstream anymore.
> 
> The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
> much work. Any attempt to work from the hg tree is doomed. The media_build
> seems to be a viable alternative. As a developer you still have to go through
> the painful process of cloning the git repo, but it is a one time thing. Once
> it's cloned then you only have to follow the new commits, which is much, much
> faster.
> 
> And regarding regressions: I'm amazed how few regressions we have considering
> the furious rate of development. The media subsystem is still one of the most
> active subsystems in the kernel and probably will remain so for the forseeable
> future as well.
> 
> It would be a shame not to submit patches upstream, that never ends well in
> the long run.
> 
> With respect to '#if 0': for the most part I'd say: good riddance. In my
> many years of experience as a SW engineer I have never seen anyone actually
> turn on '#if 0' code once it's been in the code for more than, say, a year.
> Usually people just leave it there because they are too lazy to remove it,
> or they don't understand what it is for and are too scared to remove it.
> 
> If it is code partially implementing a feature that needs more work, then
> it may sound like a good idea to keep it. However, after it's in the code for
> more than a year, then nobody remembers what the code was about and what still
> had to be done to make it work. And it's hell to figure that out after such a
> long time. Never put such code in the mainline. Keep it in a branch if you
> have to.
> 
> Anyway, if there is some '#if 0' code that you want to preserve in git, then
> you have to make a patch to add it. But you probably will have to have very
> good reasons for adding '#if 0' code to the mainline.
> 
> Regards,
> 
> 	Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

I think you are both right. There, that ought to be pleasing. :-)

More seriously (quoting from above)

> Have you tried Mauro's media_build tree? I had to use it today to test a
> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
should
> promote this more. 

Probably a good idea. I have been too busy to know about it, myself. And I 
even do try to keep up with what is going on.

> I could add backwards compatibility builds to my 
daily
> build script that uses this in order to check for which kernel versions
> this compiles if there is sufficient interest.

Nice, but don't bust your behind with a thing like that. Back when we were 
discussing the idea of getting off of hg and onto git, I suggested 
approximately the previous three minor versions of the kernel, no 
more. And if there was a serious problem with 2.(current_release - 1) or 
2.(current_release - 2) such as instability or security issues, whatever, 
then just drop that one. I think that to do this is reasonable if you or 
anyone else has the time and needed skills. More than this is not 
reasonable under any circumstances.

Now, as to the question of switching over to and using git, here are my 
recent personal experiences:

I started to do this switch-over only about a month ago, having been too 
busy for several months previous due to an illness in the family. I found 
that everything had changed in the meantime, and the hg trees had gone 
away. 

Issue 0: This issue came up just as I was deciding to switch from 32 to 64 
bit computing, so a lot of other stuff needed to be fixed or upgraded at 
the same time. I was busy. Well, lots of people are busy, and for lots of 
reasons. 

Issue 1: Which git tree? For someone who is going to get in at the 
beginning, this is not obvious. This issue got solved, of course, but it 
was the first one to face. For an outsider, I suspect that even this is 
somewhat intimidating.

Issue 2: Problems totally unrelated to drivers/media rendered the new 
kernel unusable for very a long time, approximately a couple of weeks. I 
think I can call myself experienced in kernel configuration and 
compilation, and also not a total neophyte as a developer. The issue was a 
rather evil interaction between the new kernel, the new X driver for the 
ATI Radeon chip, and the introduction of in-kernel modeswitching (KMS) in 
X. It came about that if KMS was turned on then the video would cut off 
completely halfway through the boot procedure, and if KMS was turned off 
then I could not run X. I could use the distro kernel 2.6.35.7 and a 
locally compiled 2.6.35.7 as well just fine, but I could not safely submit 
a patch based on it. And my patches could not be tested against the git 
kernel because I could not run the git kernel. This problem was ultimately 
solved, and I was able to submit a rather small patch to add a camera to 
an existing driver, on Christmas Eve. 

Issue 3: I still need to grab the git tree for libv4l and start using it. 
I have not even begun this. For some of the reasons why I am behind 
schedule, see previous items.

The point is, problems similar to those which hit me could hit anybody at 
any time and "anybody" means exactly what it says. This was not the first 
time that I have installed a development kernel. It was the first time I 
had any serious problems after doing so. Now, it is also true that after I 
finally got the issues worked through I was pleased with the results and 
would still run the new kernel by preference. But the problems were 
extremely time consuming. IMHO problems like this are sooner or later 
inevitable when it is mandatory to use a development kernel. Users are 
impatient. Testers are impatient. Developers are impatient. We are all 
impatient when things like this happen. People who are not sufficiently 
knowledgeable, who are not sufficiently tenacious, or who simply do not 
have sufficient time or motivation will just quit. It is something to 
think about.

Theodore Kilgore

Re: Debug code in HG repositories

[Mauro Carvalho Chehab]

Em 07-01-2011 21:42, Theodore Kilgore escreveu:
 
>> Have you tried Mauro's media_build tree? I had to use it today to test a
>> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
> should
>> promote this more. 
> 
> Probably a good idea. I have been too busy to know about it, myself. And I 
> even do try to keep up with what is going on.
> 
>> I could add backwards compatibility builds to my 
> daily
>> build script that uses this in order to check for which kernel versions
>> this compiles if there is sufficient interest.
> 
> Nice, but don't bust your behind with a thing like that. Back when we were 
> discussing the idea of getting off of hg and onto git, I suggested 
> approximately the previous three minor versions of the kernel, no 
> more. And if there was a serious problem with 2.(current_release - 1) or 
> 2.(current_release - 2) such as instability or security issues, whatever, 
> then just drop that one. I think that to do this is reasonable if you or 
> anyone else has the time and needed skills. More than this is not 
> reasonable under any circumstances.

I think Hans can enable it. The backport effort on media-build is a way
easier than with -hg. For example, in order to support kernel 2.6.31 (the oldest
one on that tree), we need only 10 patches. The patches themself are simple:

$ wc -l *.patch
   61 v2.6.31_nodename.patch
  540 v2.6.32_kfifo.patch
   42 v2.6.33_input_handlers_are_int.patch
   70 v2.6.33_pvrusb2_sysfs.patch
   40 v2.6.34_dvb_net.patch
   22 v2.6.34_fix_define_warnings.patch
   16 v2.6.35_firedtv_handle_fcp.patch
  104 v2.6.35_i2c_new_probed_device.patch
  145 v2.6.35_work_handler.patch
  104 v2.6.36_input_getkeycode.patch
 1144 total

And almost all patches are trivial.

> Now, as to the question of switching over to and using git, here are my 
> recent personal experiences:
> 
> I started to do this switch-over only about a month ago, having been too 
> busy for several months previous due to an illness in the family. I found 
> that everything had changed in the meantime, and the hg trees had gone 
> away. 
> 
> Issue 0: This issue came up just as I was deciding to switch from 32 to 64 
> bit computing, so a lot of other stuff needed to be fixed or upgraded at 
> the same time. I was busy. Well, lots of people are busy, and for lots of 
> reasons. 
> 
> Issue 1: Which git tree? For someone who is going to get in at the 
> beginning, this is not obvious. This issue got solved, of course, but it 
> was the first one to face. For an outsider, I suspect that even this is 
> somewhat intimidating.

It is now well-indicated at the top of the git page at linuxtv.org.

> Issue 2: Problems totally unrelated to drivers/media rendered the new 
> kernel unusable for very a long time, approximately a couple of weeks. I 
> think I can call myself experienced in kernel configuration and 
> compilation, and also not a total neophyte as a developer. The issue was a 
> rather evil interaction between the new kernel, the new X driver for the 
> ATI Radeon chip, and the introduction of in-kernel modeswitching (KMS) in 
> X. It came about that if KMS was turned on then the video would cut off 
> completely halfway through the boot procedure, and if KMS was turned off 
> then I could not run X. I could use the distro kernel 2.6.35.7 and a 
> locally compiled 2.6.35.7 as well just fine, but I could not safely submit 
> a patch based on it. And my patches could not be tested against the git 
> kernel because I could not run the git kernel. This problem was ultimately 
> solved, and I was able to submit a rather small patch to add a camera to 
> an existing driver, on Christmas Eve. 

Yeah, KMS also affected me for some time on -git builds, until it become more
stable. The solution I used were to not start X on my test machine during that
period of time.

Anyway, with media_build tree, you can compile it against your 2.6.35.7 kernel.
Depending on what you're doing, this should be ok. 

Yet, with BKL changes, the better for developers is to use kernel 2.6.37 or upper, 
in orderto be sure that the driver will work properly without BKL and without any 
race/dead lock issue.

> Issue 3: I still need to grab the git tree for libv4l and start using it. 
> I have not even begun this. For some of the reasons why I am behind 
> schedule, see previous items.

You should really use it, as some webcam fixes happen there (like some 
sensors mounted with vflip/hflip). Fedora ships it by default, and most
applications there calls it. Not sure why some distros are still not
shipping it properly.

> The point is, problems similar to those which hit me could hit anybody at 
> any time and "anybody" means exactly what it says. This was not the first 
> time that I have installed a development kernel. It was the first time I 
> had any serious problems after doing so. Now, it is also true that after I 
> finally got the issues worked through I was pleased with the results and 
> would still run the new kernel by preference. But the problems were 
> extremely time consuming. IMHO problems like this are sooner or later 
> inevitable when it is mandatory to use a development kernel. Users are 
> impatient. Testers are impatient. Developers are impatient. We are all 
> impatient when things like this happen. People who are not sufficiently 
> knowledgeable, who are not sufficiently tenacious, or who simply do not 
> have sufficient time or motivation will just quit. It is something to 
> think about.
> 
> Theodore Kilgore
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

[Johannes Stezenbach]

On Mon, Jan 10, 2011 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
> Em 07-01-2011 21:42, Theodore Kilgore escreveu:
>  
> >> Have you tried Mauro's media_build tree? I had to use it today to test a
> >> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
> > should
> >> promote this more. 
> > 
> > Probably a good idea. I have been too busy to know about it, myself. And I 
> > even do try to keep up with what is going on.
> > 
> >> I could add backwards compatibility builds to my 
> > daily
> >> build script that uses this in order to check for which kernel versions
> >> this compiles if there is sufficient interest.
...
> I think Hans can enable it. The backport effort on media-build is a way
> easier than with -hg. For example, in order to support kernel 2.6.31 (the oldest
> one on that tree), we need only 10 patches. The patches themself are simple:
> 
> $ wc -l *.patch
>    61 v2.6.31_nodename.patch
>   540 v2.6.32_kfifo.patch
>    42 v2.6.33_input_handlers_are_int.patch
>    70 v2.6.33_pvrusb2_sysfs.patch
>    40 v2.6.34_dvb_net.patch
>    22 v2.6.34_fix_define_warnings.patch
>    16 v2.6.35_firedtv_handle_fcp.patch
>   104 v2.6.35_i2c_new_probed_device.patch
>   145 v2.6.35_work_handler.patch
>   104 v2.6.36_input_getkeycode.patch
>  1144 total
> 
> And almost all patches are trivial.

FWIW, linux-wireless developers maintain a generic compat tree used
for backporting wireless drivers:
http://git.kernel.org/?p=linux/kernel/git/mcgrof/compat.git;a=summary

I suppose it might be useful to share this between linux-wireless
and linux-media?


(It is used together with three other trees to autobuild
the compat-wireless releases.
http://wireless.kernel.org/en/users/Download

It works like that:
- compat.git: generic backporting layer
- compat-wireless-2.6.git: build system
- compat-user.git: autobuild scripts called via cron
- wireless-testing.git: linux-wireless development tree

(wireless-testing.git is based on latest stable kernel but with
the wireless code from linux-next)

compat-wireless releases are not meant for development, but
they can be used as a build system together with a wireless-testing.git
tree and a few symlinks.)


Johannes

Re: Debug code in HG repositories

[Theodore Kilgore]

Mauro,

A few comments in-line. Vide infra.

On Mon, 10 Jan 2011, Mauro Carvalho Chehab wrote:

> Em 07-01-2011 21:42, Theodore Kilgore escreveu:
>  
> >> Have you tried Mauro's media_build tree? I had to use it today to test a
> >> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
> > should
> >> promote this more. 
> > 
> > Probably a good idea. I have been too busy to know about it, myself. And I 
> > even do try to keep up with what is going on.
> > 
> >> I could add backwards compatibility builds to my 
> > daily
> >> build script that uses this in order to check for which kernel versions
> >> this compiles if there is sufficient interest.
> > 
> > Nice, but don't bust your behind with a thing like that. Back when we were 
> > discussing the idea of getting off of hg and onto git, I suggested 
> > approximately the previous three minor versions of the kernel, no 
> > more. And if there was a serious problem with 2.(current_release - 1) or 
> > 2.(current_release - 2) such as instability or security issues, whatever, 
> > then just drop that one. I think that to do this is reasonable if you or 
> > anyone else has the time and needed skills. More than this is not 
> > reasonable under any circumstances.
> 
> I think Hans can enable it. The backport effort on media-build is a way
> easier than with -hg. For example, in order to support kernel 2.6.31 (the oldest
> one on that tree), we need only 10 patches. The patches themself are simple:
> 
> $ wc -l *.patch
>    61 v2.6.31_nodename.patch
>   540 v2.6.32_kfifo.patch
>    42 v2.6.33_input_handlers_are_int.patch
>    70 v2.6.33_pvrusb2_sysfs.patch
>    40 v2.6.34_dvb_net.patch
>    22 v2.6.34_fix_define_warnings.patch
>    16 v2.6.35_firedtv_handle_fcp.patch
>   104 v2.6.35_i2c_new_probed_device.patch
>   145 v2.6.35_work_handler.patch
>   104 v2.6.36_input_getkeycode.patch
>  1144 total
> 
> And almost all patches are trivial.

Great. I am glad Hans is able to do that. I also think that before some 
changes were made things had reached the point of being both ridiculous 
and impossible. People doing the work were being run ragged, and demands 
for legacy support were obviously unreasonable. 

I forget what all of the issues were in the pre-2.6.20 kernels. I vaguely 
recall there were some really bad ones. One of them that I have personal 
knowledge about was a major error in the USB Mass Storage module, detected 
and fixed somewhere around 2.6.18. Namely, if a device says it is Class 08 
the spec says the first pair of bulk endpoints will be used. Before the 
fix, last pair was being searched instead. The mistake is not confronted 
very often, of course, because few USB devices have more than one pair of 
bulk endpoints. But for those that do, ouch. In fact, the hardware which 
brought the mistake to daylight was the same camera which is supported in 
gspca/jeilinj.c. In still mode as a standard mass storage device, that 
camera uses the first pair of bulk endpoints. As it is supposed to do. But 
until things were fixed, the mass storage support was attempting to use 
the second pair, which did not work out very well. The second pair of the 
bulk endpoints gets used only in webcam mode for passing commands and 
responses.

The point of the above story is that sometimes in kernel development 
things are changed from wrong to right. Those who petulantly want their 
favorite ancient kernel to be supported simply ought to understand and 
accept out of hand. Should any kernel prior to the fixing of the above 
problem continue in use in any environment where it needs to support USB 
mass storage devices? Obviously not. The moral for the present and future 
is obvious, too. 

> 
> > Now, as to the question of switching over to and using git, here are my 
> > recent personal experiences:
> > 
> > I started to do this switch-over only about a month ago, having been too 
> > busy for several months previous due to an illness in the family. I found 
> > that everything had changed in the meantime, and the hg trees had gone 
> > away. 
> > 
> > Issue 0: This issue came up just as I was deciding to switch from 32 to 64 
> > bit computing, so a lot of other stuff needed to be fixed or upgraded at 
> > the same time. I was busy. Well, lots of people are busy, and for lots of 
> > reasons. 
> > 
> > Issue 1: Which git tree? For someone who is going to get in at the 
> > beginning, this is not obvious. This issue got solved, of course, but it 
> > was the first one to face. For an outsider, I suspect that even this is 
> > somewhat intimidating.
> 
> It is now well-indicated at the top of the git page at linuxtv.org.

Nice.

> 
> > Issue 2: Problems totally unrelated to drivers/media rendered the new 
> > kernel unusable for very a long time, approximately a couple of weeks. I 
> > think I can call myself experienced in kernel configuration and 
> > compilation, and also not a total neophyte as a developer. The issue was a 
> > rather evil interaction between the new kernel, the new X driver for the 
> > ATI Radeon chip, and the introduction of in-kernel modeswitching (KMS) in 
> > X. It came about that if KMS was turned on then the video would cut off 
> > completely halfway through the boot procedure, and if KMS was turned off 
> > then I could not run X. I could use the distro kernel 2.6.35.7 and a 
> > locally compiled 2.6.35.7 as well just fine, but I could not safely submit 
> > a patch based on it. And my patches could not be tested against the git 
> > kernel because I could not run the git kernel. This problem was ultimately 
> > solved, and I was able to submit a rather small patch to add a camera to 
> > an existing driver, on Christmas Eve. 
> 
> Yeah, KMS also affected me for some time on -git builds, until it become more
> stable. The solution I used were to not start X on my test machine during that
> period of time.

Oh. So that one bit you too, did it? You must have similar hardware. Well, 
I am glad that I was not alone. 

The only thing that I do not follow, though, is the last sentence. Namely, 
if one is trying to develop support for streaming video devices, just how 
does one test them without using X? So how exactly can that be a solution?

> 
> Anyway, with media_build tree, you can compile it against your 2.6.35.7 kernel.
> Depending on what you're doing, this should be ok. 

I really do like 2.6.37 better. Unfortunately, I am in the situation that 
I have to do some stuff which is 32-bit and some stuff which is 64-bit, so 
I need to maintain a dual-boot machine. So at this moment I am booted in 
2.6.35.7 32-bit trying to do a kernel cross-compile for an ARM gadget 
using tools which won't run in a 64-bit environment. Lots of fun, on too 
many fronts at once.

> 
> Yet, with BKL changes, the better for developers is to use kernel 2.6.37 or upper, 
> in orderto be sure that the driver will work properly without BKL and without any 
> race/dead lock issue.
> 
> > Issue 3: I still need to grab the git tree for libv4l and start using it. 
> > I have not even begun this. For some of the reasons why I am behind 
> > schedule, see previous items.
> 
> You should really use it, as some webcam fixes happen there (like some 
> sensors mounted with vflip/hflip). Fedora ships it by default, and most
> applications there calls it. Not sure why some distros are still not
> shipping it properly.

I fully agree. Did I mention that things are behind schedule? I am not 
sure which distros are "still not shipping it properly" though. I would 
not expect any distro to ship anything but a release version. For me it is 
obviously not possible to run a release version in any event. I am 
running a (slightly out of date) development version right now. For, 
usually the addition of kernel support for a webcam also requires the 
simultaneous addition of libv4lconvert support for its decompression 
algorithm at the very least.

> > The point is, problems similar to those which hit me could hit anybody at 
> > any time and "anybody" means exactly what it says. This was not the first 
> > time that I have installed a development kernel. It was the first time I 
> > had any serious problems after doing so. Now, it is also true that after I 
> > finally got the issues worked through I was pleased with the results and 
> > would still run the new kernel by preference. But the problems were 
> > extremely time consuming. IMHO problems like this are sooner or later 
> > inevitable when it is mandatory to use a development kernel. Users are 
> > impatient. Testers are impatient. Developers are impatient. We are all 
> > impatient when things like this happen. People who are not sufficiently 
> > knowledgeable, who are not sufficiently tenacious, or who simply do not 
> > have sufficient time or motivation will just quit. It is something to 
> > think about.

I will definitely stand by the previous paragraph. All of it. I am very 
glad that attempts are being made to overcome the problems.

Theodore Kilgore

Re: Debug code in HG repositories

[Oliver Endriss]

On Friday 07 January 2011 22:06:30 Hans Verkuil wrote:
> On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
> > On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
> > > Hi guys,
> > >
> > > are you aware that there is a lot of '#if 0' code in the HG repositories
> > > which is not in GIT?
> > >
> > > When drivers were submitted to the kernel from HG, the '#if 0' stuff was
> > > stripped, unless it was marked as 'keep'...
> > >
> > > This was fine, when development was done with HG.
> > >
> > > As GIT is being used now, that code will be lost, as soon as the HG
> > > repositories have been removed...
> > >
> > > Any opinions how this should be handled?
> > >
> > > CU
> > > Oliver
> > 
> > I complained about this months ago.  The problem is that when we were
> > using HG, the HG repo was a complete superset of what went into Git
> > (including development/debug code).  But now that we use Git, neither
> > is a superset of the other.
> > 
> > If you base your changes on Git, you have to add back in all the
> > portability code (and any "#if 0" you added as the maintainer for
> > development/debugging).  Oh, and regular users cannot test any of your
> > changes because they aren't willing to upgrade their entire kernel.
> > 
> > If you base your changes on Hg, nothing merges cleanly when submitted
> > upstream so your patches get rejected.
> > 
> > Want to know why we are seeing regressions all over the place?
> > Because *NOBODY* is testing the code until after the kernel goes
> > stable (since while many are willing to install a v4l-dvb tree, very
> > few will are willing to upgrade their entire kernel just to test one
> > driver).  We've probably lost about 98% of our user base of testers.
> 
> Have you tried Mauro's media_build tree? I had to use it today to test a
> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
> promote this more. I could add backwards compatibility builds to my daily
> build script that uses this in order to check for which kernel versions
> this compiles if there is sufficient interest.
> 
> > Oh, and users have to git clone 500M+ of data, and not everybody in
> > the world has bandwidth fast enough to make that worth their time (it
> > took me several hours last time I did it).
> 
> Currently the media_build tree copies the drivers from a git tree. Which, as
> you say, can be a big problem for non-developers. But all it really needs are
> the media drivers. So perhaps it might be a good idea to make a daily snapshot
> of the drivers and make it available for download on linuxtv.org. That archive
> is only 3.5 MB, so much easier to download.
> 
> > Anyway, I've beaten this horse to death and it's fallen on deaf ears.
> > Merge overhead has reached the point where it's just not worth my
> > time/effort to submit anything upstream anymore.
> 
> The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
> much work. Any attempt to work from the hg tree is doomed. The media_build
> seems to be a viable alternative. As a developer you still have to go through
> the painful process of cloning the git repo, but it is a one time thing. Once
> it's cloned then you only have to follow the new commits, which is much, much
> faster.
> 
> And regarding regressions: I'm amazed how few regressions we have considering
> the furious rate of development. The media subsystem is still one of the most
> active subsystems in the kernel and probably will remain so for the forseeable
> future as well.

Regressions can be detected only if you have enough testers!

With the current situation, it is very likely that regressions will not
show up before major linux distributions switch to a new kernel.
Afaics the user base is neglectible at the moment. So you can expect
that regressions will show up months after release of a new kernel.

Anyway, this is off-topic. I was not talking about regressions.

> It would be a shame not to submit patches upstream, that never ends well in
> the long run.
> 
> With respect to '#if 0': for the most part I'd say: good riddance. In my
> many years of experience as a SW engineer I have never seen anyone actually
> turn on '#if 0' code once it's been in the code for more than, say, a year.
> Usually people just leave it there because they are too lazy to remove it,
> or they don't understand what it is for and are too scared to remove it.
> 
> If it is code partially implementing a feature that needs more work, then
> it may sound like a good idea to keep it. However, after it's in the code for
> more than a year, then nobody remembers what the code was about and what still
> had to be done to make it work. And it's hell to figure that out after such a
> long time. Never put such code in the mainline. Keep it in a branch if you
> have to.
> 
> Anyway, if there is some '#if 0' code that you want to preserve in git, then
> you have to make a patch to add it. But you probably will have to have very
> good reasons for adding '#if 0' code to the mainline.

I do not care about some #ifdef'ed printk statements.

There are large pieces of driver code which are currently unused, and
nobody can tell whether they will ever be needed.

On the other hand a developer spent days writing this stuff, and now it
does not exist anymore - without any trace!

The problem is not, that it is missing in the current snapshot, but
that it has never been in the git repository, and there is no way to
recover it.

Afaics, the only way to preserve this kind of code is 'out-of-tree'.
It is a shame... :-(

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: Debug code in HG repositories

[Mauro Carvalho Chehab]

Em 07-01-2011 21:56, Oliver Endriss escreveu:
> On Friday 07 January 2011 22:06:30 Hans Verkuil wrote:
>> On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
>>> On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
>>>> Hi guys,
>>>>
>>>> are you aware that there is a lot of '#if 0' code in the HG repositories
>>>> which is not in GIT?
>>>>
>>>> When drivers were submitted to the kernel from HG, the '#if 0' stuff was
>>>> stripped, unless it was marked as 'keep'...
>>>>
>>>> This was fine, when development was done with HG.
>>>>
>>>> As GIT is being used now, that code will be lost, as soon as the HG
>>>> repositories have been removed...
>>>>
>>>> Any opinions how this should be handled?
>>>>
>>>> CU
>>>> Oliver
>>>
>>> I complained about this months ago.  The problem is that when we were
>>> using HG, the HG repo was a complete superset of what went into Git
>>> (including development/debug code).  But now that we use Git, neither
>>> is a superset of the other.
>>>
>>> If you base your changes on Git, you have to add back in all the
>>> portability code (and any "#if 0" you added as the maintainer for
>>> development/debugging).  Oh, and regular users cannot test any of your
>>> changes because they aren't willing to upgrade their entire kernel.
>>>
>>> If you base your changes on Hg, nothing merges cleanly when submitted
>>> upstream so your patches get rejected.
>>>
>>> Want to know why we are seeing regressions all over the place?
>>> Because *NOBODY* is testing the code until after the kernel goes
>>> stable (since while many are willing to install a v4l-dvb tree, very
>>> few will are willing to upgrade their entire kernel just to test one
>>> driver).  We've probably lost about 98% of our user base of testers.
>>
>> Have you tried Mauro's media_build tree? I had to use it today to test a
>> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
>> promote this more. I could add backwards compatibility builds to my daily
>> build script that uses this in order to check for which kernel versions
>> this compiles if there is sufficient interest.
>>
>>> Oh, and users have to git clone 500M+ of data, and not everybody in
>>> the world has bandwidth fast enough to make that worth their time (it
>>> took me several hours last time I did it).
>>
>> Currently the media_build tree copies the drivers from a git tree. Which, as
>> you say, can be a big problem for non-developers. But all it really needs are
>> the media drivers. So perhaps it might be a good idea to make a daily snapshot
>> of the drivers and make it available for download on linuxtv.org. That archive
>> is only 3.5 MB, so much easier to download.
>>
>>> Anyway, I've beaten this horse to death and it's fallen on deaf ears.
>>> Merge overhead has reached the point where it's just not worth my
>>> time/effort to submit anything upstream anymore.
>>
>> The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
>> much work. Any attempt to work from the hg tree is doomed. The media_build
>> seems to be a viable alternative. As a developer you still have to go through
>> the painful process of cloning the git repo, but it is a one time thing. Once
>> it's cloned then you only have to follow the new commits, which is much, much
>> faster.
>>
>> And regarding regressions: I'm amazed how few regressions we have considering
>> the furious rate of development. The media subsystem is still one of the most
>> active subsystems in the kernel and probably will remain so for the forseeable
>> future as well.
> 
> Regressions can be detected only if you have enough testers!
> 
> With the current situation, it is very likely that regressions will not
> show up before major linux distributions switch to a new kernel.
> Afaics the user base is neglectible at the moment. So you can expect
> that regressions will show up months after release of a new kernel.

Fedora code is released on every 6 months, generally with the newest code from
V4L/DVB. Fedora rawhide always have the latest kernel. I'm sure that other distros
have similar development procedures. So, even if nobody is using media_build.git, 
there are many users with access to the latest code, that come to them via distros.

There are very few regressions reported.

Of course, it would be great if more people start using media_build.git, as we'll
have more testers.
> 
> Anyway, this is off-topic. I was not talking about regressions.
> 
>> It would be a shame not to submit patches upstream, that never ends well in
>> the long run.
>>
>> With respect to '#if 0': for the most part I'd say: good riddance. In my
>> many years of experience as a SW engineer I have never seen anyone actually
>> turn on '#if 0' code once it's been in the code for more than, say, a year.
>> Usually people just leave it there because they are too lazy to remove it,
>> or they don't understand what it is for and are too scared to remove it.
>>
>> If it is code partially implementing a feature that needs more work, then
>> it may sound like a good idea to keep it. However, after it's in the code for
>> more than a year, then nobody remembers what the code was about and what still
>> had to be done to make it work. And it's hell to figure that out after such a
>> long time. Never put such code in the mainline. Keep it in a branch if you
>> have to.
>>
>> Anyway, if there is some '#if 0' code that you want to preserve in git, then
>> you have to make a patch to add it. But you probably will have to have very
>> good reasons for adding '#if 0' code to the mainline.
> 
> I do not care about some #ifdef'ed printk statements.
> 
> There are large pieces of driver code which are currently unused, and
> nobody can tell whether they will ever be needed.
> 
> On the other hand a developer spent days writing this stuff, and now it
> does not exist anymore - without any trace!
> 
> The problem is not, that it is missing in the current snapshot, but
> that it has never been in the git repository, and there is no way to
> recover it.

The Mercurial tree will stay there forever. We still have there the old CVS 
trees used by DVB and V4L development.
> 
> Afaics, the only way to preserve this kind of code is 'out-of-tree'.
> It is a shame... :-(

I see your point. It is harder for people to re-use that code, as they are not
upstream.

It is easy to recover the changes with:

$ gentree.pl 2.6.37 --strip_dead_code linux/ /tmp/stripped
$ gentree.pl 2.6.37  linux/ /tmp/not_stripped
$ diff -upr /tmp/stripped/ /tmp/not_stripped/ >/tmp/revert_removed_code.patch

As a reference and further discussions, I'm enclosing the diff.

Cheers,
Mauro.

---

diff -upr /tmp/stripped/drivers/media/common/tuners/tea5767.c /tmp/not_stripped/drivers/media/common/tuners/tea5767.c
--- /tmp/stripped/drivers/media/common/tuners/tea5767.c	2011-01-10 10:01:50.000000000 -0200
+++ /tmp/not_stripped/drivers/media/common/tuners/tea5767.c	2011-01-10 10:02:06.000000000 -0200
@@ -371,6 +371,9 @@ int tea5767_autodetection(struct i2c_ada
 	struct tuner_i2c_props i2c = { .adap = i2c_adap, .addr = i2c_addr };
 	unsigned char buffer[7] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
 	int rc;
+#if 0 /* Needed if uncomment I2C send code below */
+	int div;
+#endif
 
 	if ((rc = tuner_i2c_xfer_recv(&i2c, buffer, 7))< 5) {
 		printk(KERN_WARNING "It is not a TEA5767. Received %i bytes.\n", rc);
@@ -394,7 +397,42 @@ int tea5767_autodetection(struct i2c_ada
 		return -EINVAL;
 	}
 
+#if 0	/* Not working for TEA5767 in Beholder Columbus card */
+	/* It seems that tea5767 returns 0xff after the 5th byte */
+	if ((buffer[5] != 0xff) || (buffer[6] != 0xff)) {
+		printk(KERN_WARNING "Returned more than 5 bytes. It is not a TEA5767\n");
+		return -EINVAL;
+	}
+#endif
+
+#if 0 /*Sometimes, this code doesn't work */
+	/* Sets tuner at some freq (87.5 MHz) and see if it is ok */
+	div = ((87500 * 4000 + 700000 + 225000) + 16768) >> 15;
+	buffer[0] = ((div >> 8) & 0x3f) | TEA5767_MUTE;
+	buffer[1] = div & 0xff;
+	buffer[2] = TEA5767_PORT1_HIGH;
+	buffer[3] = TEA5767_PORT2_HIGH | TEA5767_HIGH_CUT_CTRL |
+		    TEA5767_ST_NOISE_CTL;
+	buffer[4] = 0;
+
+	if (5 != (rc = tuner_i2c_xfer_send(&i2c, buffer, 5)))
+		printk(KERN_WARNING "i2c i/o error: rc == %d (should be 5)\n", rc);
+
+	msleep(15);
+
+	if (5 != (rc = tuner_i2c_xfer_recv(&i2c, buffer, 5))) {
+		printk(KERN_WARNING "It is not a TEA5767. Received %i bytes.\n", rc);
+		return -EINVAL;
+	}
 
+	/* Initial freq for 32.768KHz clock */
+	if ((buffer[1] != (div & 0xff) ) || ((buffer[0] & 0x3f) != ((div >> 8) & 0x3f))) {
+		printk(KERN_WARNING "It is not a TEA5767. div=%d, Return: %02x %02x %02x %02x %02x\n",
+				div,buffer[0],buffer[1],buffer[2],buffer[3],buffer[4]);
+		tea5767_status_dump(buffer);
+		return -EINVAL;
+	}
+#endif
 	return 0;
 }
 
@@ -443,6 +481,10 @@ struct dvb_frontend *tea5767_attach(stru
 {
 	struct tea5767_priv *priv = NULL;
 
+#if 0 /* By removing autodetection allows forcing TEA chip */
+	if (tea5767_autodetection(i2c_adap, i2c_addr) == -EINVAL)
+		return -EINVAL;
+#endif
 	priv = kzalloc(sizeof(struct tea5767_priv), GFP_KERNEL);
 	if (priv == NULL)
 		return NULL;
diff -upr /tmp/stripped/drivers/media/common/tuners/tuner-simple.c /tmp/not_stripped/drivers/media/common/tuners/tuner-simple.c
--- /tmp/stripped/drivers/media/common/tuners/tuner-simple.c	2011-01-10 10:01:50.000000000 -0200
+++ /tmp/not_stripped/drivers/media/common/tuners/tuner-simple.c	2011-01-10 10:02:06.000000000 -0200
@@ -161,6 +161,12 @@ static inline int tuner_afcstatus(const 
 	return (status & TUNER_AFC) - 2;
 }
 
+#if 0 /* unused */
+static inline int tuner_mode(const int status)
+{
+	return (status & TUNER_MODE) >> 3;
+}
+#endif
 
 static int simple_get_status(struct dvb_frontend *fe, u32 *status)
 {
diff -upr /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c
--- /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c	2011-01-10 10:01:49.000000000 -0200
+++ /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c	2011-01-10 10:02:05.000000000 -0200
@@ -272,6 +272,32 @@ static const struct pci_device_id ngene_
 	NGENE_ID(0x18c3, 0xdd10, ngene_info_duoFlexS2),
 	NGENE_ID(0x18c3, 0xdd20, ngene_info_duoFlexS2),
 	NGENE_ID(0x1461, 0x062e, ngene_info_m780),
+#if 0 /* not (yet?) supported */
+	NGENE_ID(0x18c3, 0x0000, ngene_info_appboard),
+	NGENE_ID(0x18c3, 0x0004, ngene_info_appboard),
+	NGENE_ID(0x18c3, 0x8011, ngene_info_appboard),
+	NGENE_ID(0x18c3, 0x8015, ngene_info_appboard_ntsc),
+	NGENE_ID(0x153b, 0x1167, ngene_info_terratec),
+	NGENE_ID(0x18c3, 0x0030, ngene_info_python),
+	NGENE_ID(0x18c3, 0x0052, ngene_info_sidewinder),
+	NGENE_ID(0x18c3, 0x8f00, ngene_info_racer),
+	NGENE_ID(0x18c3, 0x0041, ngene_info_viper_v1),
+	NGENE_ID(0x18c3, 0x0042, ngene_info_viper_v2),
+	NGENE_ID(0x14f3, 0x0041, ngene_info_vbox_v1),
+	NGENE_ID(0x14f3, 0x0043, ngene_info_vbox_v2),
+	NGENE_ID(0x18c3, 0xabcd, ngene_info_s2),
+	NGENE_ID(0x18c3, 0xabc2, ngene_info_s2_b),
+	NGENE_ID(0x18c3, 0xabc3, ngene_info_s2_b),
+	NGENE_ID(0x18c3, 0x0001, ngene_info_appboard),
+	NGENE_ID(0x18c3, 0x0005, ngene_info_appboard),
+	NGENE_ID(0x18c3, 0x0009, ngene_info_appboard_atsc),
+	NGENE_ID(0x18c3, 0x000b, ngene_info_appboard_atsc),
+	NGENE_ID(0x18c3, 0x0010, ngene_info_shrek_50_fp),
+	NGENE_ID(0x18c3, 0x0011, ngene_info_shrek_60_fp),
+	NGENE_ID(0x18c3, 0x0012, ngene_info_shrek_50),
+	NGENE_ID(0x18c3, 0x0013, ngene_info_shrek_60),
+	NGENE_ID(0x18c3, 0x0000, ngene_info_hognose),
+#endif
 	{0}
 };
 MODULE_DEVICE_TABLE(pci, ngene_id_tbl);
diff -upr /tmp/stripped/drivers/media/video/bt8xx/bttv-cards.c /tmp/not_stripped/drivers/media/video/bt8xx/bttv-cards.c
--- /tmp/stripped/drivers/media/video/bt8xx/bttv-cards.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/bt8xx/bttv-cards.c	2011-01-10 10:02:08.000000000 -0200
@@ -1801,12 +1801,21 @@ struct tvcard bttv_tvcards[] = {
 		.name           = "Osprey 540",   /* 540 */
 		.video_inputs   = 4,
 		/* .audio_inputs= 1, */
+	#if 0 /* TODO ... */
+		.svhs           = OSPREY540_SVID_ANALOG,
+		.muxsel         = {       [OSPREY540_COMP_ANALOG] = 2,
+					[OSPREY540_SVID_ANALOG] = 3, },
+	#endif
 		.pll            = PLL_28,
 		.tuner_type     = TUNER_ABSENT,
 		.tuner_addr	= ADDR_UNSET,
 		.no_msp34xx     = 1,
 		.no_tda9875     = 1,
 		.no_tda7432     = 1,
+	#if 0 /* TODO ... */
+		.muxsel_hook    = osprey_540_muxsel,
+		.picture_hook   = osprey_540_set_picture,
+	#endif
 	},
 
 		/* ---- card 0x5C ---------------------------------- */
diff -upr /tmp/stripped/drivers/media/video/bt8xx/bttv-driver.c /tmp/not_stripped/drivers/media/video/bt8xx/bttv-driver.c
--- /tmp/stripped/drivers/media/video/bt8xx/bttv-driver.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/bt8xx/bttv-driver.c	2011-01-10 10:02:08.000000000 -0200
@@ -937,10 +937,12 @@ disclaim_video_lines(struct bttv *btv)
 static
 void free_btres(struct bttv *btv, struct bttv_fh *fh, int bits)
 {
+#if 1 /* DEBUG */
 	if ((fh->resources & bits) != bits) {
 		/* trying to free ressources not allocated by us ... */
 		printk("bttv: BUG! (btres)\n");
 	}
+#endif
 	mutex_lock(&btv->lock);
 	fh->resources  &= ~bits;
 	btv->resources &= ~bits;
diff -upr /tmp/stripped/drivers/media/video/bt8xx/bttv-risc.c /tmp/not_stripped/drivers/media/video/bt8xx/bttv-risc.c
--- /tmp/stripped/drivers/media/video/bt8xx/bttv-risc.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/bt8xx/bttv-risc.c	2011-01-10 10:02:08.000000000 -0200
@@ -349,6 +349,10 @@ bttv_calc_geo_old(struct bttv *btv, stru
 	}
 
 	vdelay = tvnorm->vdelay;
+#if 0 /* FIXME */
+	if (vdelay < btv->vbi.lines*2)
+		vdelay = btv->vbi.lines*2;
+#endif
 
 	xsf = (width*scaledtwidth)/swidth;
 	geo->hscale =  ((totalwidth*4096UL)/xsf-4096);
diff -upr /tmp/stripped/drivers/media/video/cx88/cx88-core.c /tmp/not_stripped/drivers/media/video/cx88/cx88-core.c
--- /tmp/stripped/drivers/media/video/cx88/cx88-core.c	2011-01-10 10:01:51.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/cx88/cx88-core.c	2011-01-10 10:02:07.000000000 -0200
@@ -430,6 +430,25 @@ static int cx88_risc_decode(u32 risc)
 	return incr[risc >> 28] ? incr[risc >> 28] : 1;
 }
 
+#if 0 /* currently unused, but useful for debugging */
+void cx88_risc_disasm(struct cx88_core *core,
+		      struct btcx_riscmem *risc)
+{
+	unsigned int i,j,n;
+
+	printk("%s: risc disasm: %p [dma=0x%08lx]\n",
+	       core->name, risc->cpu, (unsigned long)risc->dma);
+	for (i = 0; i < (risc->size >> 2); i += n) {
+		printk("%s:   %04d: ", core->name, i);
+		n = cx88_risc_decode(risc->cpu[i]);
+		for (j = 1; j < n; j++)
+			printk("%s:   %04d: 0x%08x [ arg #%d ]\n",
+			       core->name, i+j, risc->cpu[i+j], j);
+		if (risc->cpu[i] == RISC_JUMP)
+			break;
+	}
+}
+#endif
 
 void cx88_sram_channel_dump(struct cx88_core *core,
 			    struct sram_channel *ch)
diff -upr /tmp/stripped/drivers/media/video/cx88/cx88-reg.h /tmp/not_stripped/drivers/media/video/cx88/cx88-reg.h
--- /tmp/stripped/drivers/media/video/cx88/cx88-reg.h	2011-01-10 10:01:51.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/cx88/cx88-reg.h	2011-01-10 10:02:07.000000000 -0200
@@ -661,11 +661,18 @@
 #define EN_I2SIN_STR2DAC        0x00004000
 #define EN_I2SIN_ENABLE         0x00008000
 
+#if 0 /* old */
+#define EN_DMTRX_SUMDIFF        0x00000800
+#define EN_DMTRX_SUMR           0x00000880
+#define EN_DMTRX_LR             0x00000900
+#define EN_DMTRX_MONO           0x00000980
+#else /* dscaler cvs */
 #define EN_DMTRX_SUMDIFF        (0 << 7)
 #define EN_DMTRX_SUMR           (1 << 7)
 #define EN_DMTRX_LR             (2 << 7)
 #define EN_DMTRX_MONO           (3 << 7)
 #define EN_DMTRX_BYPASS         (1 << 11)
+#endif
 
 // Video
 #define VID_CAPTURE_CONTROL		0x310180
diff -upr /tmp/stripped/drivers/media/video/cx88/cx88-video.c /tmp/not_stripped/drivers/media/video/cx88/cx88-video.c
--- /tmp/stripped/drivers/media/video/cx88/cx88-video.c	2011-01-10 10:01:51.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/cx88/cx88-video.c	2011-01-10 10:02:07.000000000 -0200
@@ -719,6 +719,231 @@ static struct videobuf_queue_ops cx8800_
 
 /* ------------------------------------------------------------------ */
 
+#if 0 /* overlay support not finished yet */
+static u32* ov_risc_field(struct cx8800_dev *dev, struct cx8800_fh *fh,
+			  u32 *rp, struct btcx_skiplist *skips,
+			  u32 sync_line, int skip_even, int skip_odd)
+{
+	int line,maxy,start,end,skip,nskips;
+	u32 ri,ra;
+	u32 addr;
+
+	/* sync instruction */
+	*(rp++) = cpu_to_le32(RISC_RESYNC | sync_line);
+
+	addr  = (unsigned long)dev->fbuf.base;
+	addr += dev->fbuf.fmt.bytesperline * fh->win.w.top;
+	addr += (fh->fmt->depth >> 3)      * fh->win.w.left;
+
+	/* scan lines */
+	for (maxy = -1, line = 0; line < fh->win.w.height;
+	     line++, addr += dev->fbuf.fmt.bytesperline) {
+		if ((line%2) == 0  &&  skip_even)
+			continue;
+		if ((line%2) == 1  &&  skip_odd)
+			continue;
+
+		/* calculate clipping */
+		if (line > maxy)
+			btcx_calc_skips(line, fh->win.w.width, &maxy,
+					skips, &nskips, fh->clips, fh->nclips);
+
+		/* write out risc code */
+		for (start = 0, skip = 0; start < fh->win.w.width; start = end) {
+			if (skip >= nskips) {
+				ri  = RISC_WRITE;
+				end = fh->win.w.width;
+			} else if (start < skips[skip].start) {
+				ri  = RISC_WRITE;
+				end = skips[skip].start;
+			} else {
+				ri  = RISC_SKIP;
+				end = skips[skip].end;
+				skip++;
+			}
+			if (RISC_WRITE == ri)
+				ra = addr + (fh->fmt->depth>>3)*start;
+			else
+				ra = 0;
+
+			if (0 == start)
+				ri |= RISC_SOL;
+			if (fh->win.w.width == end)
+				ri |= RISC_EOL;
+			ri |= (fh->fmt->depth>>3) * (end-start);
+
+			*(rp++)=cpu_to_le32(ri);
+			if (0 != ra)
+				*(rp++)=cpu_to_le32(ra);
+		}
+	}
+	kfree(skips);
+	return rp;
+}
+
+static int ov_risc_frame(struct cx8800_dev *dev, struct cx8800_fh *fh,
+			 struct cx88_buffer *buf)
+{
+	struct btcx_skiplist *skips;
+	u32 instructions,fields;
+	u32 *rp;
+	int rc;
+
+	/* skip list for window clipping */
+	if (NULL == (skips = kmalloc(sizeof(*skips) * fh->nclips,GFP_KERNEL)))
+		return -ENOMEM;
+
+	fields = 0;
+	if (V4L2_FIELD_HAS_TOP(fh->win.field))
+		fields++;
+	if (V4L2_FIELD_HAS_BOTTOM(fh->win.field))
+		fields++;
+
+	/* estimate risc mem: worst case is (clip+1) * lines instructions
+	   + syncs + jump (all 2 dwords) */
+	instructions  = (fh->nclips+1) * fh->win.w.height;
+	instructions += 3 + 4;
+	if ((rc = btcx_riscmem_alloc(dev->pci,&buf->risc,instructions*8)) < 0) {
+		kfree(skips);
+		return rc;
+	}
+
+	/* write risc instructions */
+	rp = buf->risc.cpu;
+	switch (fh->win.field) {
+	case V4L2_FIELD_TOP:
+		rp = ov_risc_field(dev, fh, rp, skips, 0,     0, 0);
+		break;
+	case V4L2_FIELD_BOTTOM:
+		rp = ov_risc_field(dev, fh, rp, skips, 0x200, 0, 0);
+		break;
+	case V4L2_FIELD_INTERLACED:
+		rp = ov_risc_field(dev, fh, rp, skips, 0,     0, 1);
+		rp = ov_risc_field(dev, fh, rp, skips, 0x200, 1, 0);
+		break;
+	default:
+		BUG();
+	}
+
+	/* save pointer to jmp instruction address */
+	buf->risc.jmp = rp;
+	kfree(skips);
+	return 0;
+}
+
+static int verify_window(struct cx8800_dev *dev, struct v4l2_window *win)
+{
+	enum v4l2_field field;
+	int maxw, maxh;
+
+	if (NULL == dev->fbuf.base)
+		return -EINVAL;
+	if (win->w.width < 48 || win->w.height <  32)
+		return -EINVAL;
+	if (win->clipcount > 2048)
+		return -EINVAL;
+
+	field = win->field;
+	maxw  = norm_maxw(core->tvnorm);
+	maxh  = norm_maxh(core->tvnorm);
+
+	if (V4L2_FIELD_ANY == field) {
+		field = (win->w.height > maxh/2)
+			? V4L2_FIELD_INTERLACED
+			: V4L2_FIELD_TOP;
+	}
+	switch (field) {
+	case V4L2_FIELD_TOP:
+	case V4L2_FIELD_BOTTOM:
+		maxh = maxh / 2;
+		break;
+	case V4L2_FIELD_INTERLACED:
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	win->field = field;
+	if (win->w.width > maxw)
+		win->w.width = maxw;
+	if (win->w.height > maxh)
+		win->w.height = maxh;
+	return 0;
+}
+
+static int setup_window(struct cx8800_dev *dev, struct cx8800_fh *fh,
+			struct v4l2_window *win)
+{
+	struct v4l2_clip *clips = NULL;
+	int n,size,retval = 0;
+
+	if (NULL == fh->fmt)
+		return -EINVAL;
+	retval = verify_window(dev,win);
+	if (0 != retval)
+		return retval;
+
+	/* copy clips  --  luckily v4l1 + v4l2 are binary
+	   compatible here ...*/
+	n = win->clipcount;
+	size = sizeof(*clips)*(n+4);
+	clips = kmalloc(size,GFP_KERNEL);
+	if (NULL == clips)
+		return -ENOMEM;
+	if (n > 0) {
+		if (copy_from_user(clips,win->clips,sizeof(struct v4l2_clip)*n)) {
+			kfree(clips);
+			return -EFAULT;
+		}
+	}
+
+	/* clip against screen */
+	if (NULL != dev->fbuf.base)
+		n = btcx_screen_clips(dev->fbuf.fmt.width, dev->fbuf.fmt.height,
+				      &win->w, clips, n);
+	btcx_sort_clips(clips,n);
+
+	/* 4-byte alignments */
+	switch (fh->fmt->depth) {
+	case 8:
+	case 24:
+		btcx_align(&win->w, clips, n, 3);
+		break;
+	case 16:
+		btcx_align(&win->w, clips, n, 1);
+		break;
+	case 32:
+		/* no alignment fixups needed */
+		break;
+	default:
+		BUG();
+	}
+
+	down(&fh->vidq.lock);
+	if (fh->clips)
+		kfree(fh->clips);
+	fh->clips    = clips;
+	fh->nclips   = n;
+	fh->win      = *win;
+/* #if 0 */
+	fh->ov.setup_ok = 1;
+/* #endif */
+
+	/* update overlay if needed */
+	retval = 0;
+/* #if 0 */
+	if (check_btres(fh, RESOURCE_OVERLAY)) {
+		struct bttv_buffer *new;
+
+		new = videobuf_pci_alloc(sizeof(*new));
+		bttv_overlay_risc(btv, &fh->ov, fh->ovfmt, new);
+		retval = bttv_switch_overlay(btv,fh,new);
+	}
+/* #endif */
+	up(&fh->vidq.lock);
+	return retval;
+}
+#endif
 
 /* ------------------------------------------------------------------ */
 
diff -upr /tmp/stripped/drivers/media/video/em28xx/em28xx-cards.c /tmp/not_stripped/drivers/media/video/em28xx/em28xx-cards.c
--- /tmp/stripped/drivers/media/video/em28xx/em28xx-cards.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/em28xx/em28xx-cards.c	2011-01-10 10:02:08.000000000 -0200
@@ -106,9 +106,21 @@ static struct em28xx_reg_seq em2880_msi_
 };
 
 /* Boards - EM2880 MSI DIGIVOX AD and EM2880_BOARD_MSI_DIGIVOX_AD_II */
+#if 0	/* Still missing the dvb setup */
+static struct em28xx_reg_seq em2880_msi_digivox_ad_digital[] = {
+	{EM28XX_R08_GPIO,	0x6a,	~EM_GPIO_4,	10},
+	{	-1,		-1,	-1,		-1},
+};
+#endif
 
 /* Board  - EM2870 Kworld 355u
    Analog - No input analog */
+#if 0	/* Still missing the dvb setup */
+static struct em28xx_reg_seq em2870_kworld_355u_digital[] = {
+	{EM2880_R04_GPO,	0x01,	0xff,		10},
+	{  -1,			-1,	-1,		-1},
+};
+#endif
 
 /* Board - EM2882 Kworld 315U digital */
 static struct em28xx_reg_seq em2882_kworld_315u_digital[] = {
@@ -656,6 +668,10 @@ struct em28xx_board em28xx_boards[] = {
 		.tuner_gpio   = default_tuner_gpio,
 		.decoder      = EM28XX_TVP5150,
 
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = hauppauge_wintv_hvr_900_digital,
+#endif
 		.input        = { {
 			.type     = EM28XX_VMUX_TELEVISION,
 			.vmux     = TVP5150_COMPOSITE0,
@@ -758,6 +774,10 @@ struct em28xx_board em28xx_boards[] = {
 		.valid        = EM28XX_BOARD_NOT_VALIDATED,
 		.tuner_type   = TUNER_XC2028,
 		.tuner_gpio   = default_tuner_gpio,
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = default_digital,
+#endif
 	},
 	[EM2870_BOARD_TERRATEC_XS_MT2060] = {
 		.name         = "Terratec Cinergy T XS (MT2060)",
@@ -769,10 +789,18 @@ struct em28xx_board em28xx_boards[] = {
 		.valid        = EM28XX_BOARD_NOT_VALIDATED,
 		.tuner_type   = TUNER_XC2028,
 		.tuner_gpio   = default_tuner_gpio,
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = default_digital,
+#endif
 	},
 	[EM2870_BOARD_KWORLD_355U] = {
 		.name         = "Kworld 355 U DVB-T",
 		.valid        = EM28XX_BOARD_NOT_VALIDATED,
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = em2870_kworld_355u_digital,
+#endif
 	},
 	[EM2870_BOARD_PINNACLE_PCTV_DVB] = {
 		.name         = "Pinnacle PCTV DVB-T",
@@ -848,6 +876,10 @@ struct em28xx_board em28xx_boards[] = {
 		.mts_firmware = 1,
 		.ir_codes     = RC_MAP_HAUPPAUGE_NEW,
 		.decoder      = EM28XX_TVP5150,
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = hauppauge_wintv_hvr_900_digital,
+#endif
 		.input        = { {
 			.type     = EM28XX_VMUX_TELEVISION,
 			.vmux     = TVP5150_COMPOSITE0,
@@ -1003,6 +1035,10 @@ struct em28xx_board em28xx_boards[] = {
 		.tuner_type   = TUNER_XC2028,
 		.tuner_gpio   = default_tuner_gpio,
 		.decoder      = EM28XX_TVP5150,
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = hauppauge_wintv_hvr_900_digital,
+#endif
 		.input        = { {
 			.type     = EM28XX_VMUX_TELEVISION,
 			.vmux     = TVP5150_COMPOSITE0,
@@ -1245,6 +1281,10 @@ struct em28xx_board em28xx_boards[] = {
 		.tuner_type   = TUNER_XC2028,
 		.tuner_gpio   = default_tuner_gpio,
 		.decoder      = EM28XX_TVP5150,
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = em2880_msi_digivox_ad_digital,
+#endif
 		.input        = { {
 			.type     = EM28XX_VMUX_TELEVISION,
 			.vmux     = TVP5150_COMPOSITE0,
@@ -1268,6 +1308,10 @@ struct em28xx_board em28xx_boards[] = {
 		.tuner_type   = TUNER_XC2028,
 		.tuner_gpio   = default_tuner_gpio,
 		.decoder      = EM28XX_TVP5150,
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = em2880_msi_digivox_ad_digital,
+#endif
 		.input        = { {
 			.type     = EM28XX_VMUX_TELEVISION,
 			.vmux     = TVP5150_COMPOSITE0,
@@ -1394,6 +1438,10 @@ struct em28xx_board em28xx_boards[] = {
 		.tuner_type   = TUNER_XC2028,
 		.tuner_gpio   = default_tuner_gpio,
 		.decoder      = EM28XX_TVP5150,
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = default_digital,
+#endif
 		.input        = { {
 			.type     = EM28XX_VMUX_TELEVISION,
 			.vmux     = TVP5150_COMPOSITE0,
@@ -1442,6 +1490,10 @@ struct em28xx_board em28xx_boards[] = {
 		.tuner_gpio   = default_tuner_gpio,
 		.mts_firmware = 1,
 		.decoder      = EM28XX_TVP5150,
+#if 0 /* FIXME: add an entry at em28xx-dvb */
+		.has_dvb      = 1,
+		.dvb_gpio     = hauppauge_wintv_hvr_900_digital,
+#endif
 		.input        = { {
 			.type     = EM28XX_VMUX_TELEVISION,
 			.vmux     = TVP5150_COMPOSITE0,
diff -upr /tmp/stripped/drivers/media/video/gspca/pac7302.c /tmp/not_stripped/drivers/media/video/gspca/pac7302.c
--- /tmp/stripped/drivers/media/video/gspca/pac7302.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/gspca/pac7302.c	2011-01-10 10:02:08.000000000 -0200
@@ -415,6 +415,27 @@ static void reg_w_buf(struct gspca_dev *
 	}
 }
 
+#if 0 /* not used */
+static __u8 reg_r(struct gspca_dev *gspca_dev,
+			     __u8 index)
+{
+	int ret;
+
+	ret = usb_control_msg(gspca_dev->dev,
+			usb_rcvctrlpipe(gspca_dev->dev, 0),
+			0,			/* request */
+			USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+			0,			/* value */
+			index, gspca_dev->usb_buf, 1,
+			500);
+	if (ret < 0)
+		PDEBUG(D_ERR, "reg_r(): "
+		"Failed to read register from index 0x%x, error %i",
+		index, ret);
+
+	return gspca_dev->usb_buf[0];
+}
+#endif
 
 static void reg_w(struct gspca_dev *gspca_dev,
 		  __u8 index,
diff -upr /tmp/stripped/drivers/media/video/gspca/pac7311.c /tmp/not_stripped/drivers/media/video/gspca/pac7311.c
--- /tmp/stripped/drivers/media/video/gspca/pac7311.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/gspca/pac7311.c	2011-01-10 10:02:09.000000000 -0200
@@ -283,6 +283,27 @@ static void reg_w_buf(struct gspca_dev *
 	}
 }
 
+#if 0 /* not used */
+static __u8 reg_r(struct gspca_dev *gspca_dev,
+			     __u8 index)
+{
+	int ret;
+
+	ret = usb_control_msg(gspca_dev->dev,
+			usb_rcvctrlpipe(gspca_dev->dev, 0),
+			0,			/* request */
+			USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+			0,			/* value */
+			index, gspca_dev->usb_buf, 1,
+			500);
+	if (ret < 0)
+		PDEBUG(D_ERR, "reg_r(): "
+		"Failed to read register from index 0x%x, error %i",
+		index, ret);
+
+	return gspca_dev->usb_buf[0];
+}
+#endif
 
 static void reg_w(struct gspca_dev *gspca_dev,
 		  __u8 index,
diff -upr /tmp/stripped/drivers/media/video/gspca/stv0680.c /tmp/not_stripped/drivers/media/video/gspca/stv0680.c
--- /tmp/stripped/drivers/media/video/gspca/stv0680.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/gspca/stv0680.c	2011-01-10 10:02:09.000000000 -0200
@@ -195,6 +195,19 @@ static int sd_config(struct gspca_dev *g
 	PDEBUG(D_PROBE, "Sensor ID is %i",
 	       (gspca_dev->usb_buf[4]*16) + (gspca_dev->usb_buf[5]>>4));
 
+#if 0 /* The v4l1 driver used to this but I don't think it is necessary */
+	ret = usb_set_interface(gspca_dev->dev, gspca_dev->iface, 1);
+	if (ret < 0) {
+		PDEBUG(D_ERR, "Set alt 1 failed (%d)", ret);
+		return ret;
+	}
+
+	if (stv_sndctrl(gspca_dev, 0, 0x85, 0, 0x10) != 0x10)
+		return stv0680_handle_error(gspca_dev, -EIO);
+	if (stv_sndctrl(gspca_dev, 0, 0x8d, 0, 0x08) != 0x08)
+		return stv0680_handle_error(gspca_dev, -EIO);
+	PDEBUG(D_PROBE, "Camera has %i pictures.", gspca_dev->usb_buf[3]);
+#endif
 
 	ret = stv0680_get_video_mode(gspca_dev);
 	if (ret < 0)
@@ -230,6 +243,13 @@ static int sd_config(struct gspca_dev *g
 	cam->cam_mode = &sd->mode;
 	cam->nmodes = 1;
 
+#if 0 /* The v4l1 driver used to this but I don't think it is necessary */
+	ret = usb_set_interface(gspca_dev->dev, gspca_dev->iface, 0);
+	if (ret < 0) {
+		PDEBUG(D_ERR, "Set alt 0 failed (%d)", ret);
+		return ret;
+	}
+#endif
 
 	ret = stv0680_set_video_mode(gspca_dev, sd->orig_mode);
 	if (ret < 0)
diff -upr /tmp/stripped/drivers/media/video/gspca/vc032x.c /tmp/not_stripped/drivers/media/video/gspca/vc032x.c
--- /tmp/stripped/drivers/media/video/gspca/vc032x.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/gspca/vc032x.c	2011-01-10 10:02:09.000000000 -0200
@@ -253,16 +253,37 @@ static const struct v4l2_pix_format vc03
 		.priv = 2},
 };
 static const struct v4l2_pix_format bi_mode[] = {
+#if 0 /* JPEG vc0323 */
+	{320, 240, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+		.bytesperline = 320,
+		.sizeimage = 320 * 240 * 3 / 8 + 590,
+		.colorspace = V4L2_COLORSPACE_JPEG,
+		.priv = 5},
+#endif
 	{320, 240, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
 		.bytesperline = 320,
 		.sizeimage = 320 * 240 * 2,
 		.colorspace = V4L2_COLORSPACE_SRGB,
 		.priv = 2},
+#if 0 /* JPEG vc0323 */
+	{640, 480, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+		.bytesperline = 640,
+		.sizeimage = 640 * 480 * 3 / 8 + 590,
+		.colorspace = V4L2_COLORSPACE_JPEG,
+		.priv = 4},
+#endif
 	{640, 480, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
 		.bytesperline = 640,
 		.sizeimage = 640 * 480 * 2,
 		.colorspace = V4L2_COLORSPACE_SRGB,
 		.priv = 1},
+#if 0 /* JPEG vc0323 */
+	{1280, 1024, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+		.bytesperline = 1280,
+		.sizeimage = 1280 * 1024 * 1 / 4 + 590,
+		.colorspace = V4L2_COLORSPACE_JPEG,
+		.priv = 3},
+#endif
 	{1280, 1024, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
 		.bytesperline = 1280,
 		.sizeimage = 1280 * 1024 * 2,
@@ -1195,6 +1216,123 @@ static const u8 mi1320_soc_InitVGA[][4] 
 	{0xb3, 0x5c, 0x01, 0xcc},
 	{}
 };
+#if 0 /* JPEG vc0323 */
+static const u8 mi1320_soc_InitVGA_JPG[][4] = {
+	{0xb3, 0x01, 0x01, 0xcc},
+	{0xb0, 0x03, 0x19, 0xcc},
+	{0xb0, 0x04, 0x02, 0xcc},
+	{0x00, 0x00, 0x30, 0xdd},
+	{0xb3, 0x00, 0x64, 0xcc},
+	{0xb3, 0x00, 0x67, 0xcc},
+	{0xb3, 0x05, 0x01, 0xcc},
+	{0xb3, 0x06, 0x01, 0xcc},
+	{0xb3, 0x08, 0x01, 0xcc},
+	{0xb3, 0x09, 0x0c, 0xcc},
+	{0xb3, 0x34, 0x02, 0xcc},
+	{0xb3, 0x35, 0xc8, 0xcc},
+	{0xb3, 0x02, 0x00, 0xcc},
+	{0xb3, 0x03, 0x0a, 0xcc},
+	{0xb3, 0x04, 0x05, 0xcc},
+	{0xb3, 0x20, 0x00, 0xcc},
+	{0xb3, 0x21, 0x00, 0xcc},
+	{0xb3, 0x22, 0x01, 0xcc},
+	{0xb3, 0x23, 0xe0, 0xcc},
+	{0xb3, 0x14, 0x00, 0xcc},
+	{0xb3, 0x15, 0x00, 0xcc},
+	{0xb3, 0x16, 0x02, 0xcc},
+	{0xb3, 0x17, 0x7f, 0xcc},
+	{0xb3, 0x00, 0x67, 0xcc},
+	{0xb8, 0x00, 0x00, 0xcc},
+	{0xbc, 0x00, 0x71, 0xcc},
+	{0xbc, 0x01, 0x01, 0xcc},
+	{0xb3, 0x5c, 0x01, 0xcc},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x00, 0x00, 0x10, 0xdd},
+	{0xc8, 0x00, 0x00, 0xbb},
+	{0x00, 0x00, 0x30, 0xdd},
+	{0xf0, 0x00, 0x00, 0xbb},
+	{0x00, 0x00, 0x10, 0xdd},
+	{0x07, 0x00, 0xe0, 0xbb},
+	{0x08, 0x00, 0x0b, 0xbb},
+	{0x21, 0x00, 0x0c, 0xbb},
+	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
+	{0xb6, 0x00, 0x00, 0xcc},
+	{0xb6, 0x03, 0x02, 0xcc},
+	{0xb6, 0x02, 0x80, 0xcc},
+	{0xb6, 0x05, 0x01, 0xcc},
+	{0xb6, 0x04, 0xe0, 0xcc},
+	{0xb6, 0x12, 0xf8, 0xcc},
+	{0xb6, 0x13, 0x05, 0xcc},
+	{0xb6, 0x18, 0x02, 0xcc},
+	{0xb6, 0x17, 0x58, 0xcc},
+	{0xb6, 0x16, 0x00, 0xcc},
+	{0xb6, 0x22, 0x12, 0xcc},
+	{0xb6, 0x23, 0x0b, 0xcc},
+	{0xbf, 0xc0, 0x39, 0xcc},
+	{0xbf, 0xc1, 0x04, 0xcc},
+	{0xbf, 0xcc, 0x00, 0xcc},
+	{0xb3, 0x01, 0x41, 0xcc},
+	{0xf0, 0x00, 0x00, 0xbb},
+	{0x05, 0x01, 0x78, 0xbb},
+	{0x06, 0x00, 0x11, 0xbb},
+	{0x07, 0x01, 0x42, 0xbb},
+	{0x08, 0x00, 0x11, 0xbb},
+	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
+	{0x21, 0x80, 0x00, 0xbb},
+	{0x22, 0x0d, 0x0f, 0xbb},
+	{0x24, 0x80, 0x00, 0xbb},
+	{0x59, 0x00, 0xff, 0xbb},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x39, 0x03, 0xca, 0xbb},
+	{0x3a, 0x06, 0x80, 0xbb},
+	{0x3b, 0x01, 0x52, 0xbb},
+	{0x3c, 0x05, 0x40, 0xbb},
+	{0x57, 0x01, 0x9c, 0xbb},
+	{0x58, 0x01, 0xee, 0xbb},
+	{0x59, 0x00, 0xf0, 0xbb},
+	{0x5a, 0x01, 0x20, 0xbb},
+	{0x5c, 0x1d, 0x17, 0xbb},
+	{0x5d, 0x22, 0x1c, 0xbb},
+	{0x64, 0x1e, 0x1c, 0xbb},
+	{0x5b, 0x00, 0x00, 0xbb},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x22, 0xa0, 0x78, 0xbb},
+	{0x23, 0xa0, 0x78, 0xbb},
+	{0x24, 0x7f, 0x00, 0xbb},
+	{0x28, 0xea, 0x02, 0xbb},
+	{0x29, 0x86, 0x7a, 0xbb},
+	{0x5e, 0x52, 0x4c, 0xbb},
+	{0x5f, 0x20, 0x24, 0xbb},
+	{0x60, 0x00, 0x02, 0xbb},
+	{0x02, 0x00, 0xee, 0xbb},
+	{0x03, 0x39, 0x23, 0xbb},
+	{0x04, 0x07, 0x24, 0xbb},
+	{0x09, 0x00, 0xc0, 0xbb},
+	{0x0a, 0x00, 0x79, 0xbb},
+	{0x0b, 0x00, 0x04, 0xbb},
+	{0x0c, 0x00, 0x5c, 0xbb},
+	{0x0d, 0x00, 0xd9, 0xbb},
+	{0x0e, 0x00, 0x53, 0xbb},
+	{0x0f, 0x00, 0x21, 0xbb},
+	{0x10, 0x00, 0xa4, 0xbb},
+	{0x11, 0x00, 0xe5, 0xbb},
+	{0x15, 0x00, 0x00, 0xbb},
+	{0x16, 0x00, 0x00, 0xbb},
+	{0x17, 0x00, 0x00, 0xbb},
+	{0x18, 0x00, 0x00, 0xbb},
+	{0x19, 0x00, 0x00, 0xbb},
+	{0x1a, 0x00, 0x00, 0xbb},
+	{0x1b, 0x00, 0x00, 0xbb},
+	{0x1c, 0x00, 0x00, 0xbb},
+	{0x1d, 0x00, 0x00, 0xbb},
+	{0x1e, 0x00, 0x00, 0xbb},
+	{0xf0, 0x00, 0x01, 0xbb},
+	{0x06, 0xe0, 0x0e, 0xbb},
+	{0x06, 0x60, 0x0e, 0xbb},
+	{0xb3, 0x5c, 0x01, 0xcc},
+	{}
+};
+#endif
 static const u8 mi1320_soc_InitQVGA[][4] = {
 	{0xb3, 0x01, 0x01, 0xcc},
 	{0xb0, 0x03, 0x19, 0xcc},
@@ -1308,6 +1446,272 @@ static const u8 mi1320_soc_InitQVGA[][4]
 	{0xb3, 0x5c, 0x01, 0xcc},
 	{}
 };
+#if 0 /* JPEG vc0323 */
+static const u8 mi1320_soc_InitQVGA_JPG[][4] = {
+	{0xb3, 0x01, 0x01, 0xcc},
+	{0xb0, 0x03, 0x19, 0xcc},
+	{0xb0, 0x04, 0x02, 0xcc},
+	{0x00, 0x00, 0x30, 0xdd},
+	{0xb3, 0x00, 0x64, 0xcc},
+	{0xb3, 0x00, 0x67, 0xcc},
+	{0xb3, 0x05, 0x01, 0xcc},
+	{0xb3, 0x06, 0x01, 0xcc},
+	{0xb3, 0x08, 0x01, 0xcc},
+	{0xb3, 0x09, 0x0c, 0xcc},
+	{0xb3, 0x34, 0x02, 0xcc},
+	{0xb3, 0x35, 0xc8, 0xcc},
+	{0xb3, 0x02, 0x00, 0xcc},
+	{0xb3, 0x03, 0x0a, 0xcc},
+	{0xb3, 0x04, 0x05, 0xcc},
+	{0xb3, 0x20, 0x00, 0xcc},
+	{0xb3, 0x21, 0x00, 0xcc},
+	{0xb3, 0x22, 0x01, 0xcc},
+	{0xb3, 0x23, 0xe0, 0xcc},
+	{0xb3, 0x14, 0x00, 0xcc},
+	{0xb3, 0x15, 0x00, 0xcc},
+	{0xb3, 0x16, 0x02, 0xcc},
+	{0xb3, 0x17, 0x7f, 0xcc},
+	{0xb3, 0x00, 0x67, 0xcc},
+	{0xb8, 0x00, 0x00, 0xcc},
+	{0xbc, 0x00, 0xd1, 0xcc},
+	{0xbc, 0x01, 0x01, 0xcc},
+	{0xb3, 0x5c, 0x01, 0xcc},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x00, 0x00, 0x10, 0xdd},
+	{0xc8, 0x00, 0x00, 0xbb},
+	{0x00, 0x00, 0x30, 0xdd},
+	{0xf0, 0x00, 0x00, 0xbb},
+	{0x00, 0x00, 0x10, 0xdd},
+	{0x07, 0x00, 0xe0, 0xbb},
+	{0x08, 0x00, 0x0b, 0xbb},
+	{0x21, 0x00, 0x0c, 0xbb},
+	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
+	{0xb6, 0x00, 0x00, 0xcc},
+	{0xb6, 0x03, 0x01, 0xcc},
+	{0xb6, 0x02, 0x40, 0xcc},
+	{0xb6, 0x05, 0x00, 0xcc},
+	{0xb6, 0x04, 0xf0, 0xcc},
+	{0xb6, 0x12, 0xf8, 0xcc},
+	{0xb6, 0x13, 0x05, 0xcc},
+	{0xb6, 0x18, 0x00, 0xcc},
+	{0xb6, 0x17, 0x96, 0xcc},
+	{0xb6, 0x16, 0x00, 0xcc},
+	{0xb6, 0x22, 0x12, 0xcc},
+	{0xb6, 0x23, 0x0b, 0xcc},
+	{0xbf, 0xc0, 0x39, 0xcc},
+	{0xbf, 0xc1, 0x04, 0xcc},
+	{0xbf, 0xcc, 0x00, 0xcc},
+	{0xbc, 0x02, 0x18, 0xcc},
+	{0xbc, 0x03, 0x50, 0xcc},
+	{0xbc, 0x04, 0x18, 0xcc},
+	{0xbc, 0x05, 0x00, 0xcc},
+	{0xbc, 0x06, 0x00, 0xcc},
+	{0xbc, 0x08, 0x30, 0xcc},
+	{0xbc, 0x09, 0x40, 0xcc},
+	{0xbc, 0x0a, 0x10, 0xcc},
+	{0xbc, 0x0b, 0x00, 0xcc},
+	{0xbc, 0x0c, 0x00, 0xcc},
+	{0xb3, 0x01, 0x41, 0xcc},
+	{0xf0, 0x00, 0x00, 0xbb},
+	{0x05, 0x01, 0x78, 0xbb},
+	{0x06, 0x00, 0x11, 0xbb},
+	{0x07, 0x01, 0x42, 0xbb},
+	{0x08, 0x00, 0x11, 0xbb},
+	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
+	{0x21, 0x80, 0x00, 0xbb},
+	{0x22, 0x0d, 0x0f, 0xbb},
+	{0x24, 0x80, 0x00, 0xbb},
+	{0x59, 0x00, 0xff, 0xbb},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x39, 0x03, 0xca, 0xbb},
+	{0x3a, 0x06, 0x80, 0xbb},
+	{0x3b, 0x01, 0x52, 0xbb},
+	{0x3c, 0x05, 0x40, 0xbb},
+	{0x57, 0x01, 0x9c, 0xbb},
+	{0x58, 0x01, 0xee, 0xbb},
+	{0x59, 0x00, 0xf0, 0xbb},
+	{0x5a, 0x01, 0x20, 0xbb},
+	{0x5c, 0x1d, 0x17, 0xbb},
+	{0x5d, 0x22, 0x1c, 0xbb},
+	{0x64, 0x1e, 0x1c, 0xbb},
+	{0x5b, 0x00, 0x00, 0xbb},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x22, 0xa0, 0x78, 0xbb},
+	{0x23, 0xa0, 0x78, 0xbb},
+	{0x24, 0x7f, 0x00, 0xbb},
+	{0x28, 0xea, 0x02, 0xbb},
+	{0x29, 0x86, 0x7a, 0xbb},
+	{0x5e, 0x52, 0x4c, 0xbb},
+	{0x5f, 0x20, 0x24, 0xbb},
+	{0x60, 0x00, 0x02, 0xbb},
+	{0x02, 0x00, 0xee, 0xbb},
+	{0x03, 0x39, 0x23, 0xbb},
+	{0x04, 0x07, 0x24, 0xbb},
+	{0x09, 0x00, 0xc0, 0xbb},
+	{0x0a, 0x00, 0x79, 0xbb},
+	{0x0b, 0x00, 0x04, 0xbb},
+	{0x0c, 0x00, 0x5c, 0xbb},
+	{0x0d, 0x00, 0xd9, 0xbb},
+	{0x0e, 0x00, 0x53, 0xbb},
+	{0x0f, 0x00, 0x21, 0xbb},
+	{0x10, 0x00, 0xa4, 0xbb},
+	{0x11, 0x00, 0xe5, 0xbb},
+	{0x15, 0x00, 0x00, 0xbb},
+	{0x16, 0x00, 0x00, 0xbb},
+	{0x17, 0x00, 0x00, 0xbb},
+	{0x18, 0x00, 0x00, 0xbb},
+	{0x19, 0x00, 0x00, 0xbb},
+	{0x1a, 0x00, 0x00, 0xbb},
+	{0x1b, 0x00, 0x00, 0xbb},
+	{0x1c, 0x00, 0x00, 0xbb},
+	{0x1d, 0x00, 0x00, 0xbb},
+	{0x1e, 0x00, 0x00, 0xbb},
+	{0xf0, 0x00, 0x01, 0xbb},
+	{0x06, 0xe0, 0x0e, 0xbb},
+	{0x06, 0x60, 0x0e, 0xbb},
+	{0xb3, 0x5c, 0x01, 0xcc},
+	{}
+};
+#endif
+#if 0 /* JPEG vc0323 */
+static const u8 mi1320_soc_InitSXGA_JPG[][4] = {
+	{0xb3, 0x01, 0x01, 0xcc},
+	{0xb0, 0x03, 0x19, 0xcc},
+	{0xb0, 0x04, 0x02, 0xcc},
+	{0x00, 0x00, 0x33, 0xdd},
+	{0xb3, 0x00, 0x64, 0xcc},
+	{0xb3, 0x00, 0x67, 0xcc},
+	{0xb3, 0x05, 0x00, 0xcc},
+	{0xb3, 0x06, 0x00, 0xcc},
+	{0xb3, 0x08, 0x01, 0xcc},
+	{0xb3, 0x09, 0x0c, 0xcc},
+	{0xb3, 0x34, 0x02, 0xcc},
+	{0xb3, 0x35, 0xc8, 0xcc},
+	{0xb3, 0x02, 0x00, 0xcc},
+	{0xb3, 0x03, 0x0a, 0xcc},
+	{0xb3, 0x04, 0x05, 0xcc},
+	{0xb3, 0x20, 0x00, 0xcc},
+	{0xb3, 0x21, 0x00, 0xcc},
+	{0xb3, 0x22, 0x04, 0xcc},
+	{0xb3, 0x23, 0x00, 0xcc},
+	{0xb3, 0x14, 0x00, 0xcc},
+	{0xb3, 0x15, 0x00, 0xcc},
+	{0xb3, 0x16, 0x04, 0xcc},
+	{0xb3, 0x17, 0xff, 0xcc},
+	{0xb3, 0x00, 0x67, 0xcc},
+	{0xbc, 0x00, 0x71, 0xcc},
+	{0xbc, 0x01, 0x01, 0xcc},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x00, 0x00, 0x30, 0xdd},
+	{0xc8, 0x9f, 0x0b, 0xbb},
+	{0x00, 0x00, 0x20, 0xdd},
+	{0x5b, 0x00, 0x01, 0xbb},
+	{0x00, 0x00, 0x20, 0xdd},
+	{0xf0, 0x00, 0x00, 0xbb},
+	{0x00, 0x00, 0x30, 0xdd},
+	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
+	{0x00, 0x00, 0x20, 0xdd},
+	{0xb6, 0x00, 0x00, 0xcc},
+	{0xb6, 0x03, 0x05, 0xcc},
+	{0xb6, 0x02, 0x00, 0xcc},
+	{0xb6, 0x05, 0x04, 0xcc},
+	{0xb6, 0x04, 0x00, 0xcc},
+	{0xb6, 0x12, 0xf8, 0xcc},
+	{0xb6, 0x13, 0x29, 0xcc},
+	{0xb6, 0x18, 0x0a, 0xcc},
+	{0xb6, 0x17, 0x00, 0xcc},
+	{0xb6, 0x16, 0x00, 0xcc},
+	{0xb6, 0x22, 0x12, 0xcc},
+	{0xb6, 0x23, 0x0b, 0xcc},
+	{0xbf, 0xc0, 0x39, 0xcc},
+	{0xbf, 0xc1, 0x04, 0xcc},
+	{0xbf, 0xcc, 0x00, 0xcc},
+	{0xb3, 0x5c, 0x01, 0xcc},
+	{0xb3, 0x01, 0x41, 0xcc},
+	{0xf0, 0x00, 0x00, 0xbb},
+	{0x05, 0x01, 0x78, 0xbb},
+	{0x06, 0x00, 0x11, 0xbb},
+	{0x07, 0x01, 0x42, 0xbb},
+	{0x08, 0x00, 0x11, 0xbb},
+	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
+	{0x21, 0x80, 0x00, 0xbb},
+	{0x22, 0x0d, 0x0f, 0xbb},
+	{0x24, 0x80, 0x00, 0xbb},
+	{0x59, 0x00, 0xff, 0xbb},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x39, 0x03, 0xca, 0xbb},
+	{0x3a, 0x06, 0x80, 0xbb},
+	{0x3b, 0x01, 0x52, 0xbb},
+	{0x3c, 0x05, 0x40, 0xbb},
+	{0x57, 0x01, 0x9c, 0xbb},
+	{0x58, 0x01, 0xee, 0xbb},
+	{0x59, 0x00, 0xf0, 0xbb},
+	{0x5a, 0x01, 0x20, 0xbb},
+	{0x5c, 0x1d, 0x17, 0xbb},
+	{0x5d, 0x22, 0x1c, 0xbb},
+	{0x64, 0x1e, 0x1c, 0xbb},
+	{0x5b, 0x00, 0x00, 0xbb},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x22, 0xa0, 0x78, 0xbb},
+	{0x23, 0xa0, 0x78, 0xbb},
+	{0x24, 0x7f, 0x00, 0xbb},
+	{0x28, 0xea, 0x02, 0xbb},
+	{0x29, 0x86, 0x7a, 0xbb},
+	{0x5e, 0x52, 0x4c, 0xbb},
+	{0x5f, 0x20, 0x24, 0xbb},
+	{0x60, 0x00, 0x02, 0xbb},
+	{0x02, 0x00, 0xee, 0xbb},
+	{0x03, 0x39, 0x23, 0xbb},
+	{0x04, 0x07, 0x24, 0xbb},
+	{0x09, 0x00, 0xc0, 0xbb},
+	{0x0a, 0x00, 0x79, 0xbb},
+	{0x0b, 0x00, 0x04, 0xbb},
+	{0x0c, 0x00, 0x5c, 0xbb},
+	{0x0d, 0x00, 0xd9, 0xbb},
+	{0x0e, 0x00, 0x53, 0xbb},
+	{0x0f, 0x00, 0x21, 0xbb},
+	{0x10, 0x00, 0xa4, 0xbb},
+	{0x11, 0x00, 0xe5, 0xbb},
+	{0x15, 0x00, 0x00, 0xbb},
+	{0x16, 0x00, 0x00, 0xbb},
+	{0x17, 0x00, 0x00, 0xbb},
+	{0x18, 0x00, 0x00, 0xbb},
+	{0x19, 0x00, 0x00, 0xbb},
+	{0x1a, 0x00, 0x00, 0xbb},
+	{0x1b, 0x00, 0x00, 0xbb},
+	{0x1c, 0x00, 0x00, 0xbb},
+	{0x1d, 0x00, 0x00, 0xbb},
+	{0x1e, 0x00, 0x00, 0xbb},
+	{0xf0, 0x00, 0x01, 0xbb},
+	{0x06, 0xe0, 0x0e, 0xbb},
+	{0x06, 0x60, 0x0e, 0xbb},
+	{0xb3, 0x5c, 0x01, 0xcc},
+	{0xf0, 0x00, 0x00, 0xbb},
+	{0x05, 0x01, 0x13, 0xbb},
+	{0x06, 0x00, 0x11, 0xbb},
+	{0x07, 0x00, 0x85, 0xbb},
+	{0x08, 0x00, 0x27, 0xbb},
+	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
+	{0x21, 0x80, 0x00, 0xbb},
+	{0x22, 0x0d, 0x0f, 0xbb},
+	{0x24, 0x80, 0x00, 0xbb},
+	{0x59, 0x00, 0xff, 0xbb},
+	{0xf0, 0x00, 0x02, 0xbb},
+	{0x39, 0x03, 0x0d, 0xbb},
+	{0x3a, 0x06, 0x1b, 0xbb},
+	{0x3b, 0x00, 0x95, 0xbb},
+	{0x3c, 0x04, 0xdb, 0xbb},
+	{0x57, 0x02, 0x00, 0xbb},
+	{0x58, 0x02, 0x66, 0xbb},
+	{0x59, 0x00, 0xff, 0xbb},
+	{0x5a, 0x01, 0x33, 0xbb},
+	{0x5c, 0x12, 0x0d, 0xbb},
+	{0x5d, 0x16, 0x11, 0xbb},
+	{0x64, 0x5e, 0x1c, 0xbb},
+	{0x2f, 0x90, 0x00, 0xbb},
+	{}
+};
+#endif
 static const u8 mi1320_soc_InitSXGA[][4] = {
 	{0xb3, 0x01, 0x01, 0xcc},
 	{0xb0, 0x03, 0x19, 0xcc},
@@ -3512,6 +3916,11 @@ static int sd_start(struct gspca_dev *gs
 		mi1320_soc_InitSXGA,
 		mi1320_soc_InitVGA,
 		mi1320_soc_InitQVGA,
+#if 0 /* JPEG vc0323 */
+		mi1320_soc_InitSXGA_JPG,
+		mi1320_soc_InitVGA_JPG,
+		mi1320_soc_InitQVGA_JPG
+#endif
 	};
 
 /*fixme: back sensor only*/
diff -upr /tmp/stripped/drivers/media/video/gspca/zc3xx.c /tmp/not_stripped/drivers/media/video/gspca/zc3xx.c
--- /tmp/stripped/drivers/media/video/gspca/zc3xx.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/gspca/zc3xx.c	2011-01-10 10:02:08.000000000 -0200
@@ -228,7 +228,11 @@ struct usb_action {
 static const struct usb_action adcm2700_Initial[] = {
 	{0xa0, 0x01, ZC3XX_R000_SYSTEMCONTROL},		/* 00,00,01,cc */
 	{0xa0, 0x04, ZC3XX_R002_CLOCKSELECT},		/* 00,02,04,cc */
+#if 1 /*jfm*/
 	{0xa0, 0x00, ZC3XX_R008_CLOCKSETTING},		/* 00,08,03,cc */
+#else
+	{0xa0, 0x03, ZC3XX_R008_CLOCKSETTING},		/* 00,08,03,cc */
+#endif
 	{0xa0, 0x0a, ZC3XX_R010_CMOSSENSORSELECT},	/* 00,10,0a,cc */
 	{0xa0, 0xd3, ZC3XX_R08B_I2CDEVICEADDR},		/* 00,8b,d3,cc */
 	{0xa0, 0x02, ZC3XX_R003_FRAMEWIDTHHIGH},	/* 00,03,02,cc */
@@ -248,7 +252,11 @@ static const struct usb_action adcm2700_
 	{0xbb, 0x00, 0x0400},				/* 04,00,00,bb */
 	{0xdd, 0x00, 0x0010},				/* 00,00,10,dd */
 	{0xbb, 0x0f, 0x140f},				/* 14,0f,0f,bb */
+#if 1 /*jfm-mswin*/
 	{0xa0, 0xb7, ZC3XX_R101_SENSORCORRECTION},	/* 01,01,37,cc */
+#else
+	{0xa0, 0x37, ZC3XX_R101_SENSORCORRECTION},	/* 01,01,37,cc */
+#endif
 	{0xa0, 0x0d, ZC3XX_R100_OPERATIONMODE},		/* 01,00,0d,cc */
 	{0xa0, 0x06, ZC3XX_R189_AWBSTATUS},		/* 01,89,06,cc */
 	{0xa0, 0x03, ZC3XX_R1C5_SHARPNESSMODE},		/* 01,c5,03,cc */
@@ -317,7 +325,11 @@ static const struct usb_action adcm2700_
 static const struct usb_action adcm2700_InitialScale[] = {
 	{0xa0, 0x01, ZC3XX_R000_SYSTEMCONTROL},		/* 00,00,01,cc */
 	{0xa0, 0x10, ZC3XX_R002_CLOCKSELECT},		/* 00,02,10,cc */
+#if 1 /*jfm*/
 	{0xa0, 0x00, ZC3XX_R008_CLOCKSETTING},		/* 00,08,03,cc */
+#else
+	{0xa0, 0x03, ZC3XX_R008_CLOCKSETTING},		/* 00,08,03,cc */
+#endif
 	{0xa0, 0x0a, ZC3XX_R010_CMOSSENSORSELECT},	/* 00,10,0a,cc */
 	{0xa0, 0xd3, ZC3XX_R08B_I2CDEVICEADDR},		/* 00,8b,d3,cc */
 	{0xa0, 0x02, ZC3XX_R003_FRAMEWIDTHHIGH},	/* 00,03,02,cc */
@@ -337,7 +349,11 @@ static const struct usb_action adcm2700_
 	{0xbb, 0x00, 0x0400},				/* 04,00,00,bb */
 	{0xdd, 0x00, 0x0010},				/* 00,00,10,dd */
 	{0xbb, 0x0f, 0x140f},				/* 14,0f,0f,bb */
+#if 1 /*jfm-mswin*/
 	{0xa0, 0xb7, ZC3XX_R101_SENSORCORRECTION},	/* 01,01,37,cc */
+#else
+	{0xa0, 0x37, ZC3XX_R101_SENSORCORRECTION},	/* 01,01,37,cc */
+#endif
 	{0xa0, 0x0d, ZC3XX_R100_OPERATIONMODE},		/* 01,00,0d,cc */
 	{0xa0, 0x06, ZC3XX_R189_AWBSTATUS},		/* 01,89,06,cc */
 	{0xa0, 0x03, ZC3XX_R1C5_SHARPNESSMODE},		/* 01,c5,03,cc */
@@ -365,9 +381,17 @@ static const struct usb_action adcm2700_
 	{0xbb, 0x5f, 0x2090},				/* 20,5f,90,bb */
 	{0xbb, 0x01, 0x8000},				/* 80,01,00,bb */
 	{0xbb, 0x09, 0x8400},				/* 84,09,00,bb */
+#if 1 /*jfm-mswin*/
 	{0xbb, 0x86, 0x0002},				/* 00,88,02,bb */
+#else
+	{0xbb, 0x88, 0x0002},				/* 00,88,02,bb */
+#endif
 	{0xbb, 0xe6, 0x0401},				/* 04,e6,01,bb */
+#if 1 /*jfm-mswin*/
 	{0xbb, 0x86, 0x0802},				/* 08,88,02,bb */
+#else
+	{0xbb, 0x88, 0x0802},				/* 08,88,02,bb */
+#endif
 	{0xbb, 0xe6, 0x0c01},				/* 0c,e6,01,bb */
 	{0xa0, 0x01, ZC3XX_R010_CMOSSENSORSELECT},	/* 00,10,01,cc */
 	{0xdd, 0x00, 0x0010},				/* 00,00,10,dd */
@@ -3159,7 +3183,12 @@ static const struct usb_action mc501cb_N
 static const struct usb_action ov7620_Initial[] = {	/* 640x480 */
 	{0xa0, 0x01, ZC3XX_R000_SYSTEMCONTROL}, /* 00,00,01,cc */
 	{0xa0, 0x40, ZC3XX_R002_CLOCKSELECT}, /* 00,02,40,cc */
+#if 1 /*jfm*/
 	{0xa0, 0x00, ZC3XX_R008_CLOCKSETTING}, /* 00,08,00,cc */
+#else
+	{0xa0, 0x03, ZC3XX_R008_CLOCKSETTING}, /* 00,08,00,cc */
+						/* mx change? */
+#endif
 	{0xa0, 0x01, ZC3XX_R001_SYSTEMOPERATING}, /* 00,01,01,cc */
 	{0xa0, 0x06, ZC3XX_R010_CMOSSENSORSELECT}, /* 00,10,06,cc */
 	{0xa0, 0x02, ZC3XX_R083_RGAINADDR}, /* 00,83,02,cc */
diff -upr /tmp/stripped/drivers/media/video/ov7670.c /tmp/not_stripped/drivers/media/video/ov7670.c
--- /tmp/stripped/drivers/media/video/ov7670.c	2011-01-10 10:01:51.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/ov7670.c	2011-01-10 10:02:07.000000000 -0200
@@ -500,6 +500,27 @@ static int ov7670_write(struct v4l2_subd
 }
 #endif /* CONFIG_OLPC_XO_1 */
 
+#if 0 /* Not currently used, but maybe should be  */
+
+static int ov7670_write_mask(struct v4l2_subdev *sd, unsigned char reg,
+		unsigned char value, unsigned char mask)
+{
+	unsigned char v;
+	int ret, tries = 0;
+
+	ret = ov7670_read(sd, reg, &v);
+	if (ret < 0)
+		return ret;
+	v &= ~mask;
+	v |= (value & mask);
+	msleep(10); /* FIXME experiment */
+	do {
+		ret = ov7670_write(sd, reg, v);
+	} while (ret < 0 && ++tries < 3);
+	return ret;
+}
+
+#endif
 
 /*
  * Write a list of register settings; ff/ff stops the process.
@@ -901,6 +922,28 @@ static int ov7670_s_parm(struct v4l2_sub
  * Code for dealing with controls.
  */
 
+#if 0  /* This seems unneeded after all, should probably come out */
+/*
+ * Fetch and store the color matrix.
+ */
+static int ov7670_get_cmatrix(struct v4l2_subdev *sd,
+	int matrix[CMATRIX_LEN])
+{
+	int i, ret;
+	unsigned char signbits;
+
+	ret = ov7670_read(sd, REG_CMATRIX_SIGN, &signbits);
+	for (i = 0; i < CMATRIX_LEN; i++) {
+		unsigned char raw;
+
+		ret += ov7670_read(sd, REG_CMATRIX_BASE + i, &raw);
+		matrix[i] = (int) raw;
+		if (signbits & (1 << i))
+			matrix[i] *= -1;
+	}
+	return ret;
+}
+#endif
 
 
 
diff -upr /tmp/stripped/drivers/media/video/saa7134/saa7134-core.c /tmp/not_stripped/drivers/media/video/saa7134/saa7134-core.c
--- /tmp/stripped/drivers/media/video/saa7134/saa7134-core.c	2011-01-10 10:01:52.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/saa7134/saa7134-core.c	2011-01-10 10:02:08.000000000 -0200
@@ -1140,6 +1140,9 @@ static void __devexit saa7134_finidev(st
 	release_mem_region(pci_resource_start(pci_dev,0),
 			   pci_resource_len(pci_dev,0));
 
+#if 0  /* causes some trouble when reinserting the driver ... */
+	pci_disable_device(pci_dev);
+#endif
 
 	v4l2_device_unregister(&dev->v4l2_dev);
 
diff -upr /tmp/stripped/drivers/media/video/tvp5150.c /tmp/not_stripped/drivers/media/video/tvp5150.c
--- /tmp/stripped/drivers/media/video/tvp5150.c	2011-01-10 10:01:51.000000000 -0200
+++ /tmp/not_stripped/drivers/media/video/tvp5150.c	2011-01-10 10:02:07.000000000 -0200
@@ -220,6 +220,10 @@ static int tvp5150_log_status(struct v4l
 			tvp5150_read(sd, TVP5150_STATUS_REG_3),
 			tvp5150_read(sd, TVP5150_STATUS_REG_4),
 			tvp5150_read(sd, TVP5150_STATUS_REG_5));
+#if 0 /* This will pop a value from vbi reg */
+	printk("tvp5150: VBI FIFO read data = 0x%02x\n",
+			tvp5150_read(sd, TVP5150_VBI_FIFO_READ_DATA));
+#endif
 
 	dump_reg_range(sd, "Teletext filter 1",   TVP5150_TELETEXT_FIL1_INI,
 			TVP5150_TELETEXT_FIL1_END, 8);
diff -upr /tmp/stripped/include/media/lirc.h /tmp/not_stripped/include/media/lirc.h
--- /tmp/stripped/include/media/lirc.h	2011-01-10 10:01:49.000000000 -0200
+++ /tmp/not_stripped/include/media/lirc.h	2011-01-10 10:02:05.000000000 -0200
@@ -95,6 +95,12 @@
 #define LIRC_GET_MIN_TIMEOUT           _IOR('i', 0x00000008, __u32)
 #define LIRC_GET_MAX_TIMEOUT           _IOR('i', 0x00000009, __u32)
 
+#if 0	/* these ioctls are not used at the moment */
+#define LIRC_GET_MIN_FILTER_PULSE      _IOR('i', 0x0000000a, __u32)
+#define LIRC_GET_MAX_FILTER_PULSE      _IOR('i', 0x0000000b, __u32)
+#define LIRC_GET_MIN_FILTER_SPACE      _IOR('i', 0x0000000c, __u32)
+#define LIRC_GET_MAX_FILTER_SPACE      _IOR('i', 0x0000000d, __u32)
+#endif
 
 /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
 #define LIRC_GET_LENGTH                _IOR('i', 0x0000000f, __u32)
@@ -115,6 +121,23 @@
  */
 #define LIRC_SET_REC_TIMEOUT           _IOW('i', 0x00000018, __u32)
 
+#if 0	/* these ioctls are not used at the moment */
+/*
+ * pulses shorter than this are filtered out by hardware (software
+ * emulation in lirc_dev?)
+ */
+#define LIRC_SET_REC_FILTER_PULSE      _IOW('i', 0x00000019, __u32)
+/*
+ * spaces shorter than this are filtered out by hardware (software
+ * emulation in lirc_dev?)
+ */
+#define LIRC_SET_REC_FILTER_SPACE      _IOW('i', 0x0000001a, __u32)
+/*
+ * if filter cannot be set independantly for pulse/space, this should
+ * be used
+ */
+#define LIRC_SET_REC_FILTER            _IOW('i', 0x0000001b, __u32)
+#endif
 
 /*
  * to set a range use
@@ -128,5 +151,13 @@
 
 #define LIRC_NOTIFY_DECODE             _IO('i', 0x00000020)
 
+#if 0	/* these ioctls are not used at the moment */
+/*
+ * from the next key press on the driver will send
+ * LIRC_MODE2_FREQUENCY packets
+ */
+#define LIRC_MEASURE_CARRIER_ENABLE    _IO('i', 0x00000021)
+#define LIRC_MEASURE_CARRIER_DISABLE   _IO('i', 0x00000022)
+#endif
 
 #endif
diff -upr /tmp/stripped/include/media/saa6752hs.h /tmp/not_stripped/include/media/saa6752hs.h
--- /tmp/stripped/include/media/saa6752hs.h	2011-01-10 10:01:49.000000000 -0200
+++ /tmp/not_stripped/include/media/saa6752hs.h	2011-01-10 10:02:05.000000000 -0200
@@ -18,6 +18,53 @@
     Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */
 
+#if 0 /* ndef _SAA6752HS_H */
+#define _SAA6752HS_H
+
+enum mpeg_video_bitrate_mode {
+	MPEG_VIDEO_BITRATE_MODE_VBR = 0, /* Variable bitrate */
+	MPEG_VIDEO_BITRATE_MODE_CBR = 1, /* Constant bitrate */
+
+	MPEG_VIDEO_BITRATE_MODE_MAX
+};
+
+enum mpeg_audio_bitrate {
+	MPEG_AUDIO_BITRATE_256 = 0, /* 256 kBit/sec */
+	MPEG_AUDIO_BITRATE_384 = 1, /* 384 kBit/sec */
+
+	MPEG_AUDIO_BITRATE_MAX
+};
+
+enum mpeg_video_format {
+	MPEG_VIDEO_FORMAT_D1 = 0,
+	MPEG_VIDEO_FORMAT_2_3_D1 = 1,
+	MPEG_VIDEO_FORMAT_1_2_D1 = 2,
+	MPEG_VIDEO_FORMAT_SIF = 3,
+
+	MPEG_VIDEO_FORMAT_MAX
+};
+
+#define MPEG_VIDEO_TARGET_BITRATE_MAX 27000
+#define MPEG_VIDEO_MAX_BITRATE_MAX 27000
+#define MPEG_TOTAL_BITRATE_MAX 27000
+#define MPEG_PID_MAX ((1 << 14) - 1)
+
+struct mpeg_params {
+	enum mpeg_video_bitrate_mode video_bitrate_mode;
+	unsigned int video_target_bitrate;
+	unsigned int video_max_bitrate; // only used for VBR
+	enum mpeg_audio_bitrate audio_bitrate;
+	unsigned int total_bitrate;
+
+	unsigned int pmt_pid;
+	unsigned int video_pid;
+	unsigned int audio_pid;
+	unsigned int pcr_pid;
+
+	enum mpeg_video_format video_format;
+};
+
+#endif // _SAA6752HS_H
 
 /*
  * Local variables:

Re: Debug code in HG repositories

[Mauro Carvalho Chehab]

Em 10-01-2011 10:04, Mauro Carvalho Chehab escreveu:
> Em 07-01-2011 21:56, Oliver Endriss escreveu:
>> On Friday 07 January 2011 22:06:30 Hans Verkuil wrote:
>>> On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
>>>> On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
>>>>> Hi guys,
>>>>>
>>>>> are you aware that there is a lot of '#if 0' code in the HG repositories
>>>>> which is not in GIT?

> As a reference and further discussions, I'm enclosing the diff.

It is now easier to comment on what we have inside the #if 0 code. Let me add
my comments about that.

A general comment after my review is that most of the commented code should
be just discarded, but I agree with Oliver that there are some things there
that we want to preserve.

> 
> ---
> 
> diff -upr /tmp/stripped/drivers/media/common/tuners/tea5767.c /tmp/not_stripped/drivers/media/common/tuners/tea5767.c
> --- /tmp/stripped/drivers/media/common/tuners/tea5767.c	2011-01-10 10:01:50.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/common/tuners/tea5767.c	2011-01-10 10:02:06.000000000 -0200
> @@ -371,6 +371,9 @@ int tea5767_autodetection(struct i2c_ada
>  	struct tuner_i2c_props i2c = { .adap = i2c_adap, .addr = i2c_addr };
>  	unsigned char buffer[7] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
>  	int rc;
> +#if 0 /* Needed if uncomment I2C send code below */
> +	int div;
> +#endif
>  
>  	if ((rc = tuner_i2c_xfer_recv(&i2c, buffer, 7))< 5) {
>  		printk(KERN_WARNING "It is not a TEA5767. Received %i bytes.\n", rc);
> @@ -394,7 +397,42 @@ int tea5767_autodetection(struct i2c_ada
>  		return -EINVAL;
>  	}
>  
> +#if 0	/* Not working for TEA5767 in Beholder Columbus card */
> +	/* It seems that tea5767 returns 0xff after the 5th byte */
> +	if ((buffer[5] != 0xff) || (buffer[6] != 0xff)) {
> +		printk(KERN_WARNING "Returned more than 5 bytes. It is not a TEA5767\n");
> +		return -EINVAL;
> +	}
> +#endif
> +
> +#if 0 /*Sometimes, this code doesn't work */
> +	/* Sets tuner at some freq (87.5 MHz) and see if it is ok */
> +	div = ((87500 * 4000 + 700000 + 225000) + 16768) >> 15;
> +	buffer[0] = ((div >> 8) & 0x3f) | TEA5767_MUTE;
> +	buffer[1] = div & 0xff;
> +	buffer[2] = TEA5767_PORT1_HIGH;
> +	buffer[3] = TEA5767_PORT2_HIGH | TEA5767_HIGH_CUT_CTRL |
> +		    TEA5767_ST_NOISE_CTL;
> +	buffer[4] = 0;
> +
> +	if (5 != (rc = tuner_i2c_xfer_send(&i2c, buffer, 5)))
> +		printk(KERN_WARNING "i2c i/o error: rc == %d (should be 5)\n", rc);
> +
> +	msleep(15);
> +
> +	if (5 != (rc = tuner_i2c_xfer_recv(&i2c, buffer, 5))) {
> +		printk(KERN_WARNING "It is not a TEA5767. Received %i bytes.\n", rc);
> +		return -EINVAL;
> +	}
>  
> +	/* Initial freq for 32.768KHz clock */
> +	if ((buffer[1] != (div & 0xff) ) || ((buffer[0] & 0x3f) != ((div >> 8) & 0x3f))) {
> +		printk(KERN_WARNING "It is not a TEA5767. div=%d, Return: %02x %02x %02x %02x %02x\n",
> +				div,buffer[0],buffer[1],buffer[2],buffer[3],buffer[4]);
> +		tea5767_status_dump(buffer);
> +		return -EINVAL;
> +	}
> +#endif
>  	return 0;
>  }
>  
> @@ -443,6 +481,10 @@ struct dvb_frontend *tea5767_attach(stru
>  {
>  	struct tea5767_priv *priv = NULL;
>  
> +#if 0 /* By removing autodetection allows forcing TEA chip */
> +	if (tea5767_autodetection(i2c_adap, i2c_addr) == -EINVAL)
> +		return -EINVAL;
> +#endif
>  	priv = kzalloc(sizeof(struct tea5767_priv), GFP_KERNEL);
>  	if (priv == NULL)
>  		return NULL;

All the #if 0 code there are obsolete. The detection tests
were moved to other place.

> diff -upr /tmp/stripped/drivers/media/common/tuners/tuner-simple.c /tmp/not_stripped/drivers/media/common/tuners/tuner-simple.c
> --- /tmp/stripped/drivers/media/common/tuners/tuner-simple.c	2011-01-10 10:01:50.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/common/tuners/tuner-simple.c	2011-01-10 10:02:06.000000000 -0200
> @@ -161,6 +161,12 @@ static inline int tuner_afcstatus(const 
>  	return (status & TUNER_AFC) - 2;
>  }
>  
> +#if 0 /* unused */
> +static inline int tuner_mode(const int status)
> +{
> +	return (status & TUNER_MODE) >> 3;
> +}
> +#endif
>  
>  static int simple_get_status(struct dvb_frontend *fe, u32 *status)
>  {

No idea about that. Too old for me to remember, but I don't think
we should backport it.

> diff -upr /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c
> --- /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c	2011-01-10 10:01:49.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c	2011-01-10 10:02:05.000000000 -0200
> @@ -272,6 +272,32 @@ static const struct pci_device_id ngene_
>  	NGENE_ID(0x18c3, 0xdd10, ngene_info_duoFlexS2),
>  	NGENE_ID(0x18c3, 0xdd20, ngene_info_duoFlexS2),
>  	NGENE_ID(0x1461, 0x062e, ngene_info_m780),
> +#if 0 /* not (yet?) supported */
> +	NGENE_ID(0x18c3, 0x0000, ngene_info_appboard),
> +	NGENE_ID(0x18c3, 0x0004, ngene_info_appboard),
> +	NGENE_ID(0x18c3, 0x8011, ngene_info_appboard),
> +	NGENE_ID(0x18c3, 0x8015, ngene_info_appboard_ntsc),
> +	NGENE_ID(0x153b, 0x1167, ngene_info_terratec),
> +	NGENE_ID(0x18c3, 0x0030, ngene_info_python),
> +	NGENE_ID(0x18c3, 0x0052, ngene_info_sidewinder),
> +	NGENE_ID(0x18c3, 0x8f00, ngene_info_racer),
> +	NGENE_ID(0x18c3, 0x0041, ngene_info_viper_v1),
> +	NGENE_ID(0x18c3, 0x0042, ngene_info_viper_v2),
> +	NGENE_ID(0x14f3, 0x0041, ngene_info_vbox_v1),
> +	NGENE_ID(0x14f3, 0x0043, ngene_info_vbox_v2),
> +	NGENE_ID(0x18c3, 0xabcd, ngene_info_s2),
> +	NGENE_ID(0x18c3, 0xabc2, ngene_info_s2_b),
> +	NGENE_ID(0x18c3, 0xabc3, ngene_info_s2_b),
> +	NGENE_ID(0x18c3, 0x0001, ngene_info_appboard),
> +	NGENE_ID(0x18c3, 0x0005, ngene_info_appboard),
> +	NGENE_ID(0x18c3, 0x0009, ngene_info_appboard_atsc),
> +	NGENE_ID(0x18c3, 0x000b, ngene_info_appboard_atsc),
> +	NGENE_ID(0x18c3, 0x0010, ngene_info_shrek_50_fp),
> +	NGENE_ID(0x18c3, 0x0011, ngene_info_shrek_60_fp),
> +	NGENE_ID(0x18c3, 0x0012, ngene_info_shrek_50),
> +	NGENE_ID(0x18c3, 0x0013, ngene_info_shrek_60),
> +	NGENE_ID(0x18c3, 0x0000, ngene_info_hognose),
> +#endif
>  	{0}
>  };
>  MODULE_DEVICE_TABLE(pci, ngene_id_tbl);

It is probably a good idea to backport this one. I would change it to #if 1, to allow
people to test (or I would create a CONFIG_NGENE_EXPERIMENTAL to enable such support).

> diff -upr /tmp/stripped/drivers/media/video/bt8xx/bttv-cards.c /tmp/not_stripped/drivers/media/video/bt8xx/bttv-cards.c
> --- /tmp/stripped/drivers/media/video/bt8xx/bttv-cards.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/bt8xx/bttv-cards.c	2011-01-10 10:02:08.000000000 -0200
> @@ -1801,12 +1801,21 @@ struct tvcard bttv_tvcards[] = {
>  		.name           = "Osprey 540",   /* 540 */
>  		.video_inputs   = 4,
>  		/* .audio_inputs= 1, */
> +	#if 0 /* TODO ... */
> +		.svhs           = OSPREY540_SVID_ANALOG,
> +		.muxsel         = {       [OSPREY540_COMP_ANALOG] = 2,
> +					[OSPREY540_SVID_ANALOG] = 3, },
> +	#endif
>  		.pll            = PLL_28,
>  		.tuner_type     = TUNER_ABSENT,
>  		.tuner_addr	= ADDR_UNSET,
>  		.no_msp34xx     = 1,
>  		.no_tda9875     = 1,
>  		.no_tda7432     = 1,
> +	#if 0 /* TODO ... */
> +		.muxsel_hook    = osprey_540_muxsel,
> +		.picture_hook   = osprey_540_set_picture,
> +	#endif
>  	},
>  
>  		/* ---- card 0x5C ---------------------------------- */

We lack documentation about that. I remember I asked once to some contacts at Osprey but
they didn't send me any docs or further info.

> diff -upr /tmp/stripped/drivers/media/video/bt8xx/bttv-driver.c /tmp/not_stripped/drivers/media/video/bt8xx/bttv-driver.c
> --- /tmp/stripped/drivers/media/video/bt8xx/bttv-driver.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/bt8xx/bttv-driver.c	2011-01-10 10:02:08.000000000 -0200
> @@ -937,10 +937,12 @@ disclaim_video_lines(struct bttv *btv)
>  static
>  void free_btres(struct bttv *btv, struct bttv_fh *fh, int bits)
>  {
> +#if 1 /* DEBUG */
>  	if ((fh->resources & bits) != bits) {
>  		/* trying to free ressources not allocated by us ... */
>  		printk("bttv: BUG! (btres)\n");
>  	}
> +#endif
>  	mutex_lock(&btv->lock);
>  	fh->resources  &= ~bits;
>  	btv->resources &= ~bits;

No sense to backport. Yet, a patch is welcome to convert the printk into something better
(maybe BUG_ON?).

> diff -upr /tmp/stripped/drivers/media/video/bt8xx/bttv-risc.c /tmp/not_stripped/drivers/media/video/bt8xx/bttv-risc.c
> --- /tmp/stripped/drivers/media/video/bt8xx/bttv-risc.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/bt8xx/bttv-risc.c	2011-01-10 10:02:08.000000000 -0200
> @@ -349,6 +349,10 @@ bttv_calc_geo_old(struct bttv *btv, stru
>  	}
>  
>  	vdelay = tvnorm->vdelay;
> +#if 0 /* FIXME */
> +	if (vdelay < btv->vbi.lines*2)
> +		vdelay = btv->vbi.lines*2;
> +#endif
>  
>  	xsf = (width*scaledtwidth)/swidth;
>  	geo->hscale =  ((totalwidth*4096UL)/xsf-4096);

VBI works on bttv. Not sure why this code is there.

> diff -upr /tmp/stripped/drivers/media/video/cx88/cx88-core.c /tmp/not_stripped/drivers/media/video/cx88/cx88-core.c
> --- /tmp/stripped/drivers/media/video/cx88/cx88-core.c	2011-01-10 10:01:51.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/cx88/cx88-core.c	2011-01-10 10:02:07.000000000 -0200
> @@ -430,6 +430,25 @@ static int cx88_risc_decode(u32 risc)
>  	return incr[risc >> 28] ? incr[risc >> 28] : 1;
>  }
>  
> +#if 0 /* currently unused, but useful for debugging */
> +void cx88_risc_disasm(struct cx88_core *core,
> +		      struct btcx_riscmem *risc)
> +{
> +	unsigned int i,j,n;
> +
> +	printk("%s: risc disasm: %p [dma=0x%08lx]\n",
> +	       core->name, risc->cpu, (unsigned long)risc->dma);
> +	for (i = 0; i < (risc->size >> 2); i += n) {
> +		printk("%s:   %04d: ", core->name, i);
> +		n = cx88_risc_decode(risc->cpu[i]);
> +		for (j = 1; j < n; j++)
> +			printk("%s:   %04d: 0x%08x [ arg #%d ]\n",
> +			       core->name, i+j, risc->cpu[i+j], j);
> +		if (risc->cpu[i] == RISC_JUMP)
> +			break;
> +	}
> +}
> +#endif
>  
>  void cx88_sram_channel_dump(struct cx88_core *core,
>  			    struct sram_channel *ch)

This might be useful to enable, but the cx88 risc assembler code initialized
by the driver is there for a long time and nobody had to touch on it for a long
time. 

> diff -upr /tmp/stripped/drivers/media/video/cx88/cx88-reg.h /tmp/not_stripped/drivers/media/video/cx88/cx88-reg.h
> --- /tmp/stripped/drivers/media/video/cx88/cx88-reg.h	2011-01-10 10:01:51.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/cx88/cx88-reg.h	2011-01-10 10:02:07.000000000 -0200
> @@ -661,11 +661,18 @@
>  #define EN_I2SIN_STR2DAC        0x00004000
>  #define EN_I2SIN_ENABLE         0x00008000
>  
> +#if 0 /* old */
> +#define EN_DMTRX_SUMDIFF        0x00000800
> +#define EN_DMTRX_SUMR           0x00000880
> +#define EN_DMTRX_LR             0x00000900
> +#define EN_DMTRX_MONO           0x00000980
> +#else /* dscaler cvs */
>  #define EN_DMTRX_SUMDIFF        (0 << 7)
>  #define EN_DMTRX_SUMR           (1 << 7)
>  #define EN_DMTRX_LR             (2 << 7)
>  #define EN_DMTRX_MONO           (3 << 7)
>  #define EN_DMTRX_BYPASS         (1 << 11)
> +#endif
>  
>  // Video
>  #define VID_CAPTURE_CONTROL		0x310180

Seems bogus to me.

> diff -upr /tmp/stripped/drivers/media/video/cx88/cx88-video.c /tmp/not_stripped/drivers/media/video/cx88/cx88-video.c
> --- /tmp/stripped/drivers/media/video/cx88/cx88-video.c	2011-01-10 10:01:51.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/cx88/cx88-video.c	2011-01-10 10:02:07.000000000 -0200
> @@ -719,6 +719,231 @@ static struct videobuf_queue_ops cx8800_
>  
>  /* ------------------------------------------------------------------ */
>  
> +#if 0 /* overlay support not finished yet */
> +static u32* ov_risc_field(struct cx8800_dev *dev, struct cx8800_fh *fh,
> +			  u32 *rp, struct btcx_skiplist *skips,
> +			  u32 sync_line, int skip_even, int skip_odd)
> +{
> +	int line,maxy,start,end,skip,nskips;
> +	u32 ri,ra;
> +	u32 addr;
> +
> +	/* sync instruction */
> +	*(rp++) = cpu_to_le32(RISC_RESYNC | sync_line);
> +
> +	addr  = (unsigned long)dev->fbuf.base;
> +	addr += dev->fbuf.fmt.bytesperline * fh->win.w.top;
> +	addr += (fh->fmt->depth >> 3)      * fh->win.w.left;
> +
> +	/* scan lines */
> +	for (maxy = -1, line = 0; line < fh->win.w.height;
> +	     line++, addr += dev->fbuf.fmt.bytesperline) {
> +		if ((line%2) == 0  &&  skip_even)
> +			continue;
> +		if ((line%2) == 1  &&  skip_odd)
> +			continue;
> +
> +		/* calculate clipping */
> +		if (line > maxy)
> +			btcx_calc_skips(line, fh->win.w.width, &maxy,
> +					skips, &nskips, fh->clips, fh->nclips);
> +
> +		/* write out risc code */
> +		for (start = 0, skip = 0; start < fh->win.w.width; start = end) {
> +			if (skip >= nskips) {
> +				ri  = RISC_WRITE;
> +				end = fh->win.w.width;
> +			} else if (start < skips[skip].start) {
> +				ri  = RISC_WRITE;
> +				end = skips[skip].start;
> +			} else {
> +				ri  = RISC_SKIP;
> +				end = skips[skip].end;
> +				skip++;
> +			}
> +			if (RISC_WRITE == ri)
> +				ra = addr + (fh->fmt->depth>>3)*start;
> +			else
> +				ra = 0;
> +
> +			if (0 == start)
> +				ri |= RISC_SOL;
> +			if (fh->win.w.width == end)
> +				ri |= RISC_EOL;
> +			ri |= (fh->fmt->depth>>3) * (end-start);
> +
> +			*(rp++)=cpu_to_le32(ri);
> +			if (0 != ra)
> +				*(rp++)=cpu_to_le32(ra);
> +		}
> +	}
> +	kfree(skips);
> +	return rp;
> +}
> +
> +static int ov_risc_frame(struct cx8800_dev *dev, struct cx8800_fh *fh,
> +			 struct cx88_buffer *buf)
> +{
> +	struct btcx_skiplist *skips;
> +	u32 instructions,fields;
> +	u32 *rp;
> +	int rc;
> +
> +	/* skip list for window clipping */
> +	if (NULL == (skips = kmalloc(sizeof(*skips) * fh->nclips,GFP_KERNEL)))
> +		return -ENOMEM;
> +
> +	fields = 0;
> +	if (V4L2_FIELD_HAS_TOP(fh->win.field))
> +		fields++;
> +	if (V4L2_FIELD_HAS_BOTTOM(fh->win.field))
> +		fields++;
> +
> +	/* estimate risc mem: worst case is (clip+1) * lines instructions
> +	   + syncs + jump (all 2 dwords) */
> +	instructions  = (fh->nclips+1) * fh->win.w.height;
> +	instructions += 3 + 4;
> +	if ((rc = btcx_riscmem_alloc(dev->pci,&buf->risc,instructions*8)) < 0) {
> +		kfree(skips);
> +		return rc;
> +	}
> +
> +	/* write risc instructions */
> +	rp = buf->risc.cpu;
> +	switch (fh->win.field) {
> +	case V4L2_FIELD_TOP:
> +		rp = ov_risc_field(dev, fh, rp, skips, 0,     0, 0);
> +		break;
> +	case V4L2_FIELD_BOTTOM:
> +		rp = ov_risc_field(dev, fh, rp, skips, 0x200, 0, 0);
> +		break;
> +	case V4L2_FIELD_INTERLACED:
> +		rp = ov_risc_field(dev, fh, rp, skips, 0,     0, 1);
> +		rp = ov_risc_field(dev, fh, rp, skips, 0x200, 1, 0);
> +		break;
> +	default:
> +		BUG();
> +	}
> +
> +	/* save pointer to jmp instruction address */
> +	buf->risc.jmp = rp;
> +	kfree(skips);
> +	return 0;
> +}
> +
> +static int verify_window(struct cx8800_dev *dev, struct v4l2_window *win)
> +{
> +	enum v4l2_field field;
> +	int maxw, maxh;
> +
> +	if (NULL == dev->fbuf.base)
> +		return -EINVAL;
> +	if (win->w.width < 48 || win->w.height <  32)
> +		return -EINVAL;
> +	if (win->clipcount > 2048)
> +		return -EINVAL;
> +
> +	field = win->field;
> +	maxw  = norm_maxw(core->tvnorm);
> +	maxh  = norm_maxh(core->tvnorm);
> +
> +	if (V4L2_FIELD_ANY == field) {
> +		field = (win->w.height > maxh/2)
> +			? V4L2_FIELD_INTERLACED
> +			: V4L2_FIELD_TOP;
> +	}
> +	switch (field) {
> +	case V4L2_FIELD_TOP:
> +	case V4L2_FIELD_BOTTOM:
> +		maxh = maxh / 2;
> +		break;
> +	case V4L2_FIELD_INTERLACED:
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	win->field = field;
> +	if (win->w.width > maxw)
> +		win->w.width = maxw;
> +	if (win->w.height > maxh)
> +		win->w.height = maxh;
> +	return 0;
> +}
> +
> +static int setup_window(struct cx8800_dev *dev, struct cx8800_fh *fh,
> +			struct v4l2_window *win)
> +{
> +	struct v4l2_clip *clips = NULL;
> +	int n,size,retval = 0;
> +
> +	if (NULL == fh->fmt)
> +		return -EINVAL;
> +	retval = verify_window(dev,win);
> +	if (0 != retval)
> +		return retval;
> +
> +	/* copy clips  --  luckily v4l1 + v4l2 are binary
> +	   compatible here ...*/
> +	n = win->clipcount;
> +	size = sizeof(*clips)*(n+4);
> +	clips = kmalloc(size,GFP_KERNEL);
> +	if (NULL == clips)
> +		return -ENOMEM;
> +	if (n > 0) {
> +		if (copy_from_user(clips,win->clips,sizeof(struct v4l2_clip)*n)) {
> +			kfree(clips);
> +			return -EFAULT;
> +		}
> +	}
> +
> +	/* clip against screen */
> +	if (NULL != dev->fbuf.base)
> +		n = btcx_screen_clips(dev->fbuf.fmt.width, dev->fbuf.fmt.height,
> +				      &win->w, clips, n);
> +	btcx_sort_clips(clips,n);
> +
> +	/* 4-byte alignments */
> +	switch (fh->fmt->depth) {
> +	case 8:
> +	case 24:
> +		btcx_align(&win->w, clips, n, 3);
> +		break;
> +	case 16:
> +		btcx_align(&win->w, clips, n, 1);
> +		break;
> +	case 32:
> +		/* no alignment fixups needed */
> +		break;
> +	default:
> +		BUG();
> +	}
> +
> +	down(&fh->vidq.lock);
> +	if (fh->clips)
> +		kfree(fh->clips);
> +	fh->clips    = clips;
> +	fh->nclips   = n;
> +	fh->win      = *win;
> +/* #if 0 */
> +	fh->ov.setup_ok = 1;
> +/* #endif */
> +
> +	/* update overlay if needed */
> +	retval = 0;
> +/* #if 0 */
> +	if (check_btres(fh, RESOURCE_OVERLAY)) {
> +		struct bttv_buffer *new;
> +
> +		new = videobuf_pci_alloc(sizeof(*new));
> +		bttv_overlay_risc(btv, &fh->ov, fh->ovfmt, new);
> +		retval = bttv_switch_overlay(btv,fh,new);
> +	}
> +/* #endif */
> +	up(&fh->vidq.lock);
> +	return retval;
> +}
> +#endif
>  
>  /* ------------------------------------------------------------------ */
>  

This is just a copy of bttv or saa7134 overlay code, that would need to be fixed, if 
someone was interested on adding overlay code to cx88. Overlay mode is dead, due to
Xorg changes. There's no sense on preserving it anymore, except if someone decides
to fix the current apps to work with newer X11 drivers.

> diff -upr /tmp/stripped/drivers/media/video/em28xx/em28xx-cards.c /tmp/not_stripped/drivers/media/video/em28xx/em28xx-cards.c
> --- /tmp/stripped/drivers/media/video/em28xx/em28xx-cards.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/em28xx/em28xx-cards.c	2011-01-10 10:02:08.000000000 -0200
> @@ -106,9 +106,21 @@ static struct em28xx_reg_seq em2880_msi_
>  };
>  
>  /* Boards - EM2880 MSI DIGIVOX AD and EM2880_BOARD_MSI_DIGIVOX_AD_II */
> +#if 0	/* Still missing the dvb setup */
> +static struct em28xx_reg_seq em2880_msi_digivox_ad_digital[] = {
> +	{EM28XX_R08_GPIO,	0x6a,	~EM_GPIO_4,	10},
> +	{	-1,		-1,	-1,		-1},
> +};
> +#endif
>  
>  /* Board  - EM2870 Kworld 355u
>     Analog - No input analog */
> +#if 0	/* Still missing the dvb setup */
> +static struct em28xx_reg_seq em2870_kworld_355u_digital[] = {
> +	{EM2880_R04_GPO,	0x01,	0xff,		10},
> +	{  -1,			-1,	-1,		-1},
> +};
> +#endif
>  
>  /* Board - EM2882 Kworld 315U digital */
>  static struct em28xx_reg_seq em2882_kworld_315u_digital[] = {
> @@ -656,6 +668,10 @@ struct em28xx_board em28xx_boards[] = {
>  		.tuner_gpio   = default_tuner_gpio,
>  		.decoder      = EM28XX_TVP5150,
>  
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = hauppauge_wintv_hvr_900_digital,
> +#endif
>  		.input        = { {
>  			.type     = EM28XX_VMUX_TELEVISION,
>  			.vmux     = TVP5150_COMPOSITE0,
> @@ -758,6 +774,10 @@ struct em28xx_board em28xx_boards[] = {
>  		.valid        = EM28XX_BOARD_NOT_VALIDATED,
>  		.tuner_type   = TUNER_XC2028,
>  		.tuner_gpio   = default_tuner_gpio,
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = default_digital,
> +#endif
>  	},
>  	[EM2870_BOARD_TERRATEC_XS_MT2060] = {
>  		.name         = "Terratec Cinergy T XS (MT2060)",
> @@ -769,10 +789,18 @@ struct em28xx_board em28xx_boards[] = {
>  		.valid        = EM28XX_BOARD_NOT_VALIDATED,
>  		.tuner_type   = TUNER_XC2028,
>  		.tuner_gpio   = default_tuner_gpio,
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = default_digital,
> +#endif
>  	},
>  	[EM2870_BOARD_KWORLD_355U] = {
>  		.name         = "Kworld 355 U DVB-T",
>  		.valid        = EM28XX_BOARD_NOT_VALIDATED,
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = em2870_kworld_355u_digital,
> +#endif
>  	},
>  	[EM2870_BOARD_PINNACLE_PCTV_DVB] = {
>  		.name         = "Pinnacle PCTV DVB-T",
> @@ -848,6 +876,10 @@ struct em28xx_board em28xx_boards[] = {
>  		.mts_firmware = 1,
>  		.ir_codes     = RC_MAP_HAUPPAUGE_NEW,
>  		.decoder      = EM28XX_TVP5150,
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = hauppauge_wintv_hvr_900_digital,
> +#endif
>  		.input        = { {
>  			.type     = EM28XX_VMUX_TELEVISION,
>  			.vmux     = TVP5150_COMPOSITE0,
> @@ -1003,6 +1035,10 @@ struct em28xx_board em28xx_boards[] = {
>  		.tuner_type   = TUNER_XC2028,
>  		.tuner_gpio   = default_tuner_gpio,
>  		.decoder      = EM28XX_TVP5150,
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = hauppauge_wintv_hvr_900_digital,
> +#endif
>  		.input        = { {
>  			.type     = EM28XX_VMUX_TELEVISION,
>  			.vmux     = TVP5150_COMPOSITE0,
> @@ -1245,6 +1281,10 @@ struct em28xx_board em28xx_boards[] = {
>  		.tuner_type   = TUNER_XC2028,
>  		.tuner_gpio   = default_tuner_gpio,
>  		.decoder      = EM28XX_TVP5150,
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = em2880_msi_digivox_ad_digital,
> +#endif
>  		.input        = { {
>  			.type     = EM28XX_VMUX_TELEVISION,
>  			.vmux     = TVP5150_COMPOSITE0,
> @@ -1268,6 +1308,10 @@ struct em28xx_board em28xx_boards[] = {
>  		.tuner_type   = TUNER_XC2028,
>  		.tuner_gpio   = default_tuner_gpio,
>  		.decoder      = EM28XX_TVP5150,
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = em2880_msi_digivox_ad_digital,
> +#endif
>  		.input        = { {
>  			.type     = EM28XX_VMUX_TELEVISION,
>  			.vmux     = TVP5150_COMPOSITE0,
> @@ -1394,6 +1438,10 @@ struct em28xx_board em28xx_boards[] = {
>  		.tuner_type   = TUNER_XC2028,
>  		.tuner_gpio   = default_tuner_gpio,
>  		.decoder      = EM28XX_TVP5150,
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = default_digital,
> +#endif
>  		.input        = { {
>  			.type     = EM28XX_VMUX_TELEVISION,
>  			.vmux     = TVP5150_COMPOSITE0,
> @@ -1442,6 +1490,10 @@ struct em28xx_board em28xx_boards[] = {
>  		.tuner_gpio   = default_tuner_gpio,
>  		.mts_firmware = 1,
>  		.decoder      = EM28XX_TVP5150,
> +#if 0 /* FIXME: add an entry at em28xx-dvb */
> +		.has_dvb      = 1,
> +		.dvb_gpio     = hauppauge_wintv_hvr_900_digital,
> +#endif
>  		.input        = { {
>  			.type     = EM28XX_VMUX_TELEVISION,
>  			.vmux     = TVP5150_COMPOSITE0,

The above changes probably deserves a backport.

> diff -upr /tmp/stripped/drivers/media/video/gspca/pac7302.c /tmp/not_stripped/drivers/media/video/gspca/pac7302.c
> --- /tmp/stripped/drivers/media/video/gspca/pac7302.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/gspca/pac7302.c	2011-01-10 10:02:08.000000000 -0200
> @@ -415,6 +415,27 @@ static void reg_w_buf(struct gspca_dev *
>  	}
>  }
>  
> +#if 0 /* not used */
> +static __u8 reg_r(struct gspca_dev *gspca_dev,
> +			     __u8 index)
> +{
> +	int ret;
> +
> +	ret = usb_control_msg(gspca_dev->dev,
> +			usb_rcvctrlpipe(gspca_dev->dev, 0),
> +			0,			/* request */
> +			USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
> +			0,			/* value */
> +			index, gspca_dev->usb_buf, 1,
> +			500);
> +	if (ret < 0)
> +		PDEBUG(D_ERR, "reg_r(): "
> +		"Failed to read register from index 0x%x, error %i",
> +		index, ret);
> +
> +	return gspca_dev->usb_buf[0];
> +}
> +#endif
>  
>  static void reg_w(struct gspca_dev *gspca_dev,
>  		  __u8 index,

It may make some sense to backport this one.

> diff -upr /tmp/stripped/drivers/media/video/gspca/pac7311.c /tmp/not_stripped/drivers/media/video/gspca/pac7311.c
> --- /tmp/stripped/drivers/media/video/gspca/pac7311.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/gspca/pac7311.c	2011-01-10 10:02:09.000000000 -0200
> @@ -283,6 +283,27 @@ static void reg_w_buf(struct gspca_dev *
>  	}
>  }
>  
> +#if 0 /* not used */
> +static __u8 reg_r(struct gspca_dev *gspca_dev,
> +			     __u8 index)
> +{
> +	int ret;
> +
> +	ret = usb_control_msg(gspca_dev->dev,
> +			usb_rcvctrlpipe(gspca_dev->dev, 0),
> +			0,			/* request */
> +			USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
> +			0,			/* value */
> +			index, gspca_dev->usb_buf, 1,
> +			500);
> +	if (ret < 0)
> +		PDEBUG(D_ERR, "reg_r(): "
> +		"Failed to read register from index 0x%x, error %i",
> +		index, ret);
> +
> +	return gspca_dev->usb_buf[0];
> +}
> +#endif
>  
>  static void reg_w(struct gspca_dev *gspca_dev,
>  		  __u8 index,

It may make some sense to backport this one.

> diff -upr /tmp/stripped/drivers/media/video/gspca/stv0680.c /tmp/not_stripped/drivers/media/video/gspca/stv0680.c
> --- /tmp/stripped/drivers/media/video/gspca/stv0680.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/gspca/stv0680.c	2011-01-10 10:02:09.000000000 -0200
> @@ -195,6 +195,19 @@ static int sd_config(struct gspca_dev *g
>  	PDEBUG(D_PROBE, "Sensor ID is %i",
>  	       (gspca_dev->usb_buf[4]*16) + (gspca_dev->usb_buf[5]>>4));
>  
> +#if 0 /* The v4l1 driver used to this but I don't think it is necessary */
> +	ret = usb_set_interface(gspca_dev->dev, gspca_dev->iface, 1);
> +	if (ret < 0) {
> +		PDEBUG(D_ERR, "Set alt 1 failed (%d)", ret);
> +		return ret;
> +	}
> +
> +	if (stv_sndctrl(gspca_dev, 0, 0x85, 0, 0x10) != 0x10)
> +		return stv0680_handle_error(gspca_dev, -EIO);
> +	if (stv_sndctrl(gspca_dev, 0, 0x8d, 0, 0x08) != 0x08)
> +		return stv0680_handle_error(gspca_dev, -EIO);
> +	PDEBUG(D_PROBE, "Camera has %i pictures.", gspca_dev->usb_buf[3]);
> +#endif
>  
>  	ret = stv0680_get_video_mode(gspca_dev);
>  	if (ret < 0)
> @@ -230,6 +243,13 @@ static int sd_config(struct gspca_dev *g
>  	cam->cam_mode = &sd->mode;
>  	cam->nmodes = 1;
>  
> +#if 0 /* The v4l1 driver used to this but I don't think it is necessary */
> +	ret = usb_set_interface(gspca_dev->dev, gspca_dev->iface, 0);
> +	if (ret < 0) {
> +		PDEBUG(D_ERR, "Set alt 0 failed (%d)", ret);
> +		return ret;
> +	}
> +#endif
>  
>  	ret = stv0680_set_video_mode(gspca_dev, sd->orig_mode);
>  	if (ret < 0)

It may be interesting to backport, as it may help to fix some troubles with different
hardware revisions.

> diff -upr /tmp/stripped/drivers/media/video/gspca/vc032x.c /tmp/not_stripped/drivers/media/video/gspca/vc032x.c
> --- /tmp/stripped/drivers/media/video/gspca/vc032x.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/gspca/vc032x.c	2011-01-10 10:02:09.000000000 -0200
> @@ -253,16 +253,37 @@ static const struct v4l2_pix_format vc03
>  		.priv = 2},
>  };
>  static const struct v4l2_pix_format bi_mode[] = {
> +#if 0 /* JPEG vc0323 */
> +	{320, 240, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
> +		.bytesperline = 320,
> +		.sizeimage = 320 * 240 * 3 / 8 + 590,
> +		.colorspace = V4L2_COLORSPACE_JPEG,
> +		.priv = 5},
> +#endif
>  	{320, 240, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
>  		.bytesperline = 320,
>  		.sizeimage = 320 * 240 * 2,
>  		.colorspace = V4L2_COLORSPACE_SRGB,
>  		.priv = 2},
> +#if 0 /* JPEG vc0323 */
> +	{640, 480, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
> +		.bytesperline = 640,
> +		.sizeimage = 640 * 480 * 3 / 8 + 590,
> +		.colorspace = V4L2_COLORSPACE_JPEG,
> +		.priv = 4},
> +#endif
>  	{640, 480, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
>  		.bytesperline = 640,
>  		.sizeimage = 640 * 480 * 2,
>  		.colorspace = V4L2_COLORSPACE_SRGB,
>  		.priv = 1},
> +#if 0 /* JPEG vc0323 */
> +	{1280, 1024, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
> +		.bytesperline = 1280,
> +		.sizeimage = 1280 * 1024 * 1 / 4 + 590,
> +		.colorspace = V4L2_COLORSPACE_JPEG,
> +		.priv = 3},
> +#endif
>  	{1280, 1024, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
>  		.bytesperline = 1280,
>  		.sizeimage = 1280 * 1024 * 2,
> @@ -1195,6 +1216,123 @@ static const u8 mi1320_soc_InitVGA[][4] 
>  	{0xb3, 0x5c, 0x01, 0xcc},
>  	{}
>  };
> +#if 0 /* JPEG vc0323 */
> +static const u8 mi1320_soc_InitVGA_JPG[][4] = {
> +	{0xb3, 0x01, 0x01, 0xcc},
> +	{0xb0, 0x03, 0x19, 0xcc},
> +	{0xb0, 0x04, 0x02, 0xcc},
> +	{0x00, 0x00, 0x30, 0xdd},
> +	{0xb3, 0x00, 0x64, 0xcc},
> +	{0xb3, 0x00, 0x67, 0xcc},
> +	{0xb3, 0x05, 0x01, 0xcc},
> +	{0xb3, 0x06, 0x01, 0xcc},
> +	{0xb3, 0x08, 0x01, 0xcc},
> +	{0xb3, 0x09, 0x0c, 0xcc},
> +	{0xb3, 0x34, 0x02, 0xcc},
> +	{0xb3, 0x35, 0xc8, 0xcc},
> +	{0xb3, 0x02, 0x00, 0xcc},
> +	{0xb3, 0x03, 0x0a, 0xcc},
> +	{0xb3, 0x04, 0x05, 0xcc},
> +	{0xb3, 0x20, 0x00, 0xcc},
> +	{0xb3, 0x21, 0x00, 0xcc},
> +	{0xb3, 0x22, 0x01, 0xcc},
> +	{0xb3, 0x23, 0xe0, 0xcc},
> +	{0xb3, 0x14, 0x00, 0xcc},
> +	{0xb3, 0x15, 0x00, 0xcc},
> +	{0xb3, 0x16, 0x02, 0xcc},
> +	{0xb3, 0x17, 0x7f, 0xcc},
> +	{0xb3, 0x00, 0x67, 0xcc},
> +	{0xb8, 0x00, 0x00, 0xcc},
> +	{0xbc, 0x00, 0x71, 0xcc},
> +	{0xbc, 0x01, 0x01, 0xcc},
> +	{0xb3, 0x5c, 0x01, 0xcc},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x00, 0x00, 0x10, 0xdd},
> +	{0xc8, 0x00, 0x00, 0xbb},
> +	{0x00, 0x00, 0x30, 0xdd},
> +	{0xf0, 0x00, 0x00, 0xbb},
> +	{0x00, 0x00, 0x10, 0xdd},
> +	{0x07, 0x00, 0xe0, 0xbb},
> +	{0x08, 0x00, 0x0b, 0xbb},
> +	{0x21, 0x00, 0x0c, 0xbb},
> +	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
> +	{0xb6, 0x00, 0x00, 0xcc},
> +	{0xb6, 0x03, 0x02, 0xcc},
> +	{0xb6, 0x02, 0x80, 0xcc},
> +	{0xb6, 0x05, 0x01, 0xcc},
> +	{0xb6, 0x04, 0xe0, 0xcc},
> +	{0xb6, 0x12, 0xf8, 0xcc},
> +	{0xb6, 0x13, 0x05, 0xcc},
> +	{0xb6, 0x18, 0x02, 0xcc},
> +	{0xb6, 0x17, 0x58, 0xcc},
> +	{0xb6, 0x16, 0x00, 0xcc},
> +	{0xb6, 0x22, 0x12, 0xcc},
> +	{0xb6, 0x23, 0x0b, 0xcc},
> +	{0xbf, 0xc0, 0x39, 0xcc},
> +	{0xbf, 0xc1, 0x04, 0xcc},
> +	{0xbf, 0xcc, 0x00, 0xcc},
> +	{0xb3, 0x01, 0x41, 0xcc},
> +	{0xf0, 0x00, 0x00, 0xbb},
> +	{0x05, 0x01, 0x78, 0xbb},
> +	{0x06, 0x00, 0x11, 0xbb},
> +	{0x07, 0x01, 0x42, 0xbb},
> +	{0x08, 0x00, 0x11, 0xbb},
> +	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
> +	{0x21, 0x80, 0x00, 0xbb},
> +	{0x22, 0x0d, 0x0f, 0xbb},
> +	{0x24, 0x80, 0x00, 0xbb},
> +	{0x59, 0x00, 0xff, 0xbb},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x39, 0x03, 0xca, 0xbb},
> +	{0x3a, 0x06, 0x80, 0xbb},
> +	{0x3b, 0x01, 0x52, 0xbb},
> +	{0x3c, 0x05, 0x40, 0xbb},
> +	{0x57, 0x01, 0x9c, 0xbb},
> +	{0x58, 0x01, 0xee, 0xbb},
> +	{0x59, 0x00, 0xf0, 0xbb},
> +	{0x5a, 0x01, 0x20, 0xbb},
> +	{0x5c, 0x1d, 0x17, 0xbb},
> +	{0x5d, 0x22, 0x1c, 0xbb},
> +	{0x64, 0x1e, 0x1c, 0xbb},
> +	{0x5b, 0x00, 0x00, 0xbb},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x22, 0xa0, 0x78, 0xbb},
> +	{0x23, 0xa0, 0x78, 0xbb},
> +	{0x24, 0x7f, 0x00, 0xbb},
> +	{0x28, 0xea, 0x02, 0xbb},
> +	{0x29, 0x86, 0x7a, 0xbb},
> +	{0x5e, 0x52, 0x4c, 0xbb},
> +	{0x5f, 0x20, 0x24, 0xbb},
> +	{0x60, 0x00, 0x02, 0xbb},
> +	{0x02, 0x00, 0xee, 0xbb},
> +	{0x03, 0x39, 0x23, 0xbb},
> +	{0x04, 0x07, 0x24, 0xbb},
> +	{0x09, 0x00, 0xc0, 0xbb},
> +	{0x0a, 0x00, 0x79, 0xbb},
> +	{0x0b, 0x00, 0x04, 0xbb},
> +	{0x0c, 0x00, 0x5c, 0xbb},
> +	{0x0d, 0x00, 0xd9, 0xbb},
> +	{0x0e, 0x00, 0x53, 0xbb},
> +	{0x0f, 0x00, 0x21, 0xbb},
> +	{0x10, 0x00, 0xa4, 0xbb},
> +	{0x11, 0x00, 0xe5, 0xbb},
> +	{0x15, 0x00, 0x00, 0xbb},
> +	{0x16, 0x00, 0x00, 0xbb},
> +	{0x17, 0x00, 0x00, 0xbb},
> +	{0x18, 0x00, 0x00, 0xbb},
> +	{0x19, 0x00, 0x00, 0xbb},
> +	{0x1a, 0x00, 0x00, 0xbb},
> +	{0x1b, 0x00, 0x00, 0xbb},
> +	{0x1c, 0x00, 0x00, 0xbb},
> +	{0x1d, 0x00, 0x00, 0xbb},
> +	{0x1e, 0x00, 0x00, 0xbb},
> +	{0xf0, 0x00, 0x01, 0xbb},
> +	{0x06, 0xe0, 0x0e, 0xbb},
> +	{0x06, 0x60, 0x0e, 0xbb},
> +	{0xb3, 0x5c, 0x01, 0xcc},
> +	{}
> +};
> +#endif
>  static const u8 mi1320_soc_InitQVGA[][4] = {
>  	{0xb3, 0x01, 0x01, 0xcc},
>  	{0xb0, 0x03, 0x19, 0xcc},
> @@ -1308,6 +1446,272 @@ static const u8 mi1320_soc_InitQVGA[][4]
>  	{0xb3, 0x5c, 0x01, 0xcc},
>  	{}
>  };
> +#if 0 /* JPEG vc0323 */
> +static const u8 mi1320_soc_InitQVGA_JPG[][4] = {
> +	{0xb3, 0x01, 0x01, 0xcc},
> +	{0xb0, 0x03, 0x19, 0xcc},
> +	{0xb0, 0x04, 0x02, 0xcc},
> +	{0x00, 0x00, 0x30, 0xdd},
> +	{0xb3, 0x00, 0x64, 0xcc},
> +	{0xb3, 0x00, 0x67, 0xcc},
> +	{0xb3, 0x05, 0x01, 0xcc},
> +	{0xb3, 0x06, 0x01, 0xcc},
> +	{0xb3, 0x08, 0x01, 0xcc},
> +	{0xb3, 0x09, 0x0c, 0xcc},
> +	{0xb3, 0x34, 0x02, 0xcc},
> +	{0xb3, 0x35, 0xc8, 0xcc},
> +	{0xb3, 0x02, 0x00, 0xcc},
> +	{0xb3, 0x03, 0x0a, 0xcc},
> +	{0xb3, 0x04, 0x05, 0xcc},
> +	{0xb3, 0x20, 0x00, 0xcc},
> +	{0xb3, 0x21, 0x00, 0xcc},
> +	{0xb3, 0x22, 0x01, 0xcc},
> +	{0xb3, 0x23, 0xe0, 0xcc},
> +	{0xb3, 0x14, 0x00, 0xcc},
> +	{0xb3, 0x15, 0x00, 0xcc},
> +	{0xb3, 0x16, 0x02, 0xcc},
> +	{0xb3, 0x17, 0x7f, 0xcc},
> +	{0xb3, 0x00, 0x67, 0xcc},
> +	{0xb8, 0x00, 0x00, 0xcc},
> +	{0xbc, 0x00, 0xd1, 0xcc},
> +	{0xbc, 0x01, 0x01, 0xcc},
> +	{0xb3, 0x5c, 0x01, 0xcc},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x00, 0x00, 0x10, 0xdd},
> +	{0xc8, 0x00, 0x00, 0xbb},
> +	{0x00, 0x00, 0x30, 0xdd},
> +	{0xf0, 0x00, 0x00, 0xbb},
> +	{0x00, 0x00, 0x10, 0xdd},
> +	{0x07, 0x00, 0xe0, 0xbb},
> +	{0x08, 0x00, 0x0b, 0xbb},
> +	{0x21, 0x00, 0x0c, 0xbb},
> +	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
> +	{0xb6, 0x00, 0x00, 0xcc},
> +	{0xb6, 0x03, 0x01, 0xcc},
> +	{0xb6, 0x02, 0x40, 0xcc},
> +	{0xb6, 0x05, 0x00, 0xcc},
> +	{0xb6, 0x04, 0xf0, 0xcc},
> +	{0xb6, 0x12, 0xf8, 0xcc},
> +	{0xb6, 0x13, 0x05, 0xcc},
> +	{0xb6, 0x18, 0x00, 0xcc},
> +	{0xb6, 0x17, 0x96, 0xcc},
> +	{0xb6, 0x16, 0x00, 0xcc},
> +	{0xb6, 0x22, 0x12, 0xcc},
> +	{0xb6, 0x23, 0x0b, 0xcc},
> +	{0xbf, 0xc0, 0x39, 0xcc},
> +	{0xbf, 0xc1, 0x04, 0xcc},
> +	{0xbf, 0xcc, 0x00, 0xcc},
> +	{0xbc, 0x02, 0x18, 0xcc},
> +	{0xbc, 0x03, 0x50, 0xcc},
> +	{0xbc, 0x04, 0x18, 0xcc},
> +	{0xbc, 0x05, 0x00, 0xcc},
> +	{0xbc, 0x06, 0x00, 0xcc},
> +	{0xbc, 0x08, 0x30, 0xcc},
> +	{0xbc, 0x09, 0x40, 0xcc},
> +	{0xbc, 0x0a, 0x10, 0xcc},
> +	{0xbc, 0x0b, 0x00, 0xcc},
> +	{0xbc, 0x0c, 0x00, 0xcc},
> +	{0xb3, 0x01, 0x41, 0xcc},
> +	{0xf0, 0x00, 0x00, 0xbb},
> +	{0x05, 0x01, 0x78, 0xbb},
> +	{0x06, 0x00, 0x11, 0xbb},
> +	{0x07, 0x01, 0x42, 0xbb},
> +	{0x08, 0x00, 0x11, 0xbb},
> +	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
> +	{0x21, 0x80, 0x00, 0xbb},
> +	{0x22, 0x0d, 0x0f, 0xbb},
> +	{0x24, 0x80, 0x00, 0xbb},
> +	{0x59, 0x00, 0xff, 0xbb},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x39, 0x03, 0xca, 0xbb},
> +	{0x3a, 0x06, 0x80, 0xbb},
> +	{0x3b, 0x01, 0x52, 0xbb},
> +	{0x3c, 0x05, 0x40, 0xbb},
> +	{0x57, 0x01, 0x9c, 0xbb},
> +	{0x58, 0x01, 0xee, 0xbb},
> +	{0x59, 0x00, 0xf0, 0xbb},
> +	{0x5a, 0x01, 0x20, 0xbb},
> +	{0x5c, 0x1d, 0x17, 0xbb},
> +	{0x5d, 0x22, 0x1c, 0xbb},
> +	{0x64, 0x1e, 0x1c, 0xbb},
> +	{0x5b, 0x00, 0x00, 0xbb},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x22, 0xa0, 0x78, 0xbb},
> +	{0x23, 0xa0, 0x78, 0xbb},
> +	{0x24, 0x7f, 0x00, 0xbb},
> +	{0x28, 0xea, 0x02, 0xbb},
> +	{0x29, 0x86, 0x7a, 0xbb},
> +	{0x5e, 0x52, 0x4c, 0xbb},
> +	{0x5f, 0x20, 0x24, 0xbb},
> +	{0x60, 0x00, 0x02, 0xbb},
> +	{0x02, 0x00, 0xee, 0xbb},
> +	{0x03, 0x39, 0x23, 0xbb},
> +	{0x04, 0x07, 0x24, 0xbb},
> +	{0x09, 0x00, 0xc0, 0xbb},
> +	{0x0a, 0x00, 0x79, 0xbb},
> +	{0x0b, 0x00, 0x04, 0xbb},
> +	{0x0c, 0x00, 0x5c, 0xbb},
> +	{0x0d, 0x00, 0xd9, 0xbb},
> +	{0x0e, 0x00, 0x53, 0xbb},
> +	{0x0f, 0x00, 0x21, 0xbb},
> +	{0x10, 0x00, 0xa4, 0xbb},
> +	{0x11, 0x00, 0xe5, 0xbb},
> +	{0x15, 0x00, 0x00, 0xbb},
> +	{0x16, 0x00, 0x00, 0xbb},
> +	{0x17, 0x00, 0x00, 0xbb},
> +	{0x18, 0x00, 0x00, 0xbb},
> +	{0x19, 0x00, 0x00, 0xbb},
> +	{0x1a, 0x00, 0x00, 0xbb},
> +	{0x1b, 0x00, 0x00, 0xbb},
> +	{0x1c, 0x00, 0x00, 0xbb},
> +	{0x1d, 0x00, 0x00, 0xbb},
> +	{0x1e, 0x00, 0x00, 0xbb},
> +	{0xf0, 0x00, 0x01, 0xbb},
> +	{0x06, 0xe0, 0x0e, 0xbb},
> +	{0x06, 0x60, 0x0e, 0xbb},
> +	{0xb3, 0x5c, 0x01, 0xcc},
> +	{}
> +};
> +#endif
> +#if 0 /* JPEG vc0323 */
> +static const u8 mi1320_soc_InitSXGA_JPG[][4] = {
> +	{0xb3, 0x01, 0x01, 0xcc},
> +	{0xb0, 0x03, 0x19, 0xcc},
> +	{0xb0, 0x04, 0x02, 0xcc},
> +	{0x00, 0x00, 0x33, 0xdd},
> +	{0xb3, 0x00, 0x64, 0xcc},
> +	{0xb3, 0x00, 0x67, 0xcc},
> +	{0xb3, 0x05, 0x00, 0xcc},
> +	{0xb3, 0x06, 0x00, 0xcc},
> +	{0xb3, 0x08, 0x01, 0xcc},
> +	{0xb3, 0x09, 0x0c, 0xcc},
> +	{0xb3, 0x34, 0x02, 0xcc},
> +	{0xb3, 0x35, 0xc8, 0xcc},
> +	{0xb3, 0x02, 0x00, 0xcc},
> +	{0xb3, 0x03, 0x0a, 0xcc},
> +	{0xb3, 0x04, 0x05, 0xcc},
> +	{0xb3, 0x20, 0x00, 0xcc},
> +	{0xb3, 0x21, 0x00, 0xcc},
> +	{0xb3, 0x22, 0x04, 0xcc},
> +	{0xb3, 0x23, 0x00, 0xcc},
> +	{0xb3, 0x14, 0x00, 0xcc},
> +	{0xb3, 0x15, 0x00, 0xcc},
> +	{0xb3, 0x16, 0x04, 0xcc},
> +	{0xb3, 0x17, 0xff, 0xcc},
> +	{0xb3, 0x00, 0x67, 0xcc},
> +	{0xbc, 0x00, 0x71, 0xcc},
> +	{0xbc, 0x01, 0x01, 0xcc},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x00, 0x00, 0x30, 0xdd},
> +	{0xc8, 0x9f, 0x0b, 0xbb},
> +	{0x00, 0x00, 0x20, 0xdd},
> +	{0x5b, 0x00, 0x01, 0xbb},
> +	{0x00, 0x00, 0x20, 0xdd},
> +	{0xf0, 0x00, 0x00, 0xbb},
> +	{0x00, 0x00, 0x30, 0xdd},
> +	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
> +	{0x00, 0x00, 0x20, 0xdd},
> +	{0xb6, 0x00, 0x00, 0xcc},
> +	{0xb6, 0x03, 0x05, 0xcc},
> +	{0xb6, 0x02, 0x00, 0xcc},
> +	{0xb6, 0x05, 0x04, 0xcc},
> +	{0xb6, 0x04, 0x00, 0xcc},
> +	{0xb6, 0x12, 0xf8, 0xcc},
> +	{0xb6, 0x13, 0x29, 0xcc},
> +	{0xb6, 0x18, 0x0a, 0xcc},
> +	{0xb6, 0x17, 0x00, 0xcc},
> +	{0xb6, 0x16, 0x00, 0xcc},
> +	{0xb6, 0x22, 0x12, 0xcc},
> +	{0xb6, 0x23, 0x0b, 0xcc},
> +	{0xbf, 0xc0, 0x39, 0xcc},
> +	{0xbf, 0xc1, 0x04, 0xcc},
> +	{0xbf, 0xcc, 0x00, 0xcc},
> +	{0xb3, 0x5c, 0x01, 0xcc},
> +	{0xb3, 0x01, 0x41, 0xcc},
> +	{0xf0, 0x00, 0x00, 0xbb},
> +	{0x05, 0x01, 0x78, 0xbb},
> +	{0x06, 0x00, 0x11, 0xbb},
> +	{0x07, 0x01, 0x42, 0xbb},
> +	{0x08, 0x00, 0x11, 0xbb},
> +	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
> +	{0x21, 0x80, 0x00, 0xbb},
> +	{0x22, 0x0d, 0x0f, 0xbb},
> +	{0x24, 0x80, 0x00, 0xbb},
> +	{0x59, 0x00, 0xff, 0xbb},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x39, 0x03, 0xca, 0xbb},
> +	{0x3a, 0x06, 0x80, 0xbb},
> +	{0x3b, 0x01, 0x52, 0xbb},
> +	{0x3c, 0x05, 0x40, 0xbb},
> +	{0x57, 0x01, 0x9c, 0xbb},
> +	{0x58, 0x01, 0xee, 0xbb},
> +	{0x59, 0x00, 0xf0, 0xbb},
> +	{0x5a, 0x01, 0x20, 0xbb},
> +	{0x5c, 0x1d, 0x17, 0xbb},
> +	{0x5d, 0x22, 0x1c, 0xbb},
> +	{0x64, 0x1e, 0x1c, 0xbb},
> +	{0x5b, 0x00, 0x00, 0xbb},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x22, 0xa0, 0x78, 0xbb},
> +	{0x23, 0xa0, 0x78, 0xbb},
> +	{0x24, 0x7f, 0x00, 0xbb},
> +	{0x28, 0xea, 0x02, 0xbb},
> +	{0x29, 0x86, 0x7a, 0xbb},
> +	{0x5e, 0x52, 0x4c, 0xbb},
> +	{0x5f, 0x20, 0x24, 0xbb},
> +	{0x60, 0x00, 0x02, 0xbb},
> +	{0x02, 0x00, 0xee, 0xbb},
> +	{0x03, 0x39, 0x23, 0xbb},
> +	{0x04, 0x07, 0x24, 0xbb},
> +	{0x09, 0x00, 0xc0, 0xbb},
> +	{0x0a, 0x00, 0x79, 0xbb},
> +	{0x0b, 0x00, 0x04, 0xbb},
> +	{0x0c, 0x00, 0x5c, 0xbb},
> +	{0x0d, 0x00, 0xd9, 0xbb},
> +	{0x0e, 0x00, 0x53, 0xbb},
> +	{0x0f, 0x00, 0x21, 0xbb},
> +	{0x10, 0x00, 0xa4, 0xbb},
> +	{0x11, 0x00, 0xe5, 0xbb},
> +	{0x15, 0x00, 0x00, 0xbb},
> +	{0x16, 0x00, 0x00, 0xbb},
> +	{0x17, 0x00, 0x00, 0xbb},
> +	{0x18, 0x00, 0x00, 0xbb},
> +	{0x19, 0x00, 0x00, 0xbb},
> +	{0x1a, 0x00, 0x00, 0xbb},
> +	{0x1b, 0x00, 0x00, 0xbb},
> +	{0x1c, 0x00, 0x00, 0xbb},
> +	{0x1d, 0x00, 0x00, 0xbb},
> +	{0x1e, 0x00, 0x00, 0xbb},
> +	{0xf0, 0x00, 0x01, 0xbb},
> +	{0x06, 0xe0, 0x0e, 0xbb},
> +	{0x06, 0x60, 0x0e, 0xbb},
> +	{0xb3, 0x5c, 0x01, 0xcc},
> +	{0xf0, 0x00, 0x00, 0xbb},
> +	{0x05, 0x01, 0x13, 0xbb},
> +	{0x06, 0x00, 0x11, 0xbb},
> +	{0x07, 0x00, 0x85, 0xbb},
> +	{0x08, 0x00, 0x27, 0xbb},
> +	{0x20, 0x01, 0x03, 0xbb},	/* h/v flip */
> +	{0x21, 0x80, 0x00, 0xbb},
> +	{0x22, 0x0d, 0x0f, 0xbb},
> +	{0x24, 0x80, 0x00, 0xbb},
> +	{0x59, 0x00, 0xff, 0xbb},
> +	{0xf0, 0x00, 0x02, 0xbb},
> +	{0x39, 0x03, 0x0d, 0xbb},
> +	{0x3a, 0x06, 0x1b, 0xbb},
> +	{0x3b, 0x00, 0x95, 0xbb},
> +	{0x3c, 0x04, 0xdb, 0xbb},
> +	{0x57, 0x02, 0x00, 0xbb},
> +	{0x58, 0x02, 0x66, 0xbb},
> +	{0x59, 0x00, 0xff, 0xbb},
> +	{0x5a, 0x01, 0x33, 0xbb},
> +	{0x5c, 0x12, 0x0d, 0xbb},
> +	{0x5d, 0x16, 0x11, 0xbb},
> +	{0x64, 0x5e, 0x1c, 0xbb},
> +	{0x2f, 0x90, 0x00, 0xbb},
> +	{}
> +};
> +#endif
>  static const u8 mi1320_soc_InitSXGA[][4] = {
>  	{0xb3, 0x01, 0x01, 0xcc},
>  	{0xb0, 0x03, 0x19, 0xcc},
> @@ -3512,6 +3916,11 @@ static int sd_start(struct gspca_dev *gs
>  		mi1320_soc_InitSXGA,
>  		mi1320_soc_InitVGA,
>  		mi1320_soc_InitQVGA,
> +#if 0 /* JPEG vc0323 */
> +		mi1320_soc_InitSXGA_JPG,
> +		mi1320_soc_InitVGA_JPG,
> +		mi1320_soc_InitQVGA_JPG
> +#endif
>  	};
>  
>  /*fixme: back sensor only*/

I've no idea if the above is useful or not. Maybe Hans or Jean could
give us some hint about that. Eventually, this can be already obsoleted
by some newer gspca patch.

> diff -upr /tmp/stripped/drivers/media/video/gspca/zc3xx.c /tmp/not_stripped/drivers/media/video/gspca/zc3xx.c
> --- /tmp/stripped/drivers/media/video/gspca/zc3xx.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/gspca/zc3xx.c	2011-01-10 10:02:08.000000000 -0200
> @@ -228,7 +228,11 @@ struct usb_action {
>  static const struct usb_action adcm2700_Initial[] = {
>  	{0xa0, 0x01, ZC3XX_R000_SYSTEMCONTROL},		/* 00,00,01,cc */
>  	{0xa0, 0x04, ZC3XX_R002_CLOCKSELECT},		/* 00,02,04,cc */
> +#if 1 /*jfm*/
>  	{0xa0, 0x00, ZC3XX_R008_CLOCKSETTING},		/* 00,08,03,cc */
> +#else
> +	{0xa0, 0x03, ZC3XX_R008_CLOCKSETTING},		/* 00,08,03,cc */
> +#endif
>  	{0xa0, 0x0a, ZC3XX_R010_CMOSSENSORSELECT},	/* 00,10,0a,cc */
>  	{0xa0, 0xd3, ZC3XX_R08B_I2CDEVICEADDR},		/* 00,8b,d3,cc */
>  	{0xa0, 0x02, ZC3XX_R003_FRAMEWIDTHHIGH},	/* 00,03,02,cc */
> @@ -248,7 +252,11 @@ static const struct usb_action adcm2700_
>  	{0xbb, 0x00, 0x0400},				/* 04,00,00,bb */
>  	{0xdd, 0x00, 0x0010},				/* 00,00,10,dd */
>  	{0xbb, 0x0f, 0x140f},				/* 14,0f,0f,bb */
> +#if 1 /*jfm-mswin*/
>  	{0xa0, 0xb7, ZC3XX_R101_SENSORCORRECTION},	/* 01,01,37,cc */
> +#else
> +	{0xa0, 0x37, ZC3XX_R101_SENSORCORRECTION},	/* 01,01,37,cc */
> +#endif
>  	{0xa0, 0x0d, ZC3XX_R100_OPERATIONMODE},		/* 01,00,0d,cc */
>  	{0xa0, 0x06, ZC3XX_R189_AWBSTATUS},		/* 01,89,06,cc */
>  	{0xa0, 0x03, ZC3XX_R1C5_SHARPNESSMODE},		/* 01,c5,03,cc */
> @@ -317,7 +325,11 @@ static const struct usb_action adcm2700_
>  static const struct usb_action adcm2700_InitialScale[] = {
>  	{0xa0, 0x01, ZC3XX_R000_SYSTEMCONTROL},		/* 00,00,01,cc */
>  	{0xa0, 0x10, ZC3XX_R002_CLOCKSELECT},		/* 00,02,10,cc */
> +#if 1 /*jfm*/
>  	{0xa0, 0x00, ZC3XX_R008_CLOCKSETTING},		/* 00,08,03,cc */
> +#else
> +	{0xa0, 0x03, ZC3XX_R008_CLOCKSETTING},		/* 00,08,03,cc */
> +#endif
>  	{0xa0, 0x0a, ZC3XX_R010_CMOSSENSORSELECT},	/* 00,10,0a,cc */
>  	{0xa0, 0xd3, ZC3XX_R08B_I2CDEVICEADDR},		/* 00,8b,d3,cc */
>  	{0xa0, 0x02, ZC3XX_R003_FRAMEWIDTHHIGH},	/* 00,03,02,cc */
> @@ -337,7 +349,11 @@ static const struct usb_action adcm2700_
>  	{0xbb, 0x00, 0x0400},				/* 04,00,00,bb */
>  	{0xdd, 0x00, 0x0010},				/* 00,00,10,dd */
>  	{0xbb, 0x0f, 0x140f},				/* 14,0f,0f,bb */
> +#if 1 /*jfm-mswin*/
>  	{0xa0, 0xb7, ZC3XX_R101_SENSORCORRECTION},	/* 01,01,37,cc */
> +#else
> +	{0xa0, 0x37, ZC3XX_R101_SENSORCORRECTION},	/* 01,01,37,cc */
> +#endif
>  	{0xa0, 0x0d, ZC3XX_R100_OPERATIONMODE},		/* 01,00,0d,cc */
>  	{0xa0, 0x06, ZC3XX_R189_AWBSTATUS},		/* 01,89,06,cc */
>  	{0xa0, 0x03, ZC3XX_R1C5_SHARPNESSMODE},		/* 01,c5,03,cc */
> @@ -365,9 +381,17 @@ static const struct usb_action adcm2700_
>  	{0xbb, 0x5f, 0x2090},				/* 20,5f,90,bb */
>  	{0xbb, 0x01, 0x8000},				/* 80,01,00,bb */
>  	{0xbb, 0x09, 0x8400},				/* 84,09,00,bb */
> +#if 1 /*jfm-mswin*/
>  	{0xbb, 0x86, 0x0002},				/* 00,88,02,bb */
> +#else
> +	{0xbb, 0x88, 0x0002},				/* 00,88,02,bb */
> +#endif
>  	{0xbb, 0xe6, 0x0401},				/* 04,e6,01,bb */
> +#if 1 /*jfm-mswin*/
>  	{0xbb, 0x86, 0x0802},				/* 08,88,02,bb */
> +#else
> +	{0xbb, 0x88, 0x0802},				/* 08,88,02,bb */
> +#endif
>  	{0xbb, 0xe6, 0x0c01},				/* 0c,e6,01,bb */
>  	{0xa0, 0x01, ZC3XX_R010_CMOSSENSORSELECT},	/* 00,10,01,cc */
>  	{0xdd, 0x00, 0x0010},				/* 00,00,10,dd */
> @@ -3159,7 +3183,12 @@ static const struct usb_action mc501cb_N
>  static const struct usb_action ov7620_Initial[] = {	/* 640x480 */
>  	{0xa0, 0x01, ZC3XX_R000_SYSTEMCONTROL}, /* 00,00,01,cc */
>  	{0xa0, 0x40, ZC3XX_R002_CLOCKSELECT}, /* 00,02,40,cc */
> +#if 1 /*jfm*/
>  	{0xa0, 0x00, ZC3XX_R008_CLOCKSETTING}, /* 00,08,00,cc */
> +#else
> +	{0xa0, 0x03, ZC3XX_R008_CLOCKSETTING}, /* 00,08,00,cc */
> +						/* mx change? */
> +#endif
>  	{0xa0, 0x01, ZC3XX_R001_SYSTEMOPERATING}, /* 00,01,01,cc */
>  	{0xa0, 0x06, ZC3XX_R010_CMOSSENSORSELECT}, /* 00,10,06,cc */
>  	{0xa0, 0x02, ZC3XX_R083_RGAINADDR}, /* 00,83,02,cc */

I've no idea if the above is useful or not. Maybe Hans or Jean could
give us some hint about that. Eventually, this can be already obsoleted
by some newer gspca patch.

> diff -upr /tmp/stripped/drivers/media/video/ov7670.c /tmp/not_stripped/drivers/media/video/ov7670.c
> --- /tmp/stripped/drivers/media/video/ov7670.c	2011-01-10 10:01:51.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/ov7670.c	2011-01-10 10:02:07.000000000 -0200
> @@ -500,6 +500,27 @@ static int ov7670_write(struct v4l2_subd
>  }
>  #endif /* CONFIG_OLPC_XO_1 */
>  
> +#if 0 /* Not currently used, but maybe should be  */
> +
> +static int ov7670_write_mask(struct v4l2_subdev *sd, unsigned char reg,
> +		unsigned char value, unsigned char mask)
> +{
> +	unsigned char v;
> +	int ret, tries = 0;
> +
> +	ret = ov7670_read(sd, reg, &v);
> +	if (ret < 0)
> +		return ret;
> +	v &= ~mask;
> +	v |= (value & mask);
> +	msleep(10); /* FIXME experiment */
> +	do {
> +		ret = ov7670_write(sd, reg, v);
> +	} while (ret < 0 && ++tries < 3);
> +	return ret;
> +}
> +
> +#endif
>  
>  /*
>   * Write a list of register settings; ff/ff stops the process.
> @@ -901,6 +922,28 @@ static int ov7670_s_parm(struct v4l2_sub
>   * Code for dealing with controls.
>   */
>  
> +#if 0  /* This seems unneeded after all, should probably come out */
> +/*
> + * Fetch and store the color matrix.
> + */
> +static int ov7670_get_cmatrix(struct v4l2_subdev *sd,
> +	int matrix[CMATRIX_LEN])
> +{
> +	int i, ret;
> +	unsigned char signbits;
> +
> +	ret = ov7670_read(sd, REG_CMATRIX_SIGN, &signbits);
> +	for (i = 0; i < CMATRIX_LEN; i++) {
> +		unsigned char raw;
> +
> +		ret += ov7670_read(sd, REG_CMATRIX_BASE + i, &raw);
> +		matrix[i] = (int) raw;
> +		if (signbits & (1 << i))
> +			matrix[i] *= -1;
> +	}
> +	return ret;
> +}
> +#endif
>  
>  

I've no idea if the above is useful or not.

>  
> diff -upr /tmp/stripped/drivers/media/video/saa7134/saa7134-core.c /tmp/not_stripped/drivers/media/video/saa7134/saa7134-core.c
> --- /tmp/stripped/drivers/media/video/saa7134/saa7134-core.c	2011-01-10 10:01:52.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/saa7134/saa7134-core.c	2011-01-10 10:02:08.000000000 -0200
> @@ -1140,6 +1140,9 @@ static void __devexit saa7134_finidev(st
>  	release_mem_region(pci_resource_start(pci_dev,0),
>  			   pci_resource_len(pci_dev,0));
>  
> +#if 0  /* causes some trouble when reinserting the driver ... */
> +	pci_disable_device(pci_dev);
> +#endif
>  
>  	v4l2_device_unregister(&dev->v4l2_dev);
>  

This is a common issue with several PCI drivers. Maybe it is a good idea to
backport it.

> diff -upr /tmp/stripped/drivers/media/video/tvp5150.c /tmp/not_stripped/drivers/media/video/tvp5150.c
> --- /tmp/stripped/drivers/media/video/tvp5150.c	2011-01-10 10:01:51.000000000 -0200
> +++ /tmp/not_stripped/drivers/media/video/tvp5150.c	2011-01-10 10:02:07.000000000 -0200
> @@ -220,6 +220,10 @@ static int tvp5150_log_status(struct v4l
>  			tvp5150_read(sd, TVP5150_STATUS_REG_3),
>  			tvp5150_read(sd, TVP5150_STATUS_REG_4),
>  			tvp5150_read(sd, TVP5150_STATUS_REG_5));
> +#if 0 /* This will pop a value from vbi reg */
> +	printk("tvp5150: VBI FIFO read data = 0x%02x\n",
> +			tvp5150_read(sd, TVP5150_VBI_FIFO_READ_DATA));
> +#endif
>  
>  	dump_reg_range(sd, "Teletext filter 1",   TVP5150_TELETEXT_FIL1_INI,
>  			TVP5150_TELETEXT_FIL1_END, 8);

Bogus.

> diff -upr /tmp/stripped/include/media/lirc.h /tmp/not_stripped/include/media/lirc.h
> --- /tmp/stripped/include/media/lirc.h	2011-01-10 10:01:49.000000000 -0200
> +++ /tmp/not_stripped/include/media/lirc.h	2011-01-10 10:02:05.000000000 -0200
> @@ -95,6 +95,12 @@
>  #define LIRC_GET_MIN_TIMEOUT           _IOR('i', 0x00000008, __u32)
>  #define LIRC_GET_MAX_TIMEOUT           _IOR('i', 0x00000009, __u32)
>  
> +#if 0	/* these ioctls are not used at the moment */
> +#define LIRC_GET_MIN_FILTER_PULSE      _IOR('i', 0x0000000a, __u32)
> +#define LIRC_GET_MAX_FILTER_PULSE      _IOR('i', 0x0000000b, __u32)
> +#define LIRC_GET_MIN_FILTER_SPACE      _IOR('i', 0x0000000c, __u32)
> +#define LIRC_GET_MAX_FILTER_SPACE      _IOR('i', 0x0000000d, __u32)
> +#endif
>  
>  /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
>  #define LIRC_GET_LENGTH                _IOR('i', 0x0000000f, __u32)
> @@ -115,6 +121,23 @@
>   */
>  #define LIRC_SET_REC_TIMEOUT           _IOW('i', 0x00000018, __u32)
>  
> +#if 0	/* these ioctls are not used at the moment */
> +/*
> + * pulses shorter than this are filtered out by hardware (software
> + * emulation in lirc_dev?)
> + */
> +#define LIRC_SET_REC_FILTER_PULSE      _IOW('i', 0x00000019, __u32)
> +/*
> + * spaces shorter than this are filtered out by hardware (software
> + * emulation in lirc_dev?)
> + */
> +#define LIRC_SET_REC_FILTER_SPACE      _IOW('i', 0x0000001a, __u32)
> +/*
> + * if filter cannot be set independantly for pulse/space, this should
> + * be used
> + */
> +#define LIRC_SET_REC_FILTER            _IOW('i', 0x0000001b, __u32)
> +#endif
>  
>  /*
>   * to set a range use
> @@ -128,5 +151,13 @@
>  
>  #define LIRC_NOTIFY_DECODE             _IO('i', 0x00000020)
>  
> +#if 0	/* these ioctls are not used at the moment */
> +/*
> + * from the next key press on the driver will send
> + * LIRC_MODE2_FREQUENCY packets
> + */
> +#define LIRC_MEASURE_CARRIER_ENABLE    _IO('i', 0x00000021)
> +#define LIRC_MEASURE_CARRIER_DISABLE   _IO('i', 0x00000022)
> +#endif
>  
>  #endif

I think that the above were already backported.

> diff -upr /tmp/stripped/include/media/saa6752hs.h /tmp/not_stripped/include/media/saa6752hs.h
> --- /tmp/stripped/include/media/saa6752hs.h	2011-01-10 10:01:49.000000000 -0200
> +++ /tmp/not_stripped/include/media/saa6752hs.h	2011-01-10 10:02:05.000000000 -0200
> @@ -18,6 +18,53 @@
>      Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>  */
>  
> +#if 0 /* ndef _SAA6752HS_H */
> +#define _SAA6752HS_H
> +
> +enum mpeg_video_bitrate_mode {
> +	MPEG_VIDEO_BITRATE_MODE_VBR = 0, /* Variable bitrate */
> +	MPEG_VIDEO_BITRATE_MODE_CBR = 1, /* Constant bitrate */
> +
> +	MPEG_VIDEO_BITRATE_MODE_MAX
> +};
> +
> +enum mpeg_audio_bitrate {
> +	MPEG_AUDIO_BITRATE_256 = 0, /* 256 kBit/sec */
> +	MPEG_AUDIO_BITRATE_384 = 1, /* 384 kBit/sec */
> +
> +	MPEG_AUDIO_BITRATE_MAX
> +};
> +
> +enum mpeg_video_format {
> +	MPEG_VIDEO_FORMAT_D1 = 0,
> +	MPEG_VIDEO_FORMAT_2_3_D1 = 1,
> +	MPEG_VIDEO_FORMAT_1_2_D1 = 2,
> +	MPEG_VIDEO_FORMAT_SIF = 3,
> +
> +	MPEG_VIDEO_FORMAT_MAX
> +};
> +
> +#define MPEG_VIDEO_TARGET_BITRATE_MAX 27000
> +#define MPEG_VIDEO_MAX_BITRATE_MAX 27000
> +#define MPEG_TOTAL_BITRATE_MAX 27000
> +#define MPEG_PID_MAX ((1 << 14) - 1)
> +
> +struct mpeg_params {
> +	enum mpeg_video_bitrate_mode video_bitrate_mode;
> +	unsigned int video_target_bitrate;
> +	unsigned int video_max_bitrate; // only used for VBR
> +	enum mpeg_audio_bitrate audio_bitrate;
> +	unsigned int total_bitrate;
> +
> +	unsigned int pmt_pid;
> +	unsigned int video_pid;
> +	unsigned int audio_pid;
> +	unsigned int pcr_pid;
> +
> +	enum mpeg_video_format video_format;
> +};
> +
> +#endif // _SAA6752HS_H

Probably bogus. Nobody is working with saa6752hs anymore. This is an old hardware,
and this patch just adds some unused info to the header file.

Cheers,
Mauro

Re: Debug code in HG repositories

[Oliver Endriss]

On Monday 10 January 2011 13:27:09 Mauro Carvalho Chehab wrote:
> > ...
> > diff -upr /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c
> > --- /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c	2011-01-10 10:01:49.000000000 -0200
> > +++ /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c	2011-01-10 10:02:05.000000000 -0200
> > @@ -272,6 +272,32 @@ static const struct pci_device_id ngene_
> >  	NGENE_ID(0x18c3, 0xdd10, ngene_info_duoFlexS2),
> >  	NGENE_ID(0x18c3, 0xdd20, ngene_info_duoFlexS2),
> >  	NGENE_ID(0x1461, 0x062e, ngene_info_m780),
> > +#if 0 /* not (yet?) supported */
> > +	NGENE_ID(0x18c3, 0x0000, ngene_info_appboard),
> > +	NGENE_ID(0x18c3, 0x0004, ngene_info_appboard),
> > +	NGENE_ID(0x18c3, 0x8011, ngene_info_appboard),
> > +	NGENE_ID(0x18c3, 0x8015, ngene_info_appboard_ntsc),
> > +	NGENE_ID(0x153b, 0x1167, ngene_info_terratec),
> > +	NGENE_ID(0x18c3, 0x0030, ngene_info_python),
> > +	NGENE_ID(0x18c3, 0x0052, ngene_info_sidewinder),
> > +	NGENE_ID(0x18c3, 0x8f00, ngene_info_racer),
> > +	NGENE_ID(0x18c3, 0x0041, ngene_info_viper_v1),
> > +	NGENE_ID(0x18c3, 0x0042, ngene_info_viper_v2),
> > +	NGENE_ID(0x14f3, 0x0041, ngene_info_vbox_v1),
> > +	NGENE_ID(0x14f3, 0x0043, ngene_info_vbox_v2),
> > +	NGENE_ID(0x18c3, 0xabcd, ngene_info_s2),
> > +	NGENE_ID(0x18c3, 0xabc2, ngene_info_s2_b),
> > +	NGENE_ID(0x18c3, 0xabc3, ngene_info_s2_b),
> > +	NGENE_ID(0x18c3, 0x0001, ngene_info_appboard),
> > +	NGENE_ID(0x18c3, 0x0005, ngene_info_appboard),
> > +	NGENE_ID(0x18c3, 0x0009, ngene_info_appboard_atsc),
> > +	NGENE_ID(0x18c3, 0x000b, ngene_info_appboard_atsc),
> > +	NGENE_ID(0x18c3, 0x0010, ngene_info_shrek_50_fp),
> > +	NGENE_ID(0x18c3, 0x0011, ngene_info_shrek_60_fp),
> > +	NGENE_ID(0x18c3, 0x0012, ngene_info_shrek_50),
> > +	NGENE_ID(0x18c3, 0x0013, ngene_info_shrek_60),
> > +	NGENE_ID(0x18c3, 0x0000, ngene_info_hognose),
> > +#endif
> >  	{0}
> >  };
> >  MODULE_DEVICE_TABLE(pci, ngene_id_tbl);
> 
> It is probably a good idea to backport this one. I would change it to #if 1, to allow
> people to test (or I would create a CONFIG_NGENE_EXPERIMENTAL to enable such support).

Nack, it would not work. If you have a look at a really unstripped ;-)
version of the file, you will notice that you have to invest a
considerable amount of effort to get these card types running.

This kind of stuff should be added one by one, whenever someone is
working on it.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: Debug code in HG repositories

[Oliver Endriss]

On Monday 10 January 2011 13:04:54 Mauro Carvalho Chehab wrote:
> Em 07-01-2011 21:56, Oliver Endriss escreveu:
> > ...
> > There are large pieces of driver code which are currently unused, and
> > nobody can tell whether they will ever be needed.
> > 
> > On the other hand a developer spent days writing this stuff, and now it
> > does not exist anymore - without any trace!
> > 
> > The problem is not, that it is missing in the current snapshot, but
> > that it has never been in the git repository, and there is no way to
> > recover it.
> 
> The Mercurial tree will stay there forever. We still have there the old CVS 
> trees used by DVB and V4L development.
> > 
> > Afaics, the only way to preserve this kind of code is 'out-of-tree'.
> > It is a shame... :-(
> 
> I see your point. It is harder for people to re-use that code, as they are not
> upstream.

The main problem is that they do not even know that the code exists.

Maybe I should add some comment to the driver, that someone should look
into the HG repository, before he starts re-inventing the wheel.

> It is easy to recover the changes with:
> 
> $ gentree.pl 2.6.37 --strip_dead_code linux/ /tmp/stripped
> $ gentree.pl 2.6.37  linux/ /tmp/not_stripped
> $ diff -upr /tmp/stripped/ /tmp/not_stripped/ >/tmp/revert_removed_code.patch
> 
> As a reference and further discussions, I'm enclosing the diff.

The resulting diff is far from complete.
In fact, the most interesting parts are missing.

Apparently, the command
    gentree.pl 2.6.37  linux/ /tmp/not_stripped
stripped all '#if 0' blocks, which are not followed by a comment.
Just compare the original ngene_av.c with the resulting version in
/tmp/non_stripped.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: Debug code in HG repositories

[Mauro Carvalho Chehab]

Em 10-01-2011 23:10, Oliver Endriss escreveu:
> On Monday 10 January 2011 13:04:54 Mauro Carvalho Chehab wrote:
>> Em 07-01-2011 21:56, Oliver Endriss escreveu:
>>> ...
>>> There are large pieces of driver code which are currently unused, and
>>> nobody can tell whether they will ever be needed.
>>>
>>> On the other hand a developer spent days writing this stuff, and now it
>>> does not exist anymore - without any trace!
>>>
>>> The problem is not, that it is missing in the current snapshot, but
>>> that it has never been in the git repository, and there is no way to
>>> recover it.
>>
>> The Mercurial tree will stay there forever. We still have there the old CVS 
>> trees used by DVB and V4L development.
>>>
>>> Afaics, the only way to preserve this kind of code is 'out-of-tree'.
>>> It is a shame... :-(
>>
>> I see your point. It is harder for people to re-use that code, as they are not
>> upstream.
> 
> The main problem is that they do not even know that the code exists.
> 
> Maybe I should add some comment to the driver, that someone should look
> into the HG repository, before he starts re-inventing the wheel.
> 
>> It is easy to recover the changes with:
>>
>> $ gentree.pl 2.6.37 --strip_dead_code linux/ /tmp/stripped
>> $ gentree.pl 2.6.37  linux/ /tmp/not_stripped
>> $ diff -upr /tmp/stripped/ /tmp/not_stripped/ >/tmp/revert_removed_code.patch
>>
>> As a reference and further discussions, I'm enclosing the diff.
> 
> The resulting diff is far from complete.
> In fact, the most interesting parts are missing.
> 
> Apparently, the command
>     gentree.pl 2.6.37  linux/ /tmp/not_stripped
> stripped all '#if 0' blocks, which are not followed by a comment.
> Just compare the original ngene_av.c with the resulting version in
> /tmp/non_stripped.

Oliver,

I fixed the script. Sorry for taking a long time. Too much stuff here.
The fix patch were already merged at -hg.

It will now produce the right results. A regex expression were waiting for
 something after #if 1/#if 0, with is generally ok, as lines end with \n.
However, due to the usage of chomp, the \n character were removed, and the 
regex failed on lines with just '#if 0'.

-

On most places, the code inside #if 0 are just legacy stuff, where people
were trying to implement a different code for something. However, at ngene,
the code inside #if 0 are there just because the ngene developers didn't find
time yet to work on them. So, it may make sense to add those code into mainstream,
if people will uncomment part of those code. So, feel free to send me a patch
adding the commented code, if you need.

Thanks,
Mauro

Re: Debug code in HG repositories

[Vincent McIntyre]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

On 1/8/11, Hans Verkuil <hverkuil@xs4all.nl> wrote:

> Have you tried Mauro's media_build tree? I had to use it today to test a
> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
> promote this more. I could add backwards compatibility builds to my daily
> build script that uses this in order to check for which kernel versions
> this compiles if there is sufficient interest.
>

As an end-user I would be interested in seeing this added, since it
will allow faster detection of breakage in the older versions. For
instance building against 2.6.32 fails like this:

  CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
function 'hdpvr_new_i2c_ir':
/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
too many arguments to function 'i2c_new_probed_device'
make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
Error 1
make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
make: *** [default] Error 2

It's unclear that adding this would cause a lot of extra work; the
patches that need to be applied are quite few - a tribute to the
design work!

For what it's worth, I've attached the shell script I use to pull
updates and do a new build.
Doing the initial setup is well explained by the
linuxtv.org/media_tree.git page,
but this script may be of use to end users wanting to track development.

Cheers
Vince

[-- Attachment #2: update-and-build.sh --]
[-- Type: application/x-sh, Size: 2035 bytes --]

Re: Debug code in HG repositories

[Mauro Carvalho Chehab]

Em 07-01-2011 23:02, Vincent McIntyre escreveu:
> On 1/8/11, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> 
>> Have you tried Mauro's media_build tree? I had to use it today to test a
>> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
>> promote this more. I could add backwards compatibility builds to my daily
>> build script that uses this in order to check for which kernel versions
>> this compiles if there is sufficient interest.
>>
> 
> As an end-user I would be interested in seeing this added, since it
> will allow faster detection of breakage in the older versions. For
> instance building against 2.6.32 fails like this:
> 
>   CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
> /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
> function 'hdpvr_new_i2c_ir':
> /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
> too many arguments to function 'i2c_new_probed_device'
> make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
> Error 1
> make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l] Error 2
> make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
> make[2]: *** [default] Error 2
> make[2]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
> make: *** [default] Error 2
> 
> It's unclear that adding this would cause a lot of extra work; the
> patches that need to be applied are quite few - a tribute to the
> design work!

That's weird. Here, it compiles fine against my 2.6.32 kernel, as there's a
patch that removes the extra parameter. I'll double check and add a fix
if I found something wrong.

> For what it's worth, I've attached the shell script I use to pull
> updates and do a new build.
> Doing the initial setup is well explained by the
> linuxtv.org/media_tree.git page,
> but this script may be of use to end users wanting to track development.

Thanks for your script, but it seems specific to your environment. Could you
please make it more generic and perhaps patch the existing build.sh script?
It would be nice to have some optional parameters there, to make life easier
for end-users.

Thanks!
Mauro

Re: Debug code in HG repositories

[Vincent McIntyre]

On 1/10/11, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:

> Thanks for your script, but it seems specific to your environment. Could you
> please make it more generic and perhaps patch the existing build.sh script?

I was mainly intending to show how I happen to do this. It's way too complicated
compared to build.sh, which is a really nice solution.

> It would be nice to have some optional parameters there, to make life easier
> for end-users.

I can certainly try to supply some patches but I'm not sure what
parameters you have in mind.
build.sh is such a nice simple method; my script attempts to do
everything via git which is
overkill unless one is actively developing. Perhaps I could rework
into a distinct build_git.sh.

Cheers
Vince

Re: Debug code in HG repositories

[Mauro Carvalho Chehab]

Em 11-01-2011 08:37, Vincent McIntyre escreveu:
> On 1/10/11, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> 
>> Thanks for your script, but it seems specific to your environment. Could you
>> please make it more generic and perhaps patch the existing build.sh script?
> 
> I was mainly intending to show how I happen to do this. It's way too complicated
> compared to build.sh, which is a really nice solution.
> 
>> It would be nice to have some optional parameters there, to make life easier
>> for end-users.
> 
> I can certainly try to supply some patches but I'm not sure what
> parameters you have in mind.
> build.sh is such a nice simple method; my script attempts to do
> everything via git which is
> overkill unless one is actively developing. Perhaps I could rework
> into a distinct build_git.sh.

That could be interesting. For those using git trees, the better way is to use
	make -C linux DIR=<git dir>

This needs to be done just once, as it will store some info at linux/.linked_dir.
It will basically store there the directory with the git tree, and the hashes of
the original, media_build original copy and media_build copy after patched. Every
time someone tries to compile, it re-checks the hashes and re-copy the file from
the git tree, if needed.

Cheers,
Mauro

Re: Debug code in HG repositories

[Vincent McIntyre]

On 1/10/11, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em 07-01-2011 23:02, Vincent McIntyre escreveu:
>> On 1/8/11, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>
>>> Have you tried Mauro's media_build tree? I had to use it today to test a
>>> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
>>> promote this more. I could add backwards compatibility builds to my daily
>>> build script that uses this in order to check for which kernel versions
>>> this compiles if there is sufficient interest.
>>>
>>
>> As an end-user I would be interested in seeing this added, since it
>> will allow faster detection of breakage in the older versions. For
>> instance building against 2.6.32 fails like this:
>>
>>   CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
>> /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
>> function 'hdpvr_new_i2c_ir':
>> /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
>> too many arguments to function 'i2c_new_probed_device'
>> make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
>> Error 1
>> make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l]
>> Error 2
>> make[3]: Leaving directory
>> `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
>> make[2]: *** [default] Error 2
>> make[2]: Leaving directory
>> `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
>> make: *** [default] Error 2
>>
>> It's unclear that adding this would cause a lot of extra work; the
>> patches that need to be applied are quite few - a tribute to the
>> design work!
>
> That's weird. Here, it compiles fine against my 2.6.32 kernel, as there's a
> patch that removes the extra parameter. I'll double check and add a fix
> if I found something wrong.

I think a couple of modules may have been missed;
$ cd media_build
$ grep -rl i2c_new_probed_device v4l | grep -v .o
v4l/cx23885-i2c.c
v4l/bttv-input.c
v4l/cx88-input.c
v4l/ivtv-i2c.c
v4l/hdpvr-i2c.c
v4l/v4l2-common.c
v4l/cx18-i2c.c
v4l/em28xx-cards.c

$ grep +++ backports/v2.6.35_i2c_new_probed_device.patch
+++ b/drivers/media/video/bt8xx/bttv-input.c    Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/cx18/cx18-i2c.c       Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/cx23885/cx23885-i2c.c Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/em28xx/em28xx-cards.c Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/ivtv/ivtv-i2c.c       Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/v4l2-common.c Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/ivtv/ivtv-i2c.c       Tue Oct 26 23:18:52 2010 -0200

which on the face of it suggests
  btty-input.c
  cx88-input.c
  hdpvr-i2c.c
need looking at.

I get the same result whether building from a git clone of media-tree
or via media_build/build.sh.

I am building against ubuntu 2.6.32-26-generic aka 2.6.32.24+drm33.11, on i386.
I am using just their kernel-headers package for the build. Usually it works ok.

Cheers
Vince

Re: Debug code in HG repositories

[Mauro Carvalho Chehab]

Em 11-01-2011 08:47, Vincent McIntyre escreveu:
> On 1/10/11, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>> Em 07-01-2011 23:02, Vincent McIntyre escreveu:
>>> On 1/8/11, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>
>>>> Have you tried Mauro's media_build tree? I had to use it today to test a
>>>> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
>>>> promote this more. I could add backwards compatibility builds to my daily
>>>> build script that uses this in order to check for which kernel versions
>>>> this compiles if there is sufficient interest.
>>>>
>>>
>>> As an end-user I would be interested in seeing this added, since it
>>> will allow faster detection of breakage in the older versions. For
>>> instance building against 2.6.32 fails like this:
>>>
>>>   CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
>>> /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
>>> function 'hdpvr_new_i2c_ir':
>>> /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
>>> too many arguments to function 'i2c_new_probed_device'
>>> make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
>>> Error 1
>>> make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l]
>>> Error 2
>>> make[3]: Leaving directory
>>> `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
>>> make[2]: *** [default] Error 2
>>> make[2]: Leaving directory
>>> `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
>>> make[1]: *** [all] Error 2
>>> make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
>>> make: *** [default] Error 2
>>>
>>> It's unclear that adding this would cause a lot of extra work; the
>>> patches that need to be applied are quite few - a tribute to the
>>> design work!
>>
>> That's weird. Here, it compiles fine against my 2.6.32 kernel, as there's a
>> patch that removes the extra parameter. I'll double check and add a fix
>> if I found something wrong.
> 
> I think a couple of modules may have been missed;
> $ cd media_build
> $ grep -rl i2c_new_probed_device v4l | grep -v .o
> v4l/cx23885-i2c.c
> v4l/bttv-input.c
> v4l/cx88-input.c
> v4l/ivtv-i2c.c
> v4l/hdpvr-i2c.c
> v4l/v4l2-common.c
> v4l/cx18-i2c.c
> v4l/em28xx-cards.c
> 
> $ grep +++ backports/v2.6.35_i2c_new_probed_device.patch
> +++ b/drivers/media/video/bt8xx/bttv-input.c    Tue Oct 26 14:17:09 2010 -0200
> +++ b/drivers/media/video/cx18/cx18-i2c.c       Tue Oct 26 14:17:09 2010 -0200
> +++ b/drivers/media/video/cx23885/cx23885-i2c.c Tue Oct 26 14:17:09 2010 -0200
> +++ b/drivers/media/video/em28xx/em28xx-cards.c Tue Oct 26 14:17:09 2010 -0200
> +++ b/drivers/media/video/ivtv/ivtv-i2c.c       Tue Oct 26 14:17:09 2010 -0200
> +++ b/drivers/media/video/v4l2-common.c Tue Oct 26 14:17:09 2010 -0200
> +++ b/drivers/media/video/ivtv/ivtv-i2c.c       Tue Oct 26 23:18:52 2010 -0200
> 
> which on the face of it suggests
>   btty-input.c
>   cx88-input.c
>   hdpvr-i2c.c
> need looking at.
> 
> I get the same result whether building from a git clone of media-tree
> or via media_build/build.sh.
> 
> I am building against ubuntu 2.6.32-26-generic aka 2.6.32.24+drm33.11, on i386.
> I am using just their kernel-headers package for the build. Usually it works ok.

I have no time currently to touch on it, since I still have lots of patches to
take a look and submit for the merge window. So, if you have some time,
could you please prepare and submit a patch fixing it?

Thanks!
Mauro

Re: Debug code in HG repositories

[VDR User]

On Fri, Jan 7, 2011 at 1:06 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Have you tried Mauro's media_build tree? I had to use it today to test a
> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
> promote this more. I could add backwards compatibility builds to my daily
> build script that uses this in order to check for which kernel versions
> this compiles if there is sufficient interest.

I'd just like to note that I have been using the media_build daily
snapshots with much success.  IMO, it's about as close as you're going
to get to the old hg system.  As a (mostly) end-user, I am one of the
people unwilling to hassle with the entire git tree (kernel included),
but since the introduction of media_build, we're once again able to
test new code much like we did before.  I strongly urge any end-user
who hasn't given it a try, to do so.

Regards,
Derek

Re: Debug code in HG repositories

[Mauro Carvalho Chehab]

Em 07-01-2011 19:06, Hans Verkuil escreveu:
> On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
>> On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
>>> Hi guys,
>>>
>>> are you aware that there is a lot of '#if 0' code in the HG repositories
>>> which is not in GIT?
>>>
>>> When drivers were submitted to the kernel from HG, the '#if 0' stuff was
>>> stripped, unless it was marked as 'keep'...
>>>
>>> This was fine, when development was done with HG.
>>>
>>> As GIT is being used now, that code will be lost, as soon as the HG
>>> repositories have been removed...
>>>
>>> Any opinions how this should be handled?

Oliver,

There are some code there that it may make sense to bring back to -git and to
upstream, or to convert into some of the new kernel tracing facilities, but we
need to review them, as there are some codes inside the #if 0 that are simply 
dead code, where people were intending to use some alternative way to implement 
the driver, but gave up and just forgot to clean up the mess. Several of those
code don't even compile today, due to the kABI changes.

With respect to debug printk messages, I dunno if you've already used, but
dev_dbg() functions (and other similar ones) are very interesting: depending
on the way you compile your kernel, they're converted into dynamic_printk's, 
and they can be enabled/disabled via /sys/kernel/debug/. It is a way better than
just adding normal printk's, as you can tell the kernel to enable just the debug
message at some line.

For example:

$ cat /sys/kernel/debug/dynamic_debug/control |grep cx231xx
/home/v4l/new_build/v4l/cx231xx-input.c:93 [cx231xx]cx231xx_ir_init - "Trying to bind ir at bus %d, addr 0x%02x\012"
/home/v4l/new_build/v4l/cx231xx-input.c:57 [cx231xx]cx231xx_ir_init - "%s\012"
/home/v4l/new_build/v4l/cx231xx-input.c:45 [cx231xx]get_key_isdbt - "scancode = %02x\012"
/home/v4l/new_build/v4l/cx231xx-input.c:32 [cx231xx]get_key_isdbt - "%s\012"

by using:

# echo "file cx231xx-input.c +p" > /sys/kernel/debug/dynamic_debug/control

All the above debug lines will be enabled. You can do, instead:

# echo "file cx231xx-input.c line 45 +p" > /sys/kernel/debug/dynamic_debug/control

If you're interested just at the scancode printk line.

At least on the distros I use (RHEL6 and Fedora 14), dynamic printk support is enabled
by default on kernel, so, this is very useful to me, as I don't need to recompile
the entire kernel to test.

>>>
>>> CU
>>> Oliver
>>
>> I complained about this months ago.  The problem is that when we were
>> using HG, the HG repo was a complete superset of what went into Git
>> (including development/debug code).  But now that we use Git, neither
>> is a superset of the other.
>>
>> If you base your changes on Git, you have to add back in all the
>> portability code (and any "#if 0" you added as the maintainer for
>> development/debugging).  Oh, and regular users cannot test any of your
>> changes because they aren't willing to upgrade their entire kernel.
>>
>> If you base your changes on Hg, nothing merges cleanly when submitted
>> upstream so your patches get rejected.
>>
>> Want to know why we are seeing regressions all over the place?
>> Because *NOBODY* is testing the code until after the kernel goes
>> stable (since while many are willing to install a v4l-dvb tree, very
>> few will are willing to upgrade their entire kernel just to test one
>> driver).  We've probably lost about 98% of our user base of testers.
> 
> Have you tried Mauro's media_build tree? I had to use it today to test a
> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
> promote this more. I could add backwards compatibility builds to my daily
> build script that uses this in order to check for which kernel versions
> this compiles if there is sufficient interest.

I'm using it currently on most of my tests. I know that there are several
users using it.

>> Oh, and users have to git clone 500M+ of data, and not everybody in
>> the world has bandwidth fast enough to make that worth their time (it
>> took me several hours last time I did it).
> 
> Currently the media_build tree copies the drivers from a git tree. Which, as
> you say, can be a big problem for non-developers. But all it really needs are
> the media drivers. So perhaps it might be a good idea to make a daily snapshot
> of the drivers and make it available for download on linuxtv.org. That archive
> is only 3.5 MB, so much easier to download.

No, you don't need to have it. Have you looked at the build.sh script?
It downloads and compiles everything using the latest tarball from:
	http://linuxtv.org/downloads/drivers/
Currently, the archive has 3.3Mb. The tarball is updated when a change is
done on the latest development branch (It is still pointing to staging/for_v2.6.38,
as I didn't finish to add the backport to linux-next changes).

>> Anyway, I've beaten this horse to death and it's fallen on deaf ears.
>> Merge overhead has reached the point where it's just not worth my
>> time/effort to submit anything upstream anymore.
> 
> The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too
> much work. Any attempt to work from the hg tree is doomed. The media_build
> seems to be a viable alternative. As a developer you still have to go through
> the painful process of cloning the git repo, but it is a one time thing. Once
> it's cloned then you only have to follow the new commits, which is much, much
> faster.
> 
> And regarding regressions: I'm amazed how few regressions we have considering
> the furious rate of development. The media subsystem is still one of the most
> active subsystems in the kernel and probably will remain so for the forseeable
> future as well.
> 
> It would be a shame not to submit patches upstream, that never ends well in
> the long run.
> 
> With respect to '#if 0': for the most part I'd say: good riddance. In my
> many years of experience as a SW engineer I have never seen anyone actually
> turn on '#if 0' code once it's been in the code for more than, say, a year.
> Usually people just leave it there because they are too lazy to remove it,
> or they don't understand what it is for and are too scared to remove it.
> 
> If it is code partially implementing a feature that needs more work, then
> it may sound like a good idea to keep it. However, after it's in the code for
> more than a year, then nobody remembers what the code was about and what still
> had to be done to make it work. And it's hell to figure that out after such a
> long time. Never put such code in the mainline. Keep it in a branch if you
> have to.

This is the case of most #if 0 code. On a few drivers, it were used to turn on some
special debug messages. Btw, using #if 0 for debug is a bad practice, as some
upstream change may break it - Instead, it should do something like #if CONFIG_DEBUG_foo,
and having some Kconfig to allow enabling/disabling it.
> 
> Anyway, if there is some '#if 0' code that you want to preserve in git, then
> you have to make a patch to add it. But you probably will have to have very
> good reasons for adding '#if 0' code to the mainline.
> 
> Regards,
> 
> 	Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

[Jarod Wilson]

On Jan 7, 2011, at 3:13 PM, Devin Heitmueller wrote:

> On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
>> Hi guys,
>> 
>> are you aware that there is a lot of '#if 0' code in the HG repositories
>> which is not in GIT?
>> 
>> When drivers were submitted to the kernel from HG, the '#if 0' stuff was
>> stripped, unless it was marked as 'keep'...
>> 
>> This was fine, when development was done with HG.
>> 
>> As GIT is being used now, that code will be lost, as soon as the HG
>> repositories have been removed...
>> 
>> Any opinions how this should be handled?
>> 
>> CU
>> Oliver
> 
> I complained about this months ago.  The problem is that when we were
> using HG, the HG repo was a complete superset of what went into Git
> (including development/debug code).  But now that we use Git, neither
> is a superset of the other.
> 
> If you base your changes on Git, you have to add back in all the
> portability code (and any "#if 0" you added as the maintainer for
> development/debugging).  Oh, and regular users cannot test any of your
> changes because they aren't willing to upgrade their entire kernel.
> 
> If you base your changes on Hg, nothing merges cleanly when submitted
> upstream so your patches get rejected.
> 
> Want to know why we are seeing regressions all over the place?
> Because *NOBODY* is testing the code until after the kernel goes
> stable (since while many are willing to install a v4l-dvb tree, very
> few will are willing to upgrade their entire kernel just to test one
> driver).  We've probably lost about 98% of our user base of testers.

What Hans said re: media_build. I've been pointing quite a few people on
the mythtv-users mailing list in that direction for updated drivers on
top of their distro kernels.

Additionally, the current Fedora 14 kernels (which are 2.6.35.10-based)
carry a patchset developed using media_build with essentially the 2.6.38
rc1 snapshot code, so a fair number of Fedora users *are* testing this
code long before its in a stable upstream kernel release.


-- 
Jarod Wilson
jarod@wilsonet.com