[linux-dvb] [PATCH]Frontends or51132, or51211 move common code to module

Manu Abraham abraham.manu at gmail.com
Fri Apr 14 11:59:54 CEST 2006


Andrew de Quincey wrote:
> On Friday 14 April 2006 10:17, Manu Abraham wrote:
>   
>> Andrew de Quincey wrote:
>>     
>>> On Friday 14 April 2006 05:19, Rusty Scott wrote:
>>>       
>>>> The attached patch moves the common logarithm code found in the or51211
>>>> and or 51132 frontends into a module that can be accessed by other
>>>> frontends as well. This patch is in anticipation of using the logarithm
>>>> code in the lgdt330x module to calculate a signal strength which is
>>>> currently not done.
>>>>         
>>> What about making it an "arithmetic module" instead of just for logs?
>>> From what I see we're going to be needing a place to put more and more
>>> things like this.. e.g. a fixed point implementation might be handy at
>>> some point as well (not that I'm suggesting you write that! Just renaming
>>> the module).
>>>       
>> Yeah, would be nice. The last we discussed, Ralph suggested that we can
>> probably add it to dvb-core, rather than a separate module, while being
>> at the new modules.
>>     
>
> Ah - sounds like a good idea... dvb_core_arith.c anyone?
>   

Have 2 or 3 functions here, for the current module, since it needs them 
(not for statistics) but for tuning itself

> BTW: as for the reporting stuff in dB - if we can do it for some cards (e.g. 
> the manufacturer told us), it would be great - no sense in chucking stuff out 
> if we can actually do it. But we need to distinguish those from the ones 
> where we cannot.
>   

Oh, the problem is not with the demod specs, but from the tuner guys. 
The demods are specified for a reference design. Only a very few tuners 
are based on the exact reference design/evaluation kit. The demod vendor 
gives the specs based on the eval kit/reference design only.

Say for example, one vendor will think he needs to modify the RF Input 
stage for some reason whatsoever. So when the input stage is modified .. 
well, all those don't hold good .. For this we will need to get hold of 
the specs from the relevant tuner guys. We do have some specs, but to 
incorporate that into the API we will need to introduce the tuner 
concept (not the v4l tuner concept, least to get confused, which implies 
only (2) missing out (1) even in the case of analog tuners, the reason 
being the information is hard to obtain) itself (since the tuner in 
reality consists of (1) RF input stage, (2) PLL, (3) Demod, basically. 
Eventhough there are Silicon tuners, these can be considered as a whole 
in that case except for the RF input stage), which will be breaking the 
current API.

This was what i mentioned in the previous post that we should keep the 
current APi as it is, work on a copy of it, separately, make all the 
changes to it and adapt it then. This will cause it to break only once, 
considering that we have many areas that we would like to change things.






More information about the linux-dvb mailing list