[linux-dvb] Re: [Patch] Adding support for the Hauppage HVR1100
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.
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
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