Over the last few nights, I finally got a MythTV box setup that I could use for some testing of the HVR-950q. I did some work a few months ago to basically get the analog support working, but there were some reports of problems related to switching back and forth between analog and digital mode.
After adding some debugging to the driver, I found basically three classes of problems:
1. The power management on the au8522 was setup such that the chip would get completely powered down when switching modes. Essentially what would happen is when switching from analog to digital mode, the v4l stack would tell the au8522 to completely power down while in the middle of bringing up the digital half of the chip. The power management for both the analog and the digital side of the chip need to be changed such that they only power down their respective parts, rather than the entire chip. It’s basically a race condition, which is why it works sometimes but not others.
2. The digital side of the board won’t actually perform the first tuning request when switching from analog mode, because the driver’s internal state thinks it’s already tuned to the target frequency (so the set_frontend call just does a “return 0” without actually doing the tune). We will need to explicitly clear out the driver state associated with the digital side of the chip when powering down or switching over to analog mode. That’s why you don’t get a digital lock when switching from analog to digital mode, but then if you change the channel the next tuning request works.
3. MythTV’s “input group functionality” appears to be generally broken. Input groups are designed to handle cases where there are multiple inputs sharing a tuner, so that they don’t get used at the same time. However I can pretty clearly see that even after switching to analog mode, some thread in the mythtv backend continues to run the digital side of the board, performing tuning requests and polling the digital demodulator’s status.
So in other words, this is going to be more annoying than originally thought. Fixing the couple of driver issues is pretty straightforward, but digging into the MythTV code and figuring out why it’s screwed up is going to take some real effort (and users wouldn’t get the benefit of those changes unless they either build mythtv from source or wait until 0.23 comes out).
At least now I have a better idea as to exactly what is going on.