Hi, TUNER_SET_TYPE_ADDR, seems to break with that approach, it's possible to change the tuner type on the fly with it. There have been some devices around which for example use an xc3028 for analogue TV and a qt1010 for DVB-T, so in that case we wouldn't like the xc3028 hybrid tuner module to attach to the DVB part. Markus On 4/9/07, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:
Manu Abraham wrote: > Hi All, > > Currently, we have silicon tuners loading FIR filter specific DSP boot > codes for tuners as well, of course Silicon tuners. While working with > the STB6100 silicon tuner which had been a rogue for that matter, found > that the same could be extended for tuners as well. > > Some tuners as what i see, loads delivery system specific firmware to > optimize the FIR filter characteristics on the teeny DSP of the silicon > tuner. In some cases the DSP boot code is as well included in the > firmware which needs a reset of the DSP, but in many cases doesn't need so > > The approach can be used for *all* hybrid tuners how complex it might be > since it leaves room for future expansion as well. > > My thoughts go like this. > > currently the existing infrastructure is assumed to be thus ... > > DVB API is modified with the multiproto API update which thus has the > enhanced Silicon tuner changes already for the STB6100. > > with regards to the DVB API , the userspace sets a delivery system for > the demodulator, which can be a cached parameter at the bridge(ie, the > card config to be precise, which is also known as the glue logic) > > 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) > A possible implementation patch i have attached to this post. The base tree is at http://jusst.de/manu/stb0899-v4l-dvb.tar.bz2 The bridge specific locking code also i have included in the tuner driver. In reality it should go all the way down to the bridge driver. The driver doesn't actually do any real read/writes, but just provides the placeholders for the same. All delivery systems(DVB)/standards(V4L) are used in it. In real life one wouldn't have so many standards and delivery systems (for illustrational purposes) Awaiting comments Manu
-- Markus Rechberger _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
