Category | hvr-2250

We've had a handful of reports cropping up related to HVR2200 model#89619 cards. With Ubuntu 12.04.1 the driver would attempt to load firmware from file NXP7164-2010-03-10.1.fw length 4019072 as defined in the saa7164-fw.c driver source. (Hint: it's not really an Ubuntu error) Sep 13 07:50:56 dell kernel: [ 83.432854] saa7164_downloadimage() image corrupt Sep 13 07:50:56 dell kernel: [ 83.432868] bootloader d/l has failed Sep 13 07:50:56 dell kernel: [ 83.433068] Failed to boot firmware, no features registered Technically, NXP have two different revisions of the SAA7164 chip, rev2...

---

I've applied a few patches to the tda18271 driver that may improve tuning in certain channel ranges. tda18271: fix calculation bug in tda18271_rf_tracking_filters_init There was a misplaced parenthesis in the tda18271_rf_tracking_filters_init function, causing improper calibration. This has potential to improve tuning on some channels, and possibly reduce the time it takes for the RF tracking filter calibration to take place. tda18271: prog_cal and prog_tab variables should be s32, not u8 Changeset name speaks for itself tda18271: fix bad calculation of main post divider byte There...

---

Thanks to everyone who reported the saa7164-buffer.c bug. It crept in during a last minute merge. Sorry. I repro'd the problems and made a patch. http://kernellabs.com/hg/~stoth/saa7164-v4l Regards, - Steve

---

First draft is available from http://kernellabs.com/hg/~stoth/saa7164-v4l Firmware is available from http://www.steventoth.net/linux/hvr22xx/firmwares/4019072 Comments welcome.

---

We've reached the end of a major milestone. SAA7164 is ready to be merged into the master LinuxTV repositories at linuxtv.org. For cleanup and ease of merging I've extracted all of the patches from saa7164-stable and created saa7164-merge. I've asked Mauro to review and merge at his earliest convenience. I want to take this opportunity to thank everyone involved in the SAA7164 project. If you've donated, tested, written to me, complained, given me words of encouragement or simply reported bugs... thank you! What's next for the SAA7164 project? Once the merge is complete we'll rebuild saa7164-stable...

---

We're looking to reports from two people that say they're having issues tuning to channels 91 and above with the HVR2250 Model 88061 / C3F2. Update: Patches for the issue are available in the saa7164-dev tree.

---

I've posted a new set of patches to the saa7164-dev tree. The significant change relates to how the driver deals with command queueing in an effort to resolve commands that have appeared to 'timeout', often seen as I2C message failures. One of the positive side effects is that these patches also lower the overall system cpu time and the platform feels much more responsive under a heavy load. I've just begun testing these patches in a private tree and initial indications are very good. Feel free to try these patches if you're experiencing bad behavior from youe HVR2200/50 driver. As always,...

---

Yesterday I spent most of the day testing the saa7164-stable tree on Ubuntu 8.10 (Intrepid) 64bit Desktop. In previous tests here, here, here and here everything largely went well on both ATSC/QAM and DVB-T, on our both 32 and 64bit platforms. The change history in the saa7164-stable repository shows that the tree hasn't needed (or had) any digital TV related bug fixes in 2 months. The last major piece of development work took place on May 19th in saa7164-buffering, in which I took a completely different approach to managing DMA buffering in an attempt to rule out some issues that could occur...

---

Today (July 18th) I'm going to spend the entire day trying to force a hang on the -stable driver with an HVR-2250. This will be a combination of tests using MythTV with LiveTV and background recording. I'll also be on IRC for most of the day (on and off) so if you have HVR-2250 or HVR-2200 hangs issues then feel free to contact me on irc.freenode.net #linuxtv.

---

I'm beginning to wonder what would happen if the deferred worker thread, responsible for dequeueing the DMA buffers after interrupt, and updating the device registers, got so far behind that the DMA buffers we're finally trying to dequeue have wrapped and are currently in use again. Hmm, that would cause awkward things to happen and probably lead to a full system hang. Time to add some jiffy monitoring to the deferred queue handing and gather some statistics on good and badly performing SAA7164 based systems. Maybe the lockup is as simple as this.

---