Category | xc4000

The PCTV 340e is one of those unfortunate situations that I (Devin Heitmueller) personally take alot of criticism over. About two years ago I bootstrapped the driver, got it working with the hardware, but then never got around to cleaning up the code enough to get it upstream. This has resulted in the HG tree I created to fall behind current kernels, as well as people being frustrated that the work isn't available in the upstream kernel where they wouldn't have to recompile my driver every time they do a kernel update. While I generally strive to get my changes upstream so that they help out the maximum...

---

I finally got the new DVB generator up and running, and spent the afternoon debugging the PCTV 340e. The digital support is now working! http://kernellabs.com/hg/~dheitmueller/pctv-340e-2/ As always, there are a bunch of caveats: The testing as of this point has been *very* limited. I have basically confirmed that tuning works with tzap/mplayer with 8MHz DVB-T. The code needs a bunch of cleanup before it could go into the mainline. It's also based off a version of the v4l-dvb tree that is several months old and needs to be rebased against the current tip. This means that if you have...

---

So I am now at the point where I am ready to start debugging signal lock. This is the phase in the project where all the code is written but has never actually been tested/debugged. My situation however is complicated by the fact that I do not actually have access to a DVB-T signal currently. While I will be soliciting testers in general once I have something that I think basically works, at this point, I need one experienced user with access to a DVB signal who can provide an environment for me to remotely debug the board. The ideal candidate: Owns a PCTV 340e Has used DVB devices...

---

This weekend I spent some cycles working on the xc4000 driver and the surrounding code required for the PCTV 340e. I think I now have the PLL properly programmed, and I worked around the i2c clock stretching deficiencies in the dib0700. We're quickly approaching the point where I'm ready to start testing for signal lock. Once we have signal lock, there will be a call for testers, so stay tuned!

---

Did some more work on the PCTV 340e. After talking to Rainer over at PCTV as well as Patrick Boettcher, it seems pretty clear that this is some sort of issue related to the dib0700 not properly handling the xc4000's clock stretching. Pretty annoying though, since the last dib0700 device I worked on required me to fix up the dib0700 i2c interface, and it seems like again the i2c master is going to need more fixes. Also continued investigation into the situation with VBI support for em28xx. After confirming that neither Hauppauge WinTV 7 nor Pinnacle TVCenter Pro supported closed captioning,...

---

Spent another evening working on the PCTV 340e. I refactored a bunch of the xc4000 code so the standard firmware and scode blobs now successfully load. For the moment the video standard is left at the default and the driver is hard-coded to 8Mhz DVB-T. Also started going through the dib7000p configuration, which is needed before a lock is possible. I'm through the AGC configuration and just have to do the PLL config. Once that is done I will ask David to make a tuning attempt on 8Mhz and see if he gets a lock.

---

Spent most of the afternoon working on my tool which generates the firmware images for the xc4000. Pulled in the code from the existing xc2028/3028 driver to load the scode/std firmware into the chip, but it seems to fail the i2c write with the DTV8 standard. Probably some issue with switching between direct/indirect mode. Once that is done, we should be in reasonably good shape for the xc4000 driver (aside from a bunch of cleanup work). Will then have to get the dib7000p config setup at which point we can attempt to tune. In other words, continuing to make forward progress...

---

Spent last night continuing to work on the xc4000 driver for the PCTV 340e. I got the INIT1 firmware to load, so in theory the only remaining work items are to get the scode support working and properly populate the dib7000p configuration block, at which point I can make a tuning attempt to see if I get signal lock. On a separate note, I also need to get a firmware extract routine written for the drx-d firmware used by the HVR-900 R2 and PCTV 330e. I'm trying to simultaneously keep new development work on track while addressing issues coming up with support for older devices, which is not going...

---

I managed to successfully get the base firmware loaded into the xc4000 tonight. It turns up the mechanism for splitting i2c transactions is different between xc3028 and xc4000. The xc4000 requires the two leading bytes to be the same, whereas the xc3028 driver would only make the first byte the same. Once I cut over to the xc5000 version of the xc_load_i2c_sequence(), the i2c errors went away. Also, checked in a hack to get the request_firmware() call to work properly with the dib7000p i2c master under 2.6.31 (thanks to Michael Krufky for pointing me in the right direction). Despite the work...

---

After accidentally damaging the PCTV 340e board a user loaned me, I emailed my engineering contact at PCTV on Monday to see if he could provide some info so I could repair the board. Not only did he provide the necessary information, but I came home last night to find a package had arrived from their offices in Germany, with two brand new sample units (one 340e and one 340eSE). I'm only mentioning this so that when you readers out there are thinking about buying a new tuner, and you want to buy from a vendor who actively supports the Linux community, I would encourage you to consider buying...

---