[linux-dvb] [PATCH] Moving ALPS BSRV2 tuner handling code to separate file.

Manu Abraham abraham.manu at gmail.com
Sun Apr 16 11:23:36 CEST 2006

Perceval Anichini wrote:
> Hello !
>>>> What about doing things the old fashioned way, with a library?  Stick all the
>>>> nim (WTF is nim?) code into a directory, one nim per c file, and compile them
>>>> all into a nim.a library.  Then each driver can link against nim.a and will
>>>> get the nim functions it needs, and not the ones it doesn't.  The prototypes
>>>> could be in a single nim.h, or in nim_{foo,bar,baz}.h for each nim.
> [...]
>> Seems to work fine.  I added non-static global functions with the same name to
>> two modules, and they loaded fine, each calling their own version of the
>> function.  Not exactly the same as pulling the function in when the module
>> is linked at compile time, but I think that will work too.
> 	Using a static library will duplicate binary code into different
> modules as well, no ?
> 	Couldn't we build a single 'frontends' module that would
> include all tuners and demodulator selected by the user during the
> kernel configuration step ?
> For example, for a TT card, the following modules would be loaded :
> 	budget.ko
> 	frontends.ko (including stv0299 and bsbe1 code...)
> This reduces the number of modules to be loaded, but have the flaw
> to kinda obfuscate which tuners are really available in the system...
> Well, this may not a so good idea, as 'obfuscation' is a word that
> shall not apply in the kernel.
>   Another idea would be to compile the extra chip (I don't like the
> 'tuner' name, I'll explain that below), directly in the frontend
> using it (Ok, now I'm really lost between this frontend/tuner/stuff)
> I explain : Maybe the bsbe1.h, bsrv6 stuff shall be included in the
> STV0299 (This is not a tuner nor a frontend but a demod, no ?)
> module ???
> What I'm sure about is that using small header containing static
> code like Oliver did has several advantages :
>   - It works fine !
>   - The code dedicated to a single tuner is centralized in a single
>     dedicated file which is IMHO loveable -> no need to grep loads
>     of file to know where relevant code is !
>   - It allows to move easily the duplicated code in a single place.
>   - It does not imply Makefile modifications.
>   - If we find the good idea to avoid binary duplicated code,
>     it will be easy to applies, as all the code related to tuners
>     lies in a single place.
> Therefore, maybe we could finish to move all the 'tuner' stuff to
> frontends/, and then have a look of what could really be done to
> improve that binary code duplication ?
> For prefix suggestion, 'tuner-' seems a bit reductive for me : For
> example the bsbe1 chip also handle LNB control and DISECQ. Are these
> functionality really belong to the tuner stuff ? For me a
> 'tuner' is only related to HF stuff. To my mind a frontend is made of
>  Tuner + Demod + LNB control + optional DISECQ stuff. Do not hesitate
> to tell me if, I'm wrong somewhere...

In that case i should be having an Alps bsrv2 demodulator chip on the 
rev 1.3, rather than a ves1893. ;-)
wondering why Alps never released the above said demodulator datasheets 
.. ;-)

bsrv2, bs* are all tuners from Alps , not demodulators, AFAIK. The 
tuners don't do the DiSEqC but only a dedicated chip.
for example, on the Galaxis rev 1.3 FF card that i have, a LNBP13  is 
used for dedicated control. 
for DiSEqC.

The LNBP chip is never inside the tinbox itself.In some budget cases, 
the demod can be made to do DiSEqC also without a dedicated chip (It can 
be from other vendors as well). In this case, it is the demod which does 
the DiSEqC, even in this case it is discrete electronic components that 
do DiSEqC instead of the dedicated chip.

The term frontend, comes from the term RF frontend, which refers to the 
"tinbox". In many cases the tuner/frontend (tinbox) integrates the 
demod, while in some cases demodulators are outside the tuner (tinbox)


More information about the linux-dvb mailing list