[pvrusb2] mythtv and wintv-hvr-1950 - analog/digital scanning

[Mike Isely]

Uh-oh.  See below...

On Tue, 6 Jan 2009, fivenote wrote:

> Great... We're getting somewhere...
> 
> > lsmod | grep cx25840
> cx25840                36656  0
> v4l2_common            24576  7 tuner,cx25840,pvrusb2,cx8800,ivtv,cx2341x,bttv
> videodev               49024  8
> tuner,cx25840,pvrusb2,cx8800,cx88xx,ivtv,bttv,v4l2_common
> i2c_core               31892  13
> s5h1411,tda18271,tda8290,tuner,cx25840,pvrusb2,cx88xx,ivtv,bttv,i2c_algo_bit,v4l2_common,tveeprom,lirc_i2c
> 
> > cat /sys/pvrusb2/*/debuginfo

The stuff below are reports of various global control / state flags in 
the driver:

> Driver state info:
> driver: <ok> <init> <connected> <no decoder> <mode=analog>

Note the "<no decoder>" flag.  That just confirms the missing decoder 
state.

> pipeline: <idle> <configok>
> worker: <decode:quiescent> <encode:virgin> <encode:waitok> <usb:stop>
> <pathway:ok>
> state: error

And that "state: error" is the driver realizing it isn't in a viable 
state at the moment - because of the <no decoder> flag.  This is 
definitely a big piece of the puzzle.


This is the current state of which inputs are possible (no surprise 
here):

> Hardware supported inputs: television, dtv, composite, s-video


This reports current video buffer pipeline information.  It's obviously 
idle:

> Bytes streamed=0 URBs: queued=0 idle=0 ready=0 processed=0 failed=0


Here's the interesting part below.  It's a list of which V4L I2C modules 
are "attached" to the pvrusb2 driver.  Each of these modules controls a 
particular I2C bus target within the device.  What you see for each item 
listed is the name of the module (as given by the module itself), its 
I2C address (after the "@"), any "handler" that the pvrusb2 driver has 
associated with it (listed in parantheses), and a list of particular 
classes of commands that the pvrusb2 driver will send to it (in square 
brackets - normally that list is everything possible though in a few 
cases it might be trimmed):

> Attached I2C modules:

> Hauppauge PVR150 @ 0x71 [v4l2_standard v4l2_audiomode v4l2_bcsh v4l2_volume v4l2_freq v4l2_crop v4l2_size v4l2_log]

> cx25840' @ 0x44 [v4l2_standard v4l2_audiomode v4l2_bcsh v4l2_volume v4l2_freq v4l2_crop v4l2_size v4l2_log]

Ouch!  It's at this point where we should have seen "(handler: 
pvrusb2-cx2584x-v4l)", similar to what you see below for the tuner 
module.  I smell a big fat rat.


> tuner' @ 0x42 (handler: pvrusb2-tuner) [v4l2_standard v4l2_audiomode v4l2_bcsh v4l2_volume v4l2_freq v4l2_crop v4l2_size v4l2_log]

OK, so what this is telling us is that the cx25840 module showed up to 
the party and the pvrusb2 "party host" driver failed to recognize it.  
Had it been recognized, the pvrusb2 driver would have logically attached 
a "handler" to that module - this enables additional specific bits of 
communication.  In this particular case, since the pvrusb2 driver didn't 
spot the cx25840 module, it doesn't know who to send the "stream on" 
command to when streaming is started.  Not knowing that critical bit 
triggers the "no decoder present" warning, sets the "<no decoder>" flag, 
which places the driver into an error state, and the stream fails.

FYI, in case you're curious why there's no "handler" registered for the 
"Hauppauge PVR150 @ 0x71" instance, it's because in that case the 
pvrusb2 driver need not do anything unique to deal with it - that module 
is the linkage to the LIRC IR driver mentioned in the other thread.

So the root cause is to find out why the pvrusb2 driver failed to 
recognize the cx25840 module.  This is new broken behavior, and I don't 
believe there's anything you can do to accidentally cause this.  The 
pvrusb2 driver has not changed in several months now and this *was* 
working last time I tested.  The "big fat rat" I smell is that something 
probably changed in v4l-dvb surrounding code which has broken the 
pvrusb2 driver.  (And I know that the I2C architecture changed a while 
back, that might have precipitated this as various modules - e.g. 
cx25840 - have been moved forward to the new design.  This might get 
tricky...)

Going back to the in-kernel pvrusb2 driver will work around this.  Of 
course, running that driver is what led you here :-(  The standalone 
driver probably won't help since the issue that led you to the in-v4l 
driver involved tuner problems in v4l-dvb.  But now with the tuner 
fixed, the analog side is busted because of this new cx25840 problem.  

  [...]

> 
> 
> Mike, ami I missing "ghandler: pvrusb2-cx2584x-v4l"?

Yup.  Exactly.  :-(

I'll need to investigate this ASAP.  This issue is probably only in 
v4l-dvb right now, but once it hits the kernel I'm going to get buried.  
Unfortunately I have zero time right at this instant to work on it.  I 
will see what I can do this weekend.  Probably on Sunday.  Sorry about 
this.  Stay tuned.

  -Mike


-- 

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