[linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
abraham.manu at gmail.com
Thu Apr 5 21:41:49 CEST 2007
Mauro Carvalho Chehab wrote:
> Hi Manu,
> Em Qui, 2007-04-05 às 00:16 +0400, Manu Abraham escreveu:
>> so when subsystem A acquires control, a lock is acquired by the bridge
>> (the bridge can be imagined as a fulcrum for switching between systems)
>> This locking would be a FSM for handling different switches.
>> now the bridge can acquire/release locks, needs some code additions to
>> the bridge to have this, for old devices it doesn't matter at all.
>> now when subsystem B request control, it makes a request to the control
>> manager on the bridge, the control is passed all the way down from the
>> frontend(DVB)/ tuner(V4L) so it still remains quite independent the
>> tuner/frontend part from the bridge
>> with regards to TUNER (V4L) the same can be achieved using set standard
>> or similar.
>> Will have additionally one more callback (a new one)
> Currently, there two different tuner approaches for dealing with hybrid
> tuners. One as part of DVB frontend and another on V4L tuner
> implementation. This is bad, since it results on duplicating some code.
ACK, not only is that duplication bad, but when there will be large
changes with one system, that approach will be a failure. Too much work
will be involved when an internal API changes, not to mention when the
external API change occurs.
> For example, if you look on non-silicon tuners, the core of dvb-pll do
> the same programming as tuner-simple.
> Also, for silicon tuners, we have a recent case, where tda897x deals
> with dvb, while tda8290 deals also with tda897x, but for v4l.
> The right direction for this is to have the same tuner code used by both
> V4L and DVB.
> DVB callback approach for dvb_frontends seems to be an interesting
> approach. It doesn't cover, however, all needs for V4L. For example,
> some devices have also FM radio support, where stereo carrier detect and
> analog signal strengh are important measures. So, it is needed to add
> newer callbacks and maybe some extra data field for this struct to be
> used also by v4l.
With what i thought, with some slight changes at both ends (very
minimal) it should be able to work.
> One interesting target is to have a common tuner/frontend code that can
> be used by radio, analog and digital tuners, in a way that it can be
> attached to dvb_frontend and/or to tuner_core.
Even without a common tuner, things can be achieved quite well, which
require lesser maintenance.
With the case of DVB, things are moving, ie not stagnant due to the
arrival/addition of new stuff, so that is also an important aspect in
deciding how to go about. A high maintenance path is not a viable option.
Having a common tuner is not a nice aspect. Subsystems should be
separated out, while still being interoperable.
> If just one module is handling both analog and digital tuning, it would
> be easier to have locks protecting the concurrence troubles you've
> pointed above.
Already have a driver now. It requires some trimming of the V4L parts
(someone probably might need to retouch/complete the V4L area), will
post after a few reviews.
More information about the linux-dvb