[pvrusb2] HVR-1950 on the SheevaPlug (Ubuntu Jaunty)

[Mike Isely]

On Tue, 29 Sep 2009, Kai Boenke wrote:

> 2009/9/28 Mike Isely <isely at isely.net>:
> >> 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