On Tue, 29 Sep 2009, Kai Boenke wrote: > 2009/9/28 Mike Isely <[email protected]>: > >> DVB: Unable to find symbol tda18271_attach() > >> tda829x 0-0042: type set to tda8295+18271 > > > > This specific error is because the tuner module component for that chip > > is missing from your kernel. > > > > You are right. I checked my Kernel-Config and found that even though > CONFIG_MEDIA_TUNER_CUSTOMISE was not set, CONFIG_MEDIA_TUNER_TDA8290 > did not get compiled (or probably more accurate: The compiled module > did not load - did not check that). > Having this part compiled as well I actually get a step further: > > [...] > pvrusb2: Device initialization completed successfully. > pvrusb2: registered device video0 [mpeg]
When you see that "registered" message, the driver has basically finished its initialization - successfully. This is a good thing. Now there are still other things going on (see further)... > cx25840 0-0044: firmware: requesting v4l-cx25840.fw > cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes) The cx25840 module uses a thread to control firmware loading on its own. So this step can happen out-of-line. (In fact on hybrid devices this can happen additional times when switching back to analog mode.) Nothing wrong here... > tda829x 0-0042: setting tuner address to 60 > tda18271 0-0060: creating new instance > TDA18271HD/C1 detected @ 0-0060 > tda829x 0-0042: type set to tda8295+18271 These messages come from the tuner module not the pvrusb2 driver. Certainly they are going to be in response to something going on within the pvrusb2 driver. This output looks fine. > usb 1-1: firmware: requesting v4l-cx2341x-enc.fw This message is a result of the pvrusb2 driver initializating the mpeg encoder. Why does it happen later? Glad you asked - because that chip's initialization does not need to happen as part of the driver's initialization. It can happen multiple times. You'll see this take place if the driver recovers the chip from a jammed state (unfortunately this can happen but the driver handles it fine). On hybrid devices, digital mode generally doesn't require the mpeg encoder to be initialized and in those cases this message might not appear at all if you stay in digital mode. (For the OnAir devices however there is a workaround implemented to briefly touch analog mode in order to solve a problem in digital mode so there you'll always see this message once shortly after initialization.) The prvusb2 driver has effectively a sequential initialization sequence. Once get past these messages: pvrusb2: Device initialization completed successfully. pvrusb2: registered device video0 [mpeg] then all that sequential initialization is done and any further actions take place asynchronously. That can include firmware loading, and various chip-level actions (some of those sub-device drivers have their own threads). The pvrusb2 driver has an internal state machine it uses to correctly sequence the whole video pipeline and it can do various basically autonomous things at times to keep the device healthy. So up to this point at least, there's nothing wrong in the output you've shown here. > > Sadly, this is where it stops. There is no error-message for what > might happen after the file get requested. Looks like I will have to > compile debug-output into the Kernel to get a deeper insight? The > Firmware-Files however are in place: It stopped there because the driver is waiting for you to do something, i.e. open it and use it :-) > > # ls /lib/firmware/ > v4l-cx2341x-dec.fw v4l-cx25840.fw v4l-pvrusb2-73xxx-01.fw > v4l-cx2341x-enc.fw v4l-pvrusb2-24xxx-01.fw > v4l-cx2341x-init.mpg v4l-pvrusb2-29xxx-01.fw If loading of a firmware image fails, generally you will see an error message in the system log reporting this. If there's no error message then the operation was successful. Try looking at /sys/class/pvrusb2 and see if you can spot anything there. You should also see a /dev/video0 (or similar) node present - the "registration" message printed to the log is the point when the driver reports that it has registered itself with the v4l core and thus the device node should be there. > > Oh, by the way. I am targeting the same hardware (SheevaPlug) as > Charles back in June. However, he sticked with Ubuntu as OS whereas I > use Debian (Squeeze). As far as I can tell from the above, you've got a working setup (so far). -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
