* Debug code in HG repositories
@ 2011-01-07 19:53 Oliver Endriss
2011-01-07 20:13 ` Devin Heitmueller
0 siblings, 1 reply; 22+ messages in thread
From: Oliver Endriss @ 2011-01-07 19:53 UTC (permalink / raw)
To: linux-media
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/
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 19:53 Debug code in HG repositories Oliver Endriss
@ 2011-01-07 20:13 ` Devin Heitmueller
2011-01-07 21:06 ` Hans Verkuil
2011-01-08 6:06 ` Jarod Wilson
0 siblings, 2 replies; 22+ messages in thread
From: Devin Heitmueller @ 2011-01-07 20:13 UTC (permalink / raw)
To: linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 20:13 ` Devin Heitmueller
@ 2011-01-07 21:06 ` Hans Verkuil
2011-01-07 23:42 ` Theodore Kilgore
` (4 more replies)
2011-01-08 6:06 ` Jarod Wilson
1 sibling, 5 replies; 22+ messages in thread
From: Hans Verkuil @ 2011-01-07 21:06 UTC (permalink / raw)
To: Devin Heitmueller; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 21:06 ` Hans Verkuil
@ 2011-01-07 23:42 ` Theodore Kilgore
2011-01-10 11:46 ` Mauro Carvalho Chehab
2011-01-07 23:56 ` Oliver Endriss
` (3 subsequent siblings)
4 siblings, 1 reply; 22+ messages in thread
From: Theodore Kilgore @ 2011-01-07 23:42 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 21:06 ` Hans Verkuil
2011-01-07 23:42 ` Theodore Kilgore
@ 2011-01-07 23:56 ` Oliver Endriss
2011-01-10 12:04 ` Mauro Carvalho Chehab
2011-01-08 1:02 ` Vincent McIntyre
` (2 subsequent siblings)
4 siblings, 1 reply; 22+ messages in thread
From: Oliver Endriss @ 2011-01-07 23:56 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Devin Heitmueller, linux-media
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/
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 21:06 ` Hans Verkuil
2011-01-07 23:42 ` Theodore Kilgore
2011-01-07 23:56 ` Oliver Endriss
@ 2011-01-08 1:02 ` Vincent McIntyre
2011-01-10 12:33 ` Mauro Carvalho Chehab
2011-01-08 4:08 ` VDR User
2011-01-10 11:27 ` Mauro Carvalho Chehab
4 siblings, 1 reply; 22+ messages in thread
From: Vincent McIntyre @ 2011-01-08 1:02 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Devin Heitmueller, linux-media
[-- 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 --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 21:06 ` Hans Verkuil
` (2 preceding siblings ...)
2011-01-08 1:02 ` Vincent McIntyre
@ 2011-01-08 4:08 ` VDR User
2011-01-10 11:27 ` Mauro Carvalho Chehab
4 siblings, 0 replies; 22+ messages in thread
From: VDR User @ 2011-01-08 4:08 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 20:13 ` Devin Heitmueller
2011-01-07 21:06 ` Hans Verkuil
@ 2011-01-08 6:06 ` Jarod Wilson
1 sibling, 0 replies; 22+ messages in thread
From: Jarod Wilson @ 2011-01-08 6:06 UTC (permalink / raw)
To: Devin Heitmueller; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 21:06 ` Hans Verkuil
` (3 preceding siblings ...)
2011-01-08 4:08 ` VDR User
@ 2011-01-10 11:27 ` Mauro Carvalho Chehab
4 siblings, 0 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2011-01-10 11:27 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 23:42 ` Theodore Kilgore
@ 2011-01-10 11:46 ` Mauro Carvalho Chehab
2011-01-10 13:05 ` Johannes Stezenbach
2011-01-10 22:00 ` Theodore Kilgore
0 siblings, 2 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2011-01-10 11:46 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Hans Verkuil, Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-07 23:56 ` Oliver Endriss
@ 2011-01-10 12:04 ` Mauro Carvalho Chehab
2011-01-10 12:27 ` Mauro Carvalho Chehab
2011-01-11 1:10 ` Oliver Endriss
0 siblings, 2 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2011-01-10 12:04 UTC (permalink / raw)
To: linux-media; +Cc: Oliver Endriss, Hans Verkuil, Devin Heitmueller
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:
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-10 12:04 ` Mauro Carvalho Chehab
@ 2011-01-10 12:27 ` Mauro Carvalho Chehab
2011-01-11 1:20 ` Oliver Endriss
2011-01-11 1:10 ` Oliver Endriss
1 sibling, 1 reply; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2011-01-10 12:27 UTC (permalink / raw)
To: linux-media
Cc: Oliver Endriss, Hans Verkuil, Devin Heitmueller,
Jean-Francois Moine, Hans de Goede
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-08 1:02 ` Vincent McIntyre
@ 2011-01-10 12:33 ` Mauro Carvalho Chehab
2011-01-11 10:37 ` Vincent McIntyre
2011-01-11 10:47 ` Vincent McIntyre
0 siblings, 2 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2011-01-10 12:33 UTC (permalink / raw)
To: Vincent McIntyre; +Cc: Hans Verkuil, Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-10 11:46 ` Mauro Carvalho Chehab
@ 2011-01-10 13:05 ` Johannes Stezenbach
2011-01-10 22:00 ` Theodore Kilgore
1 sibling, 0 replies; 22+ messages in thread
From: Johannes Stezenbach @ 2011-01-10 13:05 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Theodore Kilgore, Hans Verkuil, Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-10 11:46 ` Mauro Carvalho Chehab
2011-01-10 13:05 ` Johannes Stezenbach
@ 2011-01-10 22:00 ` Theodore Kilgore
1 sibling, 0 replies; 22+ messages in thread
From: Theodore Kilgore @ 2011-01-10 22:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-10 12:04 ` Mauro Carvalho Chehab
2011-01-10 12:27 ` Mauro Carvalho Chehab
@ 2011-01-11 1:10 ` Oliver Endriss
2011-04-03 13:40 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 22+ messages in thread
From: Oliver Endriss @ 2011-01-11 1:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media, Hans Verkuil, Devin Heitmueller
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/
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-10 12:27 ` Mauro Carvalho Chehab
@ 2011-01-11 1:20 ` Oliver Endriss
0 siblings, 0 replies; 22+ messages in thread
From: Oliver Endriss @ 2011-01-11 1:20 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: linux-media, Hans Verkuil, Devin Heitmueller,
Jean-Francois Moine, Hans de Goede
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/
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-10 12:33 ` Mauro Carvalho Chehab
@ 2011-01-11 10:37 ` Vincent McIntyre
2011-01-11 16:21 ` Mauro Carvalho Chehab
2011-01-11 10:47 ` Vincent McIntyre
1 sibling, 1 reply; 22+ messages in thread
From: Vincent McIntyre @ 2011-01-11 10:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-10 12:33 ` Mauro Carvalho Chehab
2011-01-11 10:37 ` Vincent McIntyre
@ 2011-01-11 10:47 ` Vincent McIntyre
2011-01-11 16:26 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 22+ messages in thread
From: Vincent McIntyre @ 2011-01-11 10:47 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-11 10:37 ` Vincent McIntyre
@ 2011-01-11 16:21 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2011-01-11 16:21 UTC (permalink / raw)
To: Vincent McIntyre; +Cc: Hans Verkuil, Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-11 10:47 ` Vincent McIntyre
@ 2011-01-11 16:26 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2011-01-11 16:26 UTC (permalink / raw)
To: Vincent McIntyre; +Cc: Hans Verkuil, Devin Heitmueller, linux-media
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Debug code in HG repositories
2011-01-11 1:10 ` Oliver Endriss
@ 2011-04-03 13:40 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2011-04-03 13:40 UTC (permalink / raw)
To: linux-media; +Cc: Oliver Endriss, Hans Verkuil, Devin Heitmueller
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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2011-04-03 13:40 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-07 19:53 Debug code in HG repositories Oliver Endriss
2011-01-07 20:13 ` Devin Heitmueller
2011-01-07 21:06 ` Hans Verkuil
2011-01-07 23:42 ` Theodore Kilgore
2011-01-10 11:46 ` Mauro Carvalho Chehab
2011-01-10 13:05 ` Johannes Stezenbach
2011-01-10 22:00 ` Theodore Kilgore
2011-01-07 23:56 ` Oliver Endriss
2011-01-10 12:04 ` Mauro Carvalho Chehab
2011-01-10 12:27 ` Mauro Carvalho Chehab
2011-01-11 1:20 ` Oliver Endriss
2011-01-11 1:10 ` Oliver Endriss
2011-04-03 13:40 ` Mauro Carvalho Chehab
2011-01-08 1:02 ` Vincent McIntyre
2011-01-10 12:33 ` Mauro Carvalho Chehab
2011-01-11 10:37 ` Vincent McIntyre
2011-01-11 16:21 ` Mauro Carvalho Chehab
2011-01-11 10:47 ` Vincent McIntyre
2011-01-11 16:26 ` Mauro Carvalho Chehab
2011-01-08 4:08 ` VDR User
2011-01-10 11:27 ` Mauro Carvalho Chehab
2011-01-08 6:06 ` Jarod Wilson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.