Not just another Linux blog ...
PCTV 340e and dib7000p i2c bugs
For the last couple of nights, I have been continuing to work on getting the xc4000 running on the PCTV 340e. However, last night I made the mistake of updating the kernel in Ubuntu Karmic to the latest 2.6.31 snapshot, at which point I would get a kernel oops every time request_firmware() was called. After a good bit of backtracking to figure out where the breakage came in, it turns up the dib7000p i2c master implementation does not set the dev.parent field in the i2c adapter structure. As a result, the device argument to request_firmware() is NULL.
It looks like the field was never being populated, but the issue was not visible because very few tuners both are behind the dib7000p *and* use request_firmware(). Also, a printk() got added in 2.6.31 which makes use of the field, so it is no longer permitted to be a NULL pointer.
I’ll have to poke around at the dib7000p code and figure out how to get access to the usb_device pointer, at which point the code should start working again.
Also, I compared the trace for the xc4000 firmware loading against the Windows trace, and I noticed that the Windows driver never sends more than 32 bytes at a time, whereas the Linux driver sends 64 bytes. This might explain the failures seen a few hundred bytes into firmware loading. I do not know if the other 32 bytes are being truncated or not.
6 Comments for PCTV 340e and dib7000p i2c bugs
Did you ever fix this bug?
Mathias,
I did fix the one bug with the oops that occurs with 2.6.31, although it has not been submitted upstream yet. I also got the firmware to load successfully, which ended up not being a bug in the dib7000p’s i2c stack but rather the xc4000 driver. There is still one outstanding issue where the very last i2c command returns an error, which I have not successfully nailed down yet.
Ok, thanks.
I asked, because I seem to experince the same problem – though I use the xc2028 driver.
I haven’t done much kernel debugging, and have therefore been unable to find the cause of my problems – but it appears similar from the dmesg printout.
I was wondering where I could get my hands on the patch – I would very much love having a working TV-tuner (and remote-control).
Well, I doubt it is the *same* issue. You would need to be more specific about what device you are using and what components it contains before I could offer any suggestions.
I am using a built-in TV-tuner on a new laptop. The tuner also has a sensor for a remote control.
Here is the output of lsusb -v:
http://pastebin.com/f20f1d35d
The specifications does not say exactly what model it is, but given the lsusb and the fact that the windows driver is for a Yuan MC770A, I am guessing, that this is in fact the model (or perhaps a rebranding of it – though that would not make any difference to the driver).
My laptop is an ABook 1590W (from a Danish company).
The specifications for it (in Danish):
http://abook.dk/index.php?option=com_content&task=view&id=72&Itemid=46
http://abook.dk/images/stories/notebookpdf/abook1590w.pdf
Windows drivers for it:
ftp://ftp.abook.dk/ABook Drivers/1590W
Now for the problem:
The driver will load correctly, but when I “scan /usr/share/dvb/dvb-t/dk-All”, I get this in dmesg:
http://pastebin.com/f1e0d0026
I don’t know how to debug the issue futher, but I would be willing to try, if you told me what to do. 
Looking at the stack trace, it looks like the same basic bug I saw with request_firmware().
I worked around the issue with this patch:
http://www.kernellabs.com/hg/~dheitmueller/pctv-340e/rev/ba97460d2b3e
However, this patch is specific to my board and you would probably either need to do something more generic so that it works for all boards or add it to the tuner setup for your particular board.
Devin