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). > 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. 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? > 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. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
