[linux-dvb] RE: linux-dvb Digest, Vol 15, Issue 70

sajjan.jyothi at wipro.com sajjan.jyothi at wipro.com
Mon Apr 17 08:52:01 CEST 2006


Donau Help,
   Anyone could please help me to write a small application on donau for
PAT filtering.
-Sajjan

-----Original Message-----
From: linux-dvb-bounces at linuxtv.org
[mailto:linux-dvb-bounces at linuxtv.org] On Behalf Of
linux-dvb-request at linuxtv.org
Sent: Monday, April 17, 2006 1:38 AM
To: linux-dvb at linuxtv.org
Subject: linux-dvb Digest, Vol 15, Issue 70

Send linux-dvb mailing list submissions to
	linux-dvb at linuxtv.org

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 at linuxtv.org

You can reach the person managing the list at
	linux-dvb-owner at linuxtv.org

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 at gmail.com>
Subject: Re: [linux-dvb] [PATCH] Moving ALPS BSRV2 tuner handling code
	to	separate file.
To: Perceval Anichini <perceval.anichini at streamvision.fr>
Cc: linux-dvb at linuxtv.org
Message-ID: <44423895.4070208 at gmail.com>
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 at gmail.com>
Subject: Re: [linux-dvb] [PATCH/RFC] add dvb-s2 support to frontend.h
	and	dvb_frontend.[h|c]
To: "Marcel Siegert" <mws at linuxtv.org>
Cc: linux-dvb at linuxtv.org
Message-ID:
	<f5f2308d0604160705qd97fa0bqa290e624116a1b03 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 4/15/06, Alan Nisota <alannisota at gmail.com> 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 at redfish-solutions.com>
Subject: Re: [linux-dvb] [PATCH/RFC] add dvb-s2 support to frontend.h
	and	dvb_frontend.[h|c]
To: Alan Nisota <alannisota at gmail.com>
Cc: linux-dvb at linuxtv.org
Message-ID: <44426C44.2070401 at redfish-solutions.com>
Content-Type: text/plain; charset=ISO-8859-1

Alan Nisota wrote:

>On 4/15/06, Alan Nisota <alannisota at gmail.com> 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 at linuxtv.org>
Subject: Re: [linux-dvb] [PATCH] Moving ALPS BSRV2 tuner handling code
	to	separate file.
To: Manu Abraham <abraham.manu at gmail.com>
Cc: linux-dvb <linux-dvb at linuxtv.org>
Message-ID: <44426C9F.4020303 at linuxtv.org>
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 at rogers.com>
Subject: Re: [linux-dvb] [PATCH] Moving ALPS BSRV2 tuner handling code
	to	separate file.
To: linux-dvb at linuxtv.org
Message-ID: <44428811.1050800 at rogers.com>
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 at rogers.com>
Subject: Re: [linux-dvb] [PATCH] Moving ALPS BSRV2 tuner handling code
	to	separate file.
Cc: linux-dvb <linux-dvb at linuxtv.org>
Message-ID: <444282DC.2080709 at rogers.com>
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 at linuxtv.org>
Subject: Re: [linux-dvb] [PATCH] Moving ALPS BSRV2 tuner handling code
	to	separate file.
To: CityK <CityK at rogers.com>
Cc: linux-dvb at linuxtv.org
Message-ID: <44429BF1.9010502 at linuxtv.org>
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 at m1k.net>
Subject: [linux-dvb] Moving tuner handling code to separate file.
To: linux-dvb at linuxtv.org
Message-ID: <44429FEA.7020604 at m1k.net>
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 at gmail.com>
Subject: [linux-dvb] [PATCH] dst_ca: ca_info and application_info
To: linux-dvb at linuxtv.org
Message-ID:
	<757e2cf50604161307l4c7b8596sf2857d495699e8db at mail.gmail.com>
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 mailing list
linux-dvb at linuxtv.org
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



More information about the linux-dvb mailing list