[pvrusb2] pvrusb2-dev-0c73d0aa725b

[Mike Isely]

On Thu, 21 May 2009, Mike Isely wrote:

> 
> Martin:
> 
> This coming weekend I will try to reproduce the problem here in a 2.6.29 
> kernel.  I'll let you know.
> 
>   -Mike
> 

I have some results.  I am able to reproduce the problem.

Just to recap, the symptom at issue here is that the audio fails after 
switching from radio to tv while streaming.

I tested with kernel 2.6.29.3.

With the stock pvrusb2 driver included with that kernel, the problem 
does not occur.

With the current standalone driver compiled for that kernel, the problem 
DOES occur.

Then I played a hunch.  The standalone driver is effectively a 
"superset" driver.  It includes lots and lots of goodies that can be 
selectively compiled - the idea is that various things are expected to 
be enabled / disabled depending on the surrounding kernel environment.  
This is all controlled by the file pvrusb2-options.h included with the 
standalone driver.

Well, one of the more recent and pervasive things done with the driver 
was a complete reworking of how it communicates with the various 
chip-level drivers.  The v4l-dvb repository has a new unified mechanism 
for performing this communication.  It's a lot cleaner than was there 
before and in fact taking advantage of it allows the pvrusb2 driver to 
obsolete a whole bunch of code within the driver that was there 
basically to do for the driver what the v4l-dvb core now does.  This new 
ability becomes possible with the v4l-dvb version included in the stock 
2.6.29 kernel so the pvrusb2-options.h file compiles in the new 
mechanism while disabling the old one.  The two switches within the 
standalone driver source are PVR2_ENABLE_V4L2SUBDEV and 
PVR2_ENABLE_OLD_I2COPS.  For kernels older than 2.6.29 the following is 
in effect:

#define PVR2_ENABLE_OLD_I2COPS
#undef PVR2_ENABLE_V4L2SUBDEV

But for 2.6.29 or greater instead the standalone driver does this:

#undef PVR2_ENABLE_OLD_I2COPS
#define PVR2_ENABLE_V4L2SUBDEV

Now, with 2.6.30 (or maybe 2.6.31) the old mechanism will no longer 
work, but for 2.6.29 the old mechanism is still usable.  So as an 
experiment, I modified pvrusb2-options.h so it treated the 2.6.29 kernel 
using the old communications mechanism and re-tested.  And...  now the 
audio problem does not happen!

The pvrusb2 driver in the v4l-dvb repository has none of these nice 
switches.  Rather the source code is transformed into a smaller version 
by filtering it with all the switches set a specific way (normally what 
is appropriate for whatever is current in v4l-dvb).  This means that the 
pvrusb2 driver source in v4l-dvb no longer even has the old mechanism 
present.

This fits with the symptoms you are describing - with the older v4l-dvb 
snapshot you tried the pvrusb2 driver still talked to the chip-level 
drivers the "old way" which we know still works.  But with the current 
v4l-dvb repository the pvrusb2 driver only includes the code for the new 
sub-device mechanism.  Thus the breakage.

I was also able to get the audio to fail even if I closed /dev/video0 
after switching back to tv mode.  Most (but not all of the time) it 
failed this way.

So what now?  Well I could have introduced a bug in the pvrusb2 driver 
in how it talks to the sub-device drivers.  Another possibility is that 
the v4l-dvb core has a bug in the new mechanism.  I'm not sure which 
yet.  I need to dig further.

I never saw the tda9887 errors you are seeing.  However (1) I never 
tested directly against a current v4l-dvb snapshot since I'm able to get 
it to fail just with the standalone driver and a stock 2.6.29 kernel.  
And (2) since I am seeing the audio issue anyway, it's a good guess that 
the tda9887 thing is unrelated.

  -Mike


-- 

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