Re: [RFC] multi std silicon tuners and analog tuners

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux