Johannes Stezenbach wrote: > On Mon, Nov 28, 2005, Steve Toth wrote: > >> I did discover an issue with the I2C gate on the cx22702. I raised this >> last week. Basically, the cx22702 module expects the gate to be closed >> (blocking access to the pll from other modules). Now, by default, I >> start the part in 'open' mode then the board specific configs (during >> _init) determine whether the gate is acting in open or closed mode. >> >> The default behavior for existing drivers has not changed... The gate >> will be closed at all times. >> >> For the HVR1100, we leave the gate OPEN at all times... This approach >> felt like a good compromise. >> > > Hm, many digital demodulator data sheets say the i2c gate's > purpose is to isolate the PLL from the demods i2c bus > to decrease phase noise (i.e. signals on the i2c bus > may decrease signal quality due to interference). Thus the i2c > gate should be closed except when talking to the PLL. > > Thanks Johannes. I know, it's a problem. That's why I asked for implementation suggestions late last week. Two very different parts of the kernel need to use the same PLL. When you're inside the cx22702 driver it's a no brainer, you can toggle the gate. When you're outside of the 702 driver, in tuner.ko, you have no concept of the 702, you only have an I2C bus to operate on. I could not see a nice solution to the problem without a lot of re-engineering.of the kernel tuner support in V4L. Please, I'm open to ideas. I had three approaches in mind, ordered by level of complexity. I opted for the first because it was the quickest way to get product support without compromising a longer term plan. I didn;t want to spend weeks trying to get this (and two more drivers) into the kernel. 1) The current solution where the gate is left open for specific hardware, and not others. All existing hardware remains as is, no difference in the gate handling. All of the source changes are localised inside the existing cx22702 and cx88 device frameworks. It's clean but not ideal. 2) Pollute tuner.ko with cx88 knowledge. Possibly put callback functions (setup in cx88-cards/dvb) into cx88_core and have tuner.ko query cx88_core from the i2c_client, gather the callbacks and action them. This feels a little unclean and tuner is not current a dependency on cx22702 or cx88xx/00 so references to functions can/will break if modules are removed. I guess we could literally create an external in cx22702 and make tuner be dependent. I don't really like this. It felt like a compromise. I did look at the stv0299 references from budget-core, luckily (somewhat) they are both within the same framework where implementation is much cleaner. 3) A totally different, longer term approach. (My actual preference). Have a single tuner.ko module which deals with ALL plls and tuning requirements (analog/digital). Have demods (and/or cx88) call a registratation mechansim "tuner_register_pll" with a number of callbacks and capabilities. This would require a lot of rework on all of the demods but nicely bring tuning back into a single place. tuner.ko would then be a dependency on dvb_core (?) and cx88xx (or possibly even a newer v4l_core / v4l2_compat?). I'm sure other ideas will come to mind. I asked late last week for other suggestions. I think longer term we'll be forced to consider 3, as more and more complex tuning requirements are brought into the market. Even without new designs appearing, we have two different ways to tune the same single piece of hardware... That's a problem that should be removed. I took the simple approach because it got us support quickly, without pollution. Question: In it's current form (1) will you accept the patch? If not, we need to come to a consensus on the best approach and begin implementation. Steve
