Donau Help, Anyone could please help me to write a small application on donau for PAT filtering. -Sajjan -----Original Message----- From: linux-dvb-bounces@xxxxxxxxxxx [mailto:linux-dvb-bounces@xxxxxxxxxxx] On Behalf Of linux-dvb-request@xxxxxxxxxxx Sent: Monday, April 17, 2006 1:38 AM To: linux-dvb@xxxxxxxxxxx Subject: linux-dvb Digest, Vol 15, Issue 70 Send submissions to linux-dvb@xxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb or, via email, send a message with subject or body 'help' to linux-dvb-request@xxxxxxxxxxx You can reach the person managing the list at linux-dvb-owner@xxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of linux-dvb digest..." Today's Topics: 1. Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. (Manu Abraham) 2. Re: [PATCH/RFC] add dvb-s2 support to frontend.h and dvb_frontend.[h|c] (Alan Nisota) 3. Re: [PATCH/RFC] add dvb-s2 support to frontend.h and dvb_frontend.[h|c] (Philip Prindeville) 4. Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. (Andreas Oberritter) 5. Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. (CityK) 6. Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. (CityK) 7. Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. (Andreas Oberritter) 8. Moving tuner handling code to separate file. (Michael Krufky) 9. [PATCH] dst_ca: ca_info and application_info (Yaz Town) ---------------------------------------------------------------------- Message: 1 Date: Sun, 16 Apr 2006 16:29:09 +0400 From: Manu Abraham <abraham.manu@xxxxxxxxx> Subject: Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. To: Perceval Anichini <perceval.anichini@xxxxxxxxxxxxxxx> Cc: linux-dvb@xxxxxxxxxxx Message-ID: <44423895.4070208@xxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Perceval Anichini wrote: > Well, that's why I think 'tuner-' is indeed a quite reductive prefix > ... > > Maybe we shall have a single file by _chip_ then ??? > > For instance : > lnb-disecq/lnbp21.h > lnb-disecq/lnbp13.h > "sec/" might sound better, since who knows what might come later on .. > tuners/bsbe1.h > tuners/bsrv2.h > demod/stv0299.h > demod/... > > And then a frontend is the sum of a lnbp chip, a demod, a tuner : > exactly as in the DVB API documentation... ? > Sounds nice. The only problem is to get people to agree on such a huge change, eventhough cosmetic. It looks quite meaningful, atleast to myself. What about silicon tuners ? They have sec/(tuner)rf stages + pll /demod everything in one single chip. Then there are split ones, rf stage + pll in one chip, demod + sec in another Manu ------------------------------ Message: 2 Date: Sun, 16 Apr 2006 07:05:17 -0700 From: "Alan Nisota" <alannisota@xxxxxxxxx> Subject: Re: [PATCH/RFC] add dvb-s2 support to frontend.h and dvb_frontend.[h|c] To: "Marcel Siegert" <mws@xxxxxxxxxxx> Cc: linux-dvb@xxxxxxxxxxx Message-ID: <f5f2308d0604160705qd97fa0bqa290e624116a1b03@xxxxxxxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1 On 4/15/06, Alan Nisota <alannisota@xxxxxxxxx> wrote: > I made some assumptions about your intentions and completed the > implementation in dvb_frontend.c. I then finished off the driver, but > I haven't been able to test yet, as I still need to update mythtv to > support the new ioctls. After working on updating mythtv, I must admit that I am unhappy with the API extension for DVB-S2 that Marcel is proposing. The extended-info stuff is fine, and doesn't cause any issues, but the fact that dvb_parameters_new is not backwards compatible (the union is dynamically allocated) means that apps need to implement completely different code to implement the new API. Since they'll never be able to stop using the original dvb_parameters (how many years until 90% or more of the users have moved to a kernel newer than 2.6.18+?) all apps will either continue using the current api for already-supported protocols, and use the new ones only for the new protocols, or will have two entirely separate DVB implementations, so you are forcing a lot of additional work and maintenance headache on them. In myth specifically, the code becomes extremely ugly with many #ifdefs to support dvbs2. If dvbs2 had been added to dvb_parameters, or if dvb_parameters_new was backwards compatible, the numbers of these would drop significantly and it would be easy to switch to the new API if present for all methods without duplicating a huge amount of code. Also, I think deprecating dvb_parameters makes no sense to me. Since many apps won't support the new API, SET_FRONTEND and friends will be around for a long time. since the functions which implement that ioctl require dvb_parameters, I don't see a way to remove the calls. So all that deprecating it does is add lots of useless warnings to the kernel compile. Specifically for myth, if the current way is deployed, we could isolate anything that deals with dvb_parameters, and be able to switch between access functions, which would minimize the work required to support both APIs, and would make it possible to switch entirely to the new one, if it is available, without a lot of overhead This will, however, involve a rather substantial patch which would not otherwise be required. ------------------------------ Message: 3 Date: Sun, 16 Apr 2006 10:09:40 -0600 From: Philip Prindeville <philipp_subx@xxxxxxxxxxxxxxxxxxxxx> Subject: Re: [PATCH/RFC] add dvb-s2 support to frontend.h and dvb_frontend.[h|c] To: Alan Nisota <alannisota@xxxxxxxxx> Cc: linux-dvb@xxxxxxxxxxx Message-ID: <44426C44.2070401@xxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1 Alan Nisota wrote: >On 4/15/06, Alan Nisota <alannisota@xxxxxxxxx> wrote: > > >>The issue I have is >>that set_frontend is called from dvb_frontend_swzigzag_autotune and >>dvb_frontend_swzigzag both of which examine fepriv->parameters. Do >>you expect to update these functions to use fepriv->parameters_new (I >>assume so)? if so, how do you know when to use one vs the other? >> >> > >I made some assumptions about your intentions and completed the >implementation in dvb_frontend.c. I then finished off the driver, but >I haven't been able to test yet, as I still need to update mythtv to >support the new ioctls. > >I hope this is approximately what you intended. > >Index: v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.c >=================================================================== >--- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvb_frontend.c > 2006-04-15 13:07:55.000000000 -0700 >+++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.c >2006-04-15 13:07:47.000000000 -0700 >@@ -272,7 +272,7 @@ > /* are we using autoinversion? */ > autoinversion = ((!(fe->ops->info.caps & FE_CAN_INVERSION_AUTO)) && > ((fepriv->current_standard_set && >- fepriv->parameters_new.inversion == INVERSION_AUTO) ||; >+ fepriv->parameters_new.inversion == INVERSION_AUTO) >+ || > (! fepriv->current_standard_set && > fepriv->parameters.inversion == INVERSION_AUTO))); > >@@ -996,12 +996,22 @@ > break; > } > >+ if (fepriv->parameters_new.u) >+ kfree(fepriv->parameters_new.u); > > Isn't kfree() NULL-safe? Also, shouldn't the pointer be nulled out to avoid a double-free? Oh, never mind. You're about to overwrite the pointer lower down... >+ > castedparg = (struct dvb_frontend_parameters_new *)parg; > memcpy (&fepriv->parameters_new, parg, > sizeof (struct dvb_frontend_parameters_new)); > > Instead of sizeof (struct foo) you could also have sizeof(*parg) ... as long as parg isn't a pointer to a char. > memset(&fetunesettings, 0, sizeof(struct >dvb_frontend_tune_settings)); > > Ditto... but no point in changing this now to sizeof(fetunesettings)... >+ fepriv->parameters_new.u = (struct >frontend_parameters_union *) kmalloc(castedparg->size, GFP_KERNEL); >+ if ( !fepriv->parameters_new.u ) { >+ >+ err = -ENOMEM; >+ break; >+ } >+ memcpy(fepriv->parameters_new.u, castedparg->u, >castedparg->size); > /* be sure struct union pointer is set - even if it is NULL */ > fetunesettings.parameters_new.u = (struct >frontend_parameters_union *) kmalloc(castedparg->size, GFP_KERNEL); > if ( !fetunesettings.parameters_new.u ) { @@ -1066,7 >+1076,13 @@ > printk("dvb-core: FE_ATSC not handled yet.\n"); > break; > case FE_DVB_S2: >- printk("dvb-core: FE_DVB_S2 not >handled yet.\n"); >+ if (fepriv->current_standard != FE_DVB_S2) { >+ err = -EINVAL; >+ break; >+ } >+ fepriv->min_delay = HZ/20; > > Spaces around "/". >+ fepriv->step_size = >fepriv->parameters_new.u->qpsk2.symbol_rate / 16000; >+ fepriv->max_drift = >fepriv->parameters_new.u->qpsk2.symbol_rate / 2000; > break; > > } > > ------------------------------ Message: 4 Date: Sun, 16 Apr 2006 18:11:11 +0200 From: Andreas Oberritter <obi@xxxxxxxxxxx> Subject: Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. To: Manu Abraham <abraham.manu@xxxxxxxxx> Cc: linux-dvb <linux-dvb@xxxxxxxxxxx> Message-ID: <44426C9F.4020303@xxxxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Manu Abraham wrote: > Since FE == NIM, why should a change to "NIM_*" be important (but > rather it is just a cosmetic change which yields yet another level of > confusion), any specific reason you have, considering everywhere else > in the API it is "FE_*" ? I never said it was important, it's just an example for a prefix. Choose whatever you like, I don't really care. This is how the manufacturers call RF modules: Alps: Digital Tuner Broadcom: NIM Intel (Zarlink): NIM, front-end device Philips: NIM Samsung: NIM Sharp: Front-End Unit ST: NIM Regards, Andreas ------------------------------ Message: 5 Date: Sun, 16 Apr 2006 14:08:17 -0400 From: CityK <CityK@xxxxxxxxxx> Subject: Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. To: linux-dvb@xxxxxxxxxxx Message-ID: <44428811.1050800@xxxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1 Manu Abraham wrote: > > Andreas Oberritter wrote: > >> >> Manu Abraham wrote: >> >> >> >>> >>> Andreas Oberritter wrote: >>> >>> >>> >>>> >>>> Btw. such a change has been proposed by me last summer and >>>> >>>> Johannes suggested using a common prefix like "fe-" although >>>> >>>> I'd vote for using "nim_". >>>> >>>> >>>> >>> >>> generally, the demod is called a NIM, and the entire tuner is >>> >>> called the frontend. >>> >>> I think the "fe_" sounds more appropriate. >>> >>> >>> >> >> >> >> You're wrong. A NIM is the complete module. >> >> >> >> >> > > > > Ah, thanks for correcting it. Since FE == NIM, why should a change > > to "NIM_*" be important (but rather it is just a cosmetic change > > which yields yet another level of confusion), any specific reason > > you have, considering everywhere else in the API it is "FE_*" ? > This may end up as being a duplicate, so apologies in advance, but presently it doesn't appear my initial reply made it through. Anyways, here she be again (albeit with the benefit of some minor word choice & grammatical updates): While a NIM is a complete frontend, a frontend need not be a NIM. A NIM includes the tuner + demodulator(s) on its PCB (Hence, why they are also known, but less commonly, as ITD; integrated tuner demodulators). And this also explains the "M" portion of NIM; being a module, they are essentially a drop in frontend that can be integrated into a device -- whether it be a STB, pc card ... Examples of cards that don't use a NIM are the Fusion 3's and the pcHDTV HD-3000 --- they use an analog frontend in conjunction with an external digital demodulator. ...it is this combination that constitutes the complete frontend for these cards. ------------------------------ Message: 6 Date: Sun, 16 Apr 2006 13:46:04 -0400 From: CityK <CityK@xxxxxxxxxx> Subject: Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. Cc: linux-dvb <linux-dvb@xxxxxxxxxxx> Message-ID: <444282DC.2080709@xxxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1 Manu Abraham wrote: > Andreas Oberritter wrote: >> Manu Abraham wrote: >> >>> Andreas Oberritter wrote: >>> >>>> Btw. such a change has been proposed by me last summer and Johannes >>>> suggested using a common prefix like "fe-" although I'd vote for >>>> using "nim_". >>>> >>> generally, the demod is called a NIM, and the entire tuner is called >>> the frontend. >>> I think the "fe_" sounds more appropriate. >>> >> >> You're wrong. A NIM is the complete module. >> >> > > Ah, thanks for correcting it. Since FE == NIM, why should a change to > "NIM_*" be important (but rather it is just a cosmetic change which > yields yet another level of confusion), any specific reason you have, > considering everywhere else in the API it is "FE_*" ? While a NIM is a complete frontend, a frontend need not be a NIM. A NIM includes the tuner + demodulator(s) on its PCB (Hence, why they are also known, but less commonly, as ITD; integrated tuner demodulators). And this explains the "M" portion of NIM; being a module, they are essentially a drop in frontend that can be integrated into a device -- whether it be a STB, pc card ... Examples of cards that don't use a NIM are the Fusion 3's and the pcHDTV HD-3000 --- which use an analog frontend in conjunction with an external digital demodulator. ...it is this combination that makes up the complete frontends for the cards. ------------------------------ Message: 7 Date: Sun, 16 Apr 2006 21:33:05 +0200 From: Andreas Oberritter <obi@xxxxxxxxxxx> Subject: Re: [PATCH] Moving ALPS BSRV2 tuner handling code to separate file. To: CityK <CityK@xxxxxxxxxx> Cc: linux-dvb@xxxxxxxxxxx Message-ID: <44429BF1.9010502@xxxxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed CityK wrote: > While a NIM is a complete frontend, a frontend need not be a NIM. > > A NIM includes the tuner + demodulator(s) on its PCB (Hence, why they > are also known, but less commonly, as ITD; integrated tuner > demodulators). And this also explains the "M" portion of NIM; being a > module, they are essentially a drop in frontend that can be integrated > into a device -- whether it be a STB, pc card ... You're right. But that's the point: These modules are used on a lot of different boards, but every board has its own (almost identical) implementation of the module specific code. This code shall be factored out to have only a single implementation for each type of NIM in the kernel source tree. Other boards, which don't use NIMs, need custom settings anyway. There is no need and no gain to factor out their PLL setting code or special register settings. Their code just stays inside the adapter driver, because it won't be reused for other boards. Regards, Andreas ------------------------------ Message: 8 Date: Sun, 16 Apr 2006 15:50:02 -0400 From: Michael Krufky <mkrufky@xxxxxxx> Subject: Moving tuner handling code to separate file. To: linux-dvb@xxxxxxxxxxx Message-ID: <44429FEA.7020604@xxxxxxx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Andreas Oberritter wrote: > You're right. But that's the point: These modules are used on a lot of > different boards, but every board has its own (almost identical) > implementation of the module specific code. This code shall be > factored out to have only a single implementation for each type of NIM > in the kernel source tree. > > Other boards, which don't use NIMs, need custom settings anyway. There > is no need and no gain to factor out their PLL setting code or special > register settings. Their code just stays inside the adapter driver, > because it won't be reused for other boards. Is this what you have in mind? http://linuxtv.org/hg/~mkrufky/lgh06xf The config structs are device-specific, and are different in each implementation, so I left those where they were in the card drivers. This series moves all of the common pll_set code into a single header. I went with the "fe_foo.h" naming. I think this is what we've all settled on. If this is what we want, then someone please give me an ack and I'll include it on my hg pull request to Mauro. We should also commit Percival's patch renamed to fe_foo as well as renaming the others. I'll be happy to go ahead and do so if we can display that a consensus has been reached on this. Even if we decide on a better method later, doing this now is still better than the current duplication. Cheers, Mike ------------------------------ Message: 9 Date: Sun, 16 Apr 2006 23:07:27 +0300 From: "Yaz Town" <yaztown@xxxxxxxxx> Subject: [PATCH] dst_ca: ca_info and application_info To: linux-dvb@xxxxxxxxxxx Message-ID: <757e2cf50604161307l4c7b8596sf2857d495699e8db@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="iso-8859-1" hi, i applied the patch by *Henrik* to fedora core 5 with kernel v. 2.6.16-1.2080_FC5. the whole system crashes anytime myth or any application tries to do anything with the card (Twinhan). I know its not the patch but something in the kernel its self. any help??? Yaztown -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.linuxtv.org/pipermail/linux-dvb/attachments/20060416/c49a72ef /attachment.htm ------------------------------ _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb End of linux-dvb Digest, Vol 15, Issue 70 ***************************************** The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
