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.
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
