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

[fivenote]

Thanks Mike.

I'm happy to know we have something solid to work from now. If
something is broken, I'll usually stumble upon it - it's what I do
best :-).

I'll wait to hear from you after you've had time to work on it. Let me
know if there's any other info I can provide.

-vincent

On Tue, Jan 6, 2009 at 10:41 PM, Mike Isely <isely at isely.net> wrote:
>
> 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
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>



-- 
~~~~~~~~~~~~~~~~~~~~
VAO - fivenote at gmail.com
~~~~~~~~~~~~~~~~~~~~