Category | xc5000

After a rather large bug hunt, I've finally submitted the HVR-950q patches upstream. In the end, we created 24 patches addressing a ton of longstanding bugs: au8522: fix intermittent lockup of analog video decoder au8522: Fix off-by-one in SNR table for QAM256 au8522: properly recover from the au8522 delivering misaligned TS streams au0828: Make the s_reg and g_reg advanced debug calls work against the bridge xc5000: properly show quality register values xc5000: add support for showing the SNR and gain in the debug output xc5000: properly report i2c write failures au0828:...

---

Continued debugging has produced another dozen fixes for the HVR-950q. Most of these are low-probability failure conditions (race conditions, etc). However take a bunch of 1/1000 chance items together and you're likely to hit one of them once in a while... A couple of noteworthy changes: Firmware load time has been sped up to 2.9 seconds (down from 8-10 seconds). This should eliminate the need for MythTV users to specify the "no_poweoff" xc5000 modprobe since it will now load fast enough to avoid a mythfrontend timeout. Fix a case where the xc5000 tuner enters a failure state and all subsequent...

---

I finally spent the day and gathered up all the various patches I had kicking around for the HVR-950q. They can be found here: http://git.kernellabs.com/?p=dheitmueller/cx23885_fixes.git;a=shortlog;h=refs/heads/950q_fixes This includes the longstanding bug at startup that would cause the xc5000 to not properly bind on the digital side, a rather nasty case that hangs the analog video decoder in adverse signal conditions, and a case where sometimes digital tuning succeeds but doesn't ever return a transport stream to userland. It also resolves the confusion users see when the run tools like...

---

Finally getting caught up on a bunch of patches from various users I have been dealing with via email. Issued a PULL request tonight, which should make those people happy (as well as everyone else using the effected products) http://kernellabs.com/hg/~dheitmueller/misc-fixes3 On a personal note (but perhaps of interest to this crowd), I bought a new LG 42" television a couple of weeks ago. It actually runs Linux, and includes a serial port and USB port for management. I put in a request for the GPL source code last week, and the request was fulfilled today. I will be doing a diff and seeing...

---

I received an email tonight from a user who characterized me as "impolite" for not replying to his previous email in a timely manner (two days). I make an effort to take constructive criticism in stride, and am always looking for ways to improve the quality of the free volunteer services I provide to the community. In that light, I took a few minutes to take an inventory of the various things I did this week to see if I could have avoided the dissatisfied email. So, what have I been doing in the last week? Gained access to Andreas Lunderhage's debugging environment, analyzed the USB traces...

---

Tonight I finally fixed the last Pinnacle 800i issue and issued a PULL request to Mauro for the xc5000 improvements. If you're reading this because you're looking for the firmware, you can find it here: http://kernellabs.com/firmware/xc5000/ Now that we have legal redistribution rights, I'll be working on getting this firmware into the various distributions so that users have a true "plug-and-play" experience. Thanks go out to all the users who were kind enough to test the beta releases, as well as to Xceive for providing documentation and firmware that we are allowed to redistribute.

---

I spent pretty much all evening continuing to debug strobing the xc5000 reset on the Pinnacle 800i. Not to beat the topic to death, but this has proved more of a challenge than ever expected. If nothing else, perhaps you will learn something new about methods for debugging these sorts of issues. I took several approaches tonight. I loaded the card up on a Windows box, and confirmed that it was setting MO_GP1_IO to 0x10ff using the dscaler's regspy tool. This is a handy little tool for watching registers, although it gives you a realtime view, which means you are likely not to see rapid changes....

---

I spent most of last night attempting to get the xc5000 reset pin working on the Pinnacle 800i. Either I am not properly programming the GPIO registers to go low on the cx23883, or the reset isn't actually tied to one of the GPIOs. Steve was nice enough to lend a hand over irc and offer some debugging tips, at least validating that I wasn't doing something really stupid. Tonight I guess I will break out an iron and try to put some traces on the board so I can use the logic analyzer. Because it's a PCI board, using a scope isn't really practical. This also means I will have to move a bunch...

---

I think I've said this before, but life is *much* easier when you have an engineering level contact at the vendor. After my previous post, I had an extended discussion with Steven Toth (who committed the original GPIO fix) on strategies for determining the correct GPIO to reset the xc5000. These included ideas like adding code to poll the 24 GPIOs in succession to and waiting for the tuner to become unresponsive. I was also considering removing the RF shield from my device and tracing it out by hand with a meter, which is pretty laborious since I don't an SMT rework station. In the end though,...

---

Got some feedback today on the xc5000 tree I posted yesterday. It's been generally positive, although one user is reporting some suspicious behavior. I also started debugging why the Pinnacle 800i stopped working with my tree. I bisected the patch series and determined that the problem was introduced in the patch that started doing power management by pulling the xc5000 reset pin low. I had assumed it was some problem with re-initializing the xc5000 after being brought out of reset, however that was not the issue. It turns up that the xc5000 reset callback is strobing the cx23883's MO_SRST_IO...

---