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
