Kernel Labs

Spent this evening digging into how the 0x418, 0x419, 0x420, and 0x421 registers are getting the values which cause video corruption. Just as a sanity check I dropped in the HVR-1850 that Steven was kind enough to loan me, and confirmed that the problem doesn’t occur there.

This also allowed me to dump out the register state for the 1850 board? Why is this useful? Because there were two likely possibilities as to why the 1800 was broken and the 1850 worked:

1. The code path in the driver that initializes the HVR-1800 is somehow different, resulting in the register state being programmed differently for the two boards
2. The registers are programmed identically, but the register definitions built into the chip changed between the cx23887 and cx23888, causing breakage

And what did the register dump reveal? The registers were being programmed identically by the driver. This suggests the source of the issue is #2 above.

Remember how I said a couple of posts ago that “I tend to cheat”? Well, here’s where I do exactly that. Knowing that the registers were programmed identically, I just did a quick comparison of the cx23887 and cx23888 register maps, and indeed Conexant did change the definitions of the registers. Of course I could have spent several hours dumping the registers under Windows and analyzing the behavior, but why would I do that when I can spend five minutes and look up the answer?

Long story short: we just need to add some calls to “is_cx23888()” in the cx25840 driver and make a bit of the logic conditional. That should address the formatting issues, as well as the color problems. The debugging also revealed that the hue and saturation V4L2 controls were broken, which means we’ll need to add an if() block to handle that as well.

Those fixes are straightforward and should be available shortly. It doesn’t explain though the issue with the video being corrupted due to the 0x404 register. The cx23887 and cx23888 treat that register exactly the same, and the field is related to injection of ancillary data into the ITU-656 stream. So that will need a bit more debugging. My suspicion though is that either some other register is being programmed improperly and turning off the ancillary data injection entirely obscures the issue, or the HVR-1850 is programming the cx23417 MPEG encoder differently than the HVR-1800 does (such that the 417 isn’t expecting ancillary data if it’s an HVR-1800 board).

Stay tuned!