Continued my work tonight on my HVR-950 digital support. Forgot how fun drivers can be when you don't have the design manuals for any of the chips...
Trying to figure out why the LGDT3303 wasn't responding to I2C commands on initialization. It looks like the reset pin is actually hard-wired to one of the GPIO pins of the em2880 bridge chip. This allows it to toggle which components are active based on whether it's doing digital reception or analog. This in itself isn't that uncommon (in fact, we did the same thing at 3Com when we designed the 56K version of the OCLM - the main CPU could reset the modem chipset by just pulling up a GPIO pin).
The funny thing is though that the resetting of the demodulator is done as a product of a callback in the tuner reset.
So here's how analog support works today:
- em28xx driver loads
- Bridge initializes
- Driver tells bridge to initialize tuner in analog node
- Tuner loads firmware and trips reset
- reset callback from tuner sets GPIO pins enabling tvp5150 video decoder
Now the fun part is when you want to be in digital mode. The way the DVB driver is layered as an extension to the analog driver, the workflow basically looks like this:
- em28xx driver loads
- Bridge initializes
- Driver tells bridge to initialize tuner in analog node
- Tuner initialize issues reset to the tuner
- reset callback from tuner sets GPIO pins enabling tvp5150 video decoder
- em28xx-dvb digital driver loads
- Digital driver tells bridge to initialize tuner in digital mode
- Tuner loads firmware and trips reset
- reset callback from tuner sets GPIO pins enabling lgdt3303 digital demodulator (and presumably disabling the tvp5150 as well)
- dvb_attach() is called against the lgdt3303 driver
Bearing in mind that the driver supports probably a dozen different combinations of tuner, digital demodulator, and video decoder chipsets, it's little wonder that it's is such a mess.
Unfortunately, without breaking out an oscilloscope and mapping out the GPIO pins, I'm afraid to just start twiddling them until it works. Driving a pin high that's designed to be an input will likely burn out whatever it's connected to. This was another valuable lesson which I learned at 3Com when I burned the tip of my finger discovering that I had wired up a UART chip backwards (the burn took two months to heal).
After showing my father the burn, he pointed out that when checking a chip for heat you're only supposed to barely touch it. I guess little gems of wisdom like that might have been what kept me out of hardware design.
