Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Patrick Boettcher wrote: > Hi Mauro, > > On Sat, 5 Dec 2009, Mauro Carvalho Chehab wrote: > >> Patrick Boettcher wrote: >>> Hi Mauro, >>> >>> please pull from >>> >>> http://linuxtv.org/hg/~pb/v4l-dvb/ >>> >>> for the following changeset: >>> >>> DiB8090: Add the DiB0090 tuner driver and STK8096GP-board >>> >>> This is the adding support for the DiB809x-device you were asking 2 >>> weeks ago. If possible, please include it into the patches which will go >>> for 2.6.33 . >>> >>> This repo also includes the changesets which were in my previous pull >>> request. >>> >> Hi Patrick, >> >> In the last patch, checkpatch.pl returned: >> >> total: 134 errors, 220 warnings, 3291 lines checked >> >> Would it be possible to correct the CodingStyle errors on it? There >> are lots of >> comments that aren't following C99 specs. Also, some code is indented >> with 4 spaces, >> instead of tabs, making really hard to read the code, among several >> other codingstyle >> violations. > > I committed and pushed the patch from Olivier which fixes most of the > Codingstyle violations (all of them except 80 char/line). Thanks. > I didn't see them in the first place, because it seems the 'make commit' > does not use a built-in checkpatch.pl if it does not find one in > /usr/src . This is a new (maybe buggy) behaviour. Weird. I'll try to fix this issue when I have some time. > Still, if you take a look at dib0090.c you will find it odd. Why? > Because as usual the DiBcom drivers are generated from internal source > code by a script. This is done to keep in sync drivers in development > and Linux easier. If someone has a problem with the dib-drivers he > should contact DiBcom rather than trying to hack his solution > (especially when it's about performance or other reception related > problem) into the driver. It seems that the script has some troubles with big lines. There are several big lines that got a really weird format. > I'm sorry that the drivers delivered like that are ugly from the > artistic point-of-view, but that's the only way I have today to deliver > drivers at all. > > Please pull now from > > http://linuxtv.org/hg/~pb/v4l-dvb/ Done. Thanks! Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, On Sat, 5 Dec 2009, Mauro Carvalho Chehab wrote: Patrick Boettcher wrote: Hi Mauro, please pull from http://linuxtv.org/hg/~pb/v4l-dvb/ for the following changeset: DiB8090: Add the DiB0090 tuner driver and STK8096GP-board This is the adding support for the DiB809x-device you were asking 2 weeks ago. If possible, please include it into the patches which will go for 2.6.33 . This repo also includes the changesets which were in my previous pull request. Hi Patrick, In the last patch, checkpatch.pl returned: total: 134 errors, 220 warnings, 3291 lines checked Would it be possible to correct the CodingStyle errors on it? There are lots of comments that aren't following C99 specs. Also, some code is indented with 4 spaces, instead of tabs, making really hard to read the code, among several other codingstyle violations. I committed and pushed the patch from Olivier which fixes most of the Codingstyle violations (all of them except 80 char/line). I didn't see them in the first place, because it seems the 'make commit' does not use a built-in checkpatch.pl if it does not find one in /usr/src . This is a new (maybe buggy) behaviour. Still, if you take a look at dib0090.c you will find it odd. Why? Because as usual the DiBcom drivers are generated from internal source code by a script. This is done to keep in sync drivers in development and Linux easier. If someone has a problem with the dib-drivers he should contact DiBcom rather than trying to hack his solution (especially when it's about performance or other reception related problem) into the driver. I'm sorry that the drivers delivered like that are ugly from the artistic point-of-view, but that's the only way I have today to deliver drivers at all. Please pull now from http://linuxtv.org/hg/~pb/v4l-dvb/ best regards, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Patrick Boettcher wrote: > Hi Mauro, > > please pull from > > http://linuxtv.org/hg/~pb/v4l-dvb/ > > for the following changeset: > > DiB8090: Add the DiB0090 tuner driver and STK8096GP-board > > This is the adding support for the DiB809x-device you were asking 2 > weeks ago. If possible, please include it into the patches which will go > for 2.6.33 . > > This repo also includes the changesets which were in my previous pull > request. > Hi Patrick, In the last patch, checkpatch.pl returned: total: 134 errors, 220 warnings, 3291 lines checked Would it be possible to correct the CodingStyle errors on it? There are lots of comments that aren't following C99 specs. Also, some code is indented with 4 spaces, instead of tabs, making really hard to read the code, among several other codingstyle violations. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi, in addition there is now: DiB0070: Update to latest internal release DiB0070: Indenting driver with indent -linux DiB8000: added support for DiBcom ISDB-T/ISDB-Tsb demodulator DiB8000 DiB0700: add support for STK807XP and STK807XPVR regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ On Fri, 14 Aug 2009, Patrick Boettcher wrote: Hi Mauro, can you please pull from http://linuxtv.org/hg/~pb/v4l-dvb/ for - ISDB-T: add mapping of LAYER_ENABLED to frontend-cache - ISDB-T: added reference to ARIB TR-B14 - ISDB-T: added bandwidth as an optional parameter - ISDB-T: Added note about DTV_FREQUENCY - DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1) In addition to that I have an ISDB-T demodulator driver ready (including device-support of course) and have modified 'scan' in dvb-apps to use the interface to scan for ISDB-T channels (can be used as an example showing how to tune ISDB-T) I'm looking forward to issue a pull request for that as well, but first I would like to have the API merged. I'm aware that the RFC was quite silent (thanks to Mike and Akihiro for commenting) - I'm taking that as a "no-objection" on the current implementation. I think binary compatibity is not broken, so applications compiled for DVB API 5.0 will continue to work without problems. I think that the 3 months from now on are enough time to fix up possibly bad things before a next kernel release (2.6.32). A pull would also widen the testers range, which I'm strongly depending on. thanks, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Em Mon, 15 Jun 2009 14:56:39 +0200 (CEST) Patrick Boettcher escreveu: > Hi Mauro, > > On Mon, 15 Jun 2009, Mauro Carvalho Chehab wrote: > > > Em Thu, 11 Jun 2009 15:35:14 -0700 (PDT) > > Trent Piepho escreveu: > > > >> On Thu, 11 Jun 2009, Patrick Boettcher wrote: > >>> On Wed, 27 May 2009, Trent Piepho wrote: > On Tue, 26 May 2009, Patrick Boettcher wrote: > Does this patch to fix these problems look ok? > >>> > >>> In fact, everything looks correct in my eyes. I'll ask Mauro to pull any > >>> minute from now. > >>> > >>> I even have an explaination why the failing attach of the itd1000 was > >>> not errored out: when I did the development I was using a userspace > >>> proprietary driver to validate, for that I needed the demod to be > >>> attached... > >>> > >>> Thanks for cleaning up this mess. > >> > >> Now that that patch is done, here is the rest of the series with dvb-pll > >> conversions. There is an additional patch to the flexcop card detecting > >> code. The #if defined(CONFIG_...) stuff didn't take into account code > >> being compiled into the kernel. > >> > >> Here's the series: > >> > >> 01/08: dvb-pll: Add Samsung TDTC9251DH0 DVB-T NIM > >> http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3d148fee550b > >> > >> 02/08: dvb-pll: Add support for Samsung TBDU18132 DVB-S NIM > >> http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=5a8e32e94aa7 > >> > >> 03/08: dvb-pll: Add support for Samsung TBMU24112 DVB-S NIM > >> http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c28394056a5a > >> > >> 04/08: dvb-pll: Add support for Alps TDEE4 DVB-C NIM > >> http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=90f54e498f90 > >> > >> 05/08: b2c2: fix frontends compiled into kernel > >> http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=748c762fcf3e > >> > >> 06/08: b2c2: Use dvb-pll for AirStar DVB-T's tuner > >> http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=fcacc65753f1 > >> > >> 07/08: b2c2: Use dvb-pll for Skystar2 rev 2.3 and rev 2.6 > >> http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=8ef37f1432e6 > >> > >> 08/08: b2c2: Use dvb-pll for Cablestar2 > >> http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=01fd4e3bd1c0 > > > > Nice patches. Are those tested with real cards? > > > > In particular, I loved this: > > > > +/* Can we use the specified front-end? Remember that if we are compiled > > + * into the kernel we can't call code that's in modules. */ > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > IMO, you should add it on a dvb core header. Then, a cleanup patch would be > > to > > simplify all those frontend tests all over all the dvb drivers code. > > > > Patrick, > > > > I think you have some skystar boards. I'd appreciate if you can review > > those patches before applying it. > > The only card I use which is using DVB_PLL (now) is the Airstar DVB-T. So > we need to take some risks and apply to force users to test :). I will ask > some users I know. > > However I won't be able to commit nor test anything before 3.5 weeks > from now. Hmm... this will be outside the merge window... I think I'll merge it on our tree after sending the first pull request for 2.6.30 (probably later today), in order to cook it for a while at the main tree before merging it. It would be nice if you can ask those users to test it asap, in order to get it tested during this week. Otherwise, we'll need to postpone this to 2.6.31. > > regards, > Patrick. > > -- >Mail: patrick.boettc...@desy.de >WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, On Mon, 15 Jun 2009, Mauro Carvalho Chehab wrote: Em Thu, 11 Jun 2009 15:35:14 -0700 (PDT) Trent Piepho escreveu: On Thu, 11 Jun 2009, Patrick Boettcher wrote: On Wed, 27 May 2009, Trent Piepho wrote: On Tue, 26 May 2009, Patrick Boettcher wrote: Does this patch to fix these problems look ok? In fact, everything looks correct in my eyes. I'll ask Mauro to pull any minute from now. I even have an explaination why the failing attach of the itd1000 was not errored out: when I did the development I was using a userspace proprietary driver to validate, for that I needed the demod to be attached... Thanks for cleaning up this mess. Now that that patch is done, here is the rest of the series with dvb-pll conversions. There is an additional patch to the flexcop card detecting code. The #if defined(CONFIG_...) stuff didn't take into account code being compiled into the kernel. Here's the series: 01/08: dvb-pll: Add Samsung TDTC9251DH0 DVB-T NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3d148fee550b 02/08: dvb-pll: Add support for Samsung TBDU18132 DVB-S NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=5a8e32e94aa7 03/08: dvb-pll: Add support for Samsung TBMU24112 DVB-S NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c28394056a5a 04/08: dvb-pll: Add support for Alps TDEE4 DVB-C NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=90f54e498f90 05/08: b2c2: fix frontends compiled into kernel http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=748c762fcf3e 06/08: b2c2: Use dvb-pll for AirStar DVB-T's tuner http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=fcacc65753f1 07/08: b2c2: Use dvb-pll for Skystar2 rev 2.3 and rev 2.6 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=8ef37f1432e6 08/08: b2c2: Use dvb-pll for Cablestar2 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=01fd4e3bd1c0 Nice patches. Are those tested with real cards? In particular, I loved this: +/* Can we use the specified front-end? Remember that if we are compiled + * into the kernel we can't call code that's in modules. */ +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) IMO, you should add it on a dvb core header. Then, a cleanup patch would be to simplify all those frontend tests all over all the dvb drivers code. Patrick, I think you have some skystar boards. I'd appreciate if you can review those patches before applying it. The only card I use which is using DVB_PLL (now) is the Airstar DVB-T. So we need to take some risks and apply to force users to test :). I will ask some users I know. However I won't be able to commit nor test anything before 3.5 weeks from now. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Em Thu, 11 Jun 2009 15:35:14 -0700 (PDT) Trent Piepho escreveu: > On Thu, 11 Jun 2009, Patrick Boettcher wrote: > > On Wed, 27 May 2009, Trent Piepho wrote: > > > On Tue, 26 May 2009, Patrick Boettcher wrote: > > > Does this patch to fix these problems look ok? > > > > In fact, everything looks correct in my eyes. I'll ask Mauro to pull any > > minute from now. > > > > I even have an explaination why the failing attach of the itd1000 was > > not errored out: when I did the development I was using a userspace > > proprietary driver to validate, for that I needed the demod to be > > attached... > > > > Thanks for cleaning up this mess. > > Now that that patch is done, here is the rest of the series with dvb-pll > conversions. There is an additional patch to the flexcop card detecting > code. The #if defined(CONFIG_...) stuff didn't take into account code > being compiled into the kernel. > > Here's the series: > > 01/08: dvb-pll: Add Samsung TDTC9251DH0 DVB-T NIM > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3d148fee550b > > 02/08: dvb-pll: Add support for Samsung TBDU18132 DVB-S NIM > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=5a8e32e94aa7 > > 03/08: dvb-pll: Add support for Samsung TBMU24112 DVB-S NIM > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c28394056a5a > > 04/08: dvb-pll: Add support for Alps TDEE4 DVB-C NIM > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=90f54e498f90 > > 05/08: b2c2: fix frontends compiled into kernel > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=748c762fcf3e > > 06/08: b2c2: Use dvb-pll for AirStar DVB-T's tuner > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=fcacc65753f1 > > 07/08: b2c2: Use dvb-pll for Skystar2 rev 2.3 and rev 2.6 > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=8ef37f1432e6 > > 08/08: b2c2: Use dvb-pll for Cablestar2 > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=01fd4e3bd1c0 Nice patches. Are those tested with real cards? In particular, I loved this: +/* Can we use the specified front-end? Remember that if we are compiled + * into the kernel we can't call code that's in modules. */ +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) IMO, you should add it on a dvb core header. Then, a cleanup patch would be to simplify all those frontend tests all over all the dvb drivers code. Patrick, I think you have some skystar boards. I'd appreciate if you can review those patches before applying it. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
On Thu, 11 Jun 2009, Patrick Boettcher wrote: > On Wed, 27 May 2009, Trent Piepho wrote: > > On Tue, 26 May 2009, Patrick Boettcher wrote: > > Does this patch to fix these problems look ok? > > In fact, everything looks correct in my eyes. I'll ask Mauro to pull any > minute from now. > > I even have an explaination why the failing attach of the itd1000 was > not errored out: when I did the development I was using a userspace > proprietary driver to validate, for that I needed the demod to be > attached... > > Thanks for cleaning up this mess. Now that that patch is done, here is the rest of the series with dvb-pll conversions. There is an additional patch to the flexcop card detecting code. The #if defined(CONFIG_...) stuff didn't take into account code being compiled into the kernel. Here's the series: 01/08: dvb-pll: Add Samsung TDTC9251DH0 DVB-T NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3d148fee550b 02/08: dvb-pll: Add support for Samsung TBDU18132 DVB-S NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=5a8e32e94aa7 03/08: dvb-pll: Add support for Samsung TBMU24112 DVB-S NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c28394056a5a 04/08: dvb-pll: Add support for Alps TDEE4 DVB-C NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=90f54e498f90 05/08: b2c2: fix frontends compiled into kernel http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=748c762fcf3e 06/08: b2c2: Use dvb-pll for AirStar DVB-T's tuner http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=fcacc65753f1 07/08: b2c2: Use dvb-pll for Skystar2 rev 2.3 and rev 2.6 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=8ef37f1432e6 08/08: b2c2: Use dvb-pll for Cablestar2 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=01fd4e3bd1c0 b2c2/flexcop-fe-tuner.c | 283 +++- frontends/dvb-pll.c | 75 frontends/dvb-pll.h |4 3 files changed, 172 insertions(+), 190 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Trent, On Wed, 27 May 2009, Trent Piepho wrote: On Tue, 26 May 2009, Patrick Boettcher wrote: MHz to 161 Mhz as welll as 439-447 MHz. Probably wrong. My guess is the data sheet says, "low band 48 to 154 MHz, mid band 161 MHz to 439 MHz, etc.," where 154 is the frequency of the last channel in the low band and 161 is the first channel in the mid band. Then someone translated this to code without really understanding what's going on. It should probably be: if (params->frequency > 44300) bs = 0x08; else if (params->frequency > 15750) bs = 0x0a; elsebs = 0x09; The tuner's limits should already be enforced elsewhere. Or just convert this to use dvb_pll. Thanks for pointing this out, can you please provide a patch for that? Preferably for the dvb_pll-solution? I've done this, but found some more mistakes in the flexcop code wrt frontend attachment. In patch 7469 you changed a failure path "dvb_frontend_detach(fc->fe)" into a "fc->fe->ops->release(fc->fe)", which isn't correct. There is more stuff dvb_frontend_detach() does besides call the main release method. The various attach functions in flexcop-fe-tuner don't return success/fail, which is a problem when frontend attachment partially fails. For instance if mt352 attachment works but dvb-pll attachment then fails the driver will think everything is ok because fc->fe is non-NULL, but the tuner will not work. It makes more sense to consider this an error and clean up. There are a couple other places where frontend attachment can partially fail where I wasn't entirely sure what's right. In skystar2_rev27_attach(), after the s5h1420 demod is attached, attachment of a ISL6421 LNB and ITD1000 tuner is attempted. If these fail an error message is printed but the rest of the code will consider the frontend to be successfully attached. Can the frontend work if the ISL6421 or ITD1000 didn't attach (which can happen if the driver isn't present even if the hardware is fine)? I'm guessing not and called these cases an error. If it's not an error, then the err() printout should probably be warning or info level. Does this patch to fix these problems look ok? In fact, everything looks correct in my eyes. I'll ask Mauro to pull any minute from now. I even have an explaination why the failing attach of the itd1000 was not errored out: when I did the development I was using a userspace proprietary driver to validate, for that I needed the demod to be attached... Thanks for cleaning up this mess. best regards, Patrick. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
On Tue, 26 May 2009, Patrick Boettcher wrote:
> > MHz to 161 Mhz as welll as 439-447 MHz. Probably wrong. My guess is the
> > data sheet says, "low band 48 to 154 MHz, mid band 161 MHz to 439 MHz,
> > etc.," where 154 is the frequency of the last channel in the low band and
> > 161 is the first channel in the mid band. Then someone translated this to
> > code without really understanding what's going on. It should probably be:
> >
> > if (params->frequency > 44300) bs = 0x08;
> > else if (params->frequency > 15750) bs = 0x0a;
> > elsebs = 0x09;
> >
> > The tuner's limits should already be enforced elsewhere. Or just convert
> > this to use dvb_pll.
>
> Thanks for pointing this out, can you please provide a patch for that?
> Preferably for the dvb_pll-solution?
I've done this, but found some more mistakes in the flexcop code wrt
frontend attachment.
In patch 7469 you changed a failure path "dvb_frontend_detach(fc->fe)" into
a "fc->fe->ops->release(fc->fe)", which isn't correct. There is more stuff
dvb_frontend_detach() does besides call the main release method.
The various attach functions in flexcop-fe-tuner don't return success/fail,
which is a problem when frontend attachment partially fails. For instance
if mt352 attachment works but dvb-pll attachment then fails the driver
will think everything is ok because fc->fe is non-NULL, but the tuner will
not work. It makes more sense to consider this an error and clean up.
There are a couple other places where frontend attachment can partially
fail where I wasn't entirely sure what's right. In
skystar2_rev27_attach(), after the s5h1420 demod is attached, attachment of
a ISL6421 LNB and ITD1000 tuner is attempted. If these fail an error
message is printed but the rest of the code will consider the frontend to
be successfully attached. Can the frontend work if the ISL6421 or ITD1000
didn't attach (which can happen if the driver isn't present even if the
hardware is fine)? I'm guessing not and called these cases an error. If
it's not an error, then the err() printout should probably be warning or
info level.
Does this patch to fix these problems look ok?
Maybe change "if (!i2c_tuner) return 0;" into "BUG_ON(!i2c_tuner);"?
In the case of a partial frontend attachment failure, should we keep
trying the rest of the frontends in the list or fail out early? This patch
does the former, but the latter could easily be done by adding a "break" to
the end of the "Clean up partially attached frontend" code block.
# HG changeset patch
# User Trent Piepho
# Date 1243476805 25200
# Node ID 27aa25fe54ae2fd9a166bfdb3cec4c4ecadc9cba
# Parent 480905f8768ce2e5b01da1c6d723cf95cf134d0b
b2c2: Fix problems with frontend attachment
From: Trent Piepho
The frontend attachment code didn't handle cases where the frontend
partially failed to attach. For instance, when the demod was attached
successfully but the tuner driver wasn't compiled or fails to init for some
reason. In these cases we try to clean up the partial attachment and fail
instead of proceeding with a broken frontend.
If frontend registration fails, clean up with dvb_frontend_detach() rather
than just calling the frontend's main release method. The former does some
additional stuff, like release an attached tuner and take care of putting
symbols when dynamic binding is used.
In skystar2_rev23_attach() it's not necessary to set fc->dev_type, that
gets set before skystar2_rev23_attach() is called.
Priority: normal
Signed-off-by: Trent Piepho
diff -r 480905f8768c -r 27aa25fe54ae
linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Wed May 27 17:35:06
2009 -0700
+++ b/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Wed May 27 19:13:25
2009 -0700
@@ -175,23 +175,23 @@ static int skystar23_samsung_tbdu18132_t
return 0;
}
-static void skystar2_rev23_attach(struct flexcop_device *fc,
- struct i2c_adapter *i2c)
-{
- fc->fe = dvb_attach(mt312_attach,
- &skystar23_samsung_tbdu18132_config, i2c);
+static int skystar2_rev23_attach(struct flexcop_device *fc,
+ struct i2c_adapter *i2c)
+{
+ fc->fe = dvb_attach(mt312_attach, &skystar23_samsung_tbdu18132_config,
i2c);
if (fc->fe != NULL) {
struct dvb_frontend_ops *ops = &fc->fe->ops;
- ops->tuner_ops.set_params \
- = skystar23_samsung_tbdu18132_tuner_set_params;
+ ops->tuner_ops.set_params =
+ skystar23_samsung_tbdu18132_tuner_set_params;
ops->diseqc_send_master_cmd = flexcop_diseqc_send_master_cmd;
ops->diseqc_send_burst = flexcop_diseqc_send_burst;
ops->set_tone = flexcop_set_tone;
ops->set_voltage= flexcop_set_voltage;
fc->fe_sleep= ops->sleep;
op
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Trent, On Mon, 25 May 2009, Trent Piepho wrote: On Mon, 25 May 2009, Mauro Carvalho Chehab wrote: + if (params->frequency >= 4800 && params->frequency <= 15400) \ + bs = 0x09; + if (params->frequency >= 16100 && params->frequency <= 43900) \ + bs = 0x0a; + if (params->frequency >= 44700 && params->frequency <= 86300) \ + bs = 0x08; Just remove the backslash. You don't need they. The original code has this, but bs will be zero for a frequency between 154 MHz to 161 Mhz as welll as 439-447 MHz. Probably wrong. My guess is the data sheet says, "low band 48 to 154 MHz, mid band 161 MHz to 439 MHz, etc.," where 154 is the frequency of the last channel in the low band and 161 is the first channel in the mid band. Then someone translated this to code without really understanding what's going on. It should probably be: if (params->frequency > 44300) bs = 0x08; else if (params->frequency > 15750) bs = 0x0a; elsebs = 0x09; The tuner's limits should already be enforced elsewhere. Or just convert this to use dvb_pll. Thanks for pointing this out, can you please provide a patch for that? Preferably for the dvb_pll-solution? There seems only to be a handful of users which are really knowing that they are using this card and this driver to receive DVB-C in Linux, so testing it will be hard, but most likely it's not needed. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, On Mon, 25 May 2009, Mauro Carvalho Chehab wrote: Em Wed, 20 May 2009 11:27:18 +0200 (CEST) Patrick Boettcher escreveu: Hi Mauro, please pull from my repository for hte following changesets: Committed, thanks. Yet, I saw a few minor issues on one of your patch. Please fix and submit me later a cleanup. - Rewrote frontend-attach mechanism to gain noise-less deactivation of submodules This patch do also a good CodingStyle fixes. That's good (although it is generally better to have the codingsyle specific changes on a separate patch). It wasn't me to do the codingstyle changes. I didn't see the \'s in diff and I actually don't know why I didn't see them. Thanks for the other comments, I'll take them into consideration. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
On Mon, 25 May 2009, Mauro Carvalho Chehab wrote: > > + if (params->frequency >= 4800 && params->frequency <= 15400) \ > + bs = 0x09; > + if (params->frequency >= 16100 && params->frequency <= 43900) > \ > + bs = 0x0a; > + if (params->frequency >= 44700 && params->frequency <= 86300) > \ > + bs = 0x08; > > Just remove the backslash. You don't need they. The original code has this, but bs will be zero for a frequency between 154 MHz to 161 Mhz as welll as 439-447 MHz. Probably wrong. My guess is the data sheet says, "low band 48 to 154 MHz, mid band 161 MHz to 439 MHz, etc.," where 154 is the frequency of the last channel in the low band and 161 is the first channel in the mid band. Then someone translated this to code without really understanding what's going on. It should probably be: if (params->frequency > 44300) bs = 0x08; else if (params->frequency > 15750) bs = 0x0a; elsebs = 0x09; The tuner's limits should already be enforced elsewhere. Or just convert this to use dvb_pll. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Em Wed, 20 May 2009 11:27:18 +0200 (CEST) Patrick Boettcher escreveu: > Hi Mauro, > > please pull from my repository for hte following changesets: Committed, thanks. Yet, I saw a few minor issues on one of your patch. Please fix and submit me later a cleanup. > - Rewrote frontend-attach mechanism to gain noise-less deactivation of > submodules This patch do also a good CodingStyle fixes. That's good (although it is generally better to have the codingsyle specific changes on a separate patch). However, in order to be CodingStyle compatible, you've sacrificed code readability into a few cases. For example: + struct i2c_adapter *i2c_tuner \ + = s5h1420_get_tuner_i2c_adapter(fc->fe); checkpatch.pl may not complain, but this is badly indented. Also, the backslash is needed only on macros. One alternative that would be correct, from codingstyle's perpective would be: + struct i2c_adapter *i2c_tuner = + 5h1420_get_tuner_i2c_adapter(fc->fe); The above is how 'indent' tool would have enforced 80 cols. To be honest, I don't like this either. If I haven't any alternative, I would just violate 80 cols. In this specific case, it is cleaner to break it into two statements: struct i2c_adapter *i2c_tuner; i2c_tuner = s5h1420_get_tuner_i2c_adapter(fc->fe); The optimizer will likely generate the same assembler for both, but the later is cleaner for humans. +/* 4 MHz = 4000 KHz */ This comment is pointless. You should just remove it. + ops->tuner_ops.set_params \ + = skystar23_samsung_tbdu18132_tuner_set_params; and + if (fc->fe != NULL) + fc->fe->ops.tuner_ops.set_params \ + = alps_tdee4_stv0297_tuner_set_params; + else + fc->fc_i2c_adap[0].no_base_addr = 0; In the above case, the better for now is to just violate the 80 cols warning. Unfortunately, we have the bad habit of using long names on some symbols, even when not needed. For example, instead of using alps_tdee4_stv0297_tuner_set_params, this name would be equally understood: alps_tdee4_stv0297_s_params; Also, fc->fe->ops.tuner_ops.set_params could be, instead: fc->fe->ops.tuner.s_params I have to say that ops.tuner_ops is redundant. + if (params->frequency >= 4800 && params->frequency <= 15400) \ + bs = 0x09; + if (params->frequency >= 16100 && params->frequency <= 43900) \ + bs = 0x0a; + if (params->frequency >= 44700 && params->frequency <= 86300) \ + bs = 0x08; Just remove the backslash. You don't need they. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, I added two more changed aiming 2.6.30: - Code cleanup (passes checkpatch now) of the b2c2-flexcop-drivers 1/2 - Code cleanup (passes checkpatch now) of the b2c2-flexcop-drivers 2/2 Please pull them along as well. Thanks, Patrick. On Sun, 29 Mar 2009, Patrick Boettcher wrote: Hi Mauro, can you please pull from my repository for two changes for the flexcop-devices: - Remove unecessary udelay - Fix i2c code of flexcop-driver for rare revisions The latter should be a bug-fix for 2.6.29, but I'm not sure whether it breaks support for another device. I think the 2.6.30 release time will reveal anything unwanted. best regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
