[pvrusb2] HVR-1950 requires procreload=1?

[Mike Isely]

On Sun, 7 Jun 2009, Roger wrote:

> "procreload=1" seems to help, but isn't a viable solution.  Upon boot
> from hibernate, this problem reoccurs.

I have yet to find a real case where procreload=1 actually solves a 
problem.  It was added long ago when I was trying to find ways to help 
recover from crashed hardware.


> 
> Checking current module options:
> $ cat /etc/modules.conf |grep pvrusb2
> options pvrusb2 debug=1 ir_mode=1 procreload=1

For the pvrusb2 driver, 'debug' is not a flag but a bit mask.  By 
setting it to '1' you have actually DISABLED a lot of output.  Please 
read the documentation about this - the behavior of debug has been this 
way for many years.

http://www.isely.net/pvrusb2/usage.html#Logging


> 
> 
> Attaching dmesg log for the following scenario:
> 
> Got /dev/video0 and no /dev/dvb/*.  Unusable /dev/video0 (when trying to
> play with mplayer).
> 

Getting one but not the other makes no sense to me unless for some 
reason you managed to build the driver with CONFIG_VIDEO_PVRUSB2_DVB 
unset (which would remove the DVB parts of the driver).  But the normal 
build process for the standalone driver turns this one on.  If you are 
working from an in-kernel driver, then of course it depends on what 
you've set in the kernel.


> 
> What is notable to me are the following lines:
> 
> s5h1411_readreg: readreg error (ret == -5)
> pvrusb2: unregistering DVB devices
> device: 'dvb0.net0': device_unregister
> 
> 
> s5h1411_readreg seems to be v4l-dvb related.
> 
> ret == -5 probably isn't a good thing.
> 

Yes, it's a driver for the tuner within your device.  The error return 
indicates an I2C transfer failure ("-5" means EIO).

I think you have some issues with how you've configured DVB, though 
exactly what I do not know.


> 
> 
> Here's is an example of what should happen in dmesg:
> 
> 
> cx25840' 2-0044: Video signal:              not present
> cx25840' 2-0044: Detected format:           NTSC-M
> cx25840' 2-0044: Specified standard:        NTSC-M
> cx25840' 2-0044: Specified video input:     Composite 7
> cx25840' 2-0044: Specified audioclock freq: 48000 Hz
> cx25840' 2-0044: Detected audio mode:       mono
> cx25840' 2-0044: Detected audio standard:   no detected audio standard
> cx25840' 2-0044: Audio muted:               no
> cx25840' 2-0044: Audio microcontroller:     detecting
> cx25840' 2-0044: Configured audio standard: automatic detection
> cx25840' 2-0044: Configured audio system:   BTSC
> cx25840' 2-0044: Specified audio input:     Tuner (In8)
> cx25840' 2-0044: Preferred audio mode:      stereo
> cx25840' 2-0044: firmware: requesting v4l-cx25840.fw
> device: '2-0044': device_add
> PM: Adding info for No Bus:2-0044
> device: '2-0044': device_unregister
> PM: Removing info for No Bus:2-0044
> cx25840' 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> usb 3-4: firmware: requesting v4l-cx2341x-enc.fw
> device: '3-4': device_add
> PM: Adding info for No Bus:3-4
> device: '3-4': device_unregister
> PM: Removing info for No Bus:3-4
> cx25840' 2-0044: 0x0000 is not a valid video input!
> DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB
> Frontend)...
> device: 'dvb0.frontend0': device_add
> PM: Adding info for No Bus:dvb0.frontend0
> tda829x 2-0042: type set to tda8295
> tda18271 2-0060: attaching existing instance
> device: 'sn-6202710': device_add
> PM: Adding info for No Bus:sn-6202710
> 
> Also note when comparing the two sets of dmesg log outputs here, the
> timing of the call of function s5h1411_readreg seems to be several
> seconds after the initialization of cx25840.  Could s5h1411_readreg is
> either severely bugging-out or could it be a timing issue?

The two are different parts and their relative timing is not really 
relevant.

  -Mike

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8