[linux-dvb] Re: [Patch] Adding support for the Hauppage HVR1100

Steve Toth stoth at hauppauge.com
Tue Nov 29 15:47:54 CET 2005

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 

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 

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.


More information about the linux-dvb mailing list