Devin Heitmueller writes: > Hi Ralph, > > Good to hear from you. > > > AFAIR, there were at least 2 reasons. > > One was that the existing driver does not accept 2 (or even 4) tuners with the > > same address (but behind different demods) on the same I2C bus which > > is the case on duoflex C/T addon cards. > > Do you mean that you are relying solely on the i2c gates on the > "other" demods being closed so that the tuners associated with the > other inputs do not receive the commands? If so, that would > definitely create the need for some weird locking structure (since > today demods typically do not manage their i2c gates in tandem). Yes, gate openings are locked against each other in the bridge drivers. > > The other was that it does not give back the intermediate frequency > > which the demod needs. (This is currently done by misusing > > get_frequency() but I added a get_if() call in newer internal versions > > which should be added to dvb-core/dvb_frontend.h) > > Generally speaking with other devices the IF is configured for the > tuner depending on the target modulation (there is a tda18271_config > struct passed at attach time containing the IF for various modes). > Then the demod driver is also configured for a particular IF. You mean the optional "struct tda18271_std_map *std_map;"? That would be a possibility. But then you have to handle IF tables for all kinds of tuners and demods in the bridge driver. Letting the tuner choose the IF and have a way to tell the demod (a simple get_if() call) is much easier. > Are you changing the IF based on something other than the target > modulation type? Or do you need to vary the IF based on different > frequencies within the same modulation? No. > > Feel free to change ngene/ddbridge to use the existing driver but it > > will need some major changes in tda18271_attach() and a few other places. > > If there are indeed good reasons, then so be it. But it feels like we > are working around deficiencies in the core DVB framework that would > apply to all drivers, and it would be good if we could avoid the > maintenance headaches associated with two different drivers for the > same chip. I know. At the time I was also just porting the DRX-K and only wanted to get it working based on the known to work Windows driver combination and not wrestle with other problems. I guess it whould not be too hard to adapt the old driver now. Another problem that keeps showing up in the existing drivers is that some tuner/demod combinations let the tuner call gate_ctrl, others only call it in the demod. This leads to problems when trying to use them in new combinations. Either the gate is not opened/closed at all or twice. In the latter case this can even lead to lockups if also using locking. Regards, Ralph -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
