[pvrusb2] pvrusb2 vs. em8300

[Mike Isely]

On Sun, 12 Feb 2006, Michael Roitzsch wrote:

> Hi Mike,
>
> I reported this problem already, but this was a long time ago, so let me 
> refresh the caches: I have a pvrusb2 which somehow collides with an MPEG 
> decoder card I have. The card is a DXR3 (aka Hollywood+) with the em8300 
> kernel module. The card is I2C based just like the pvrusb2. What happens is 
> that the pvrusb2 does not emit any audio when the em8300 driver is loaded. If 
> I prevent the em8300 module from loading and power-cycle the pvrusb2, 
> everything works fine (latest driver snapshot). But when both devices get 
> their drivers, the pvrusb2 is silent.
>
> I have not investigated the issue until today, since I had a different 
> problem with my Ubuntu not liking the em8300 driver for other reasons. I 
> wanted to fix that first to make sure the pvrusb2 problem is not related to 
> that. Today I got things sorted out and headed back to the pvrusb2. Of course 
> it still does not cooperate with that other driver. I grabbed two logs: one 
> with the em8300 driver in place (that's the broken one) and one without the 
> em8300 driver (that's the working one). From what I can see, the firmware1 is 
> not loaded in the broken case. Do you have any idea what might be going on 
> here and what further data I could provide?
>
> Michael
>

Two things:

1. Please send me the log data.

2. In the broken case, do this:

    cat /sys/class/pvrusb2/sn-XXXX/debuginfo

(The XXXX is your device serial number.)  Assuming that you're running a 
recent driver snapshot (current or immediately previous IIRC), then you'll 
get a list of I2C modules that have associated themselves with the pvrusb2 
driver.  If em8300 is interfering, there might be some evidence found 
here.  By the way, LOTS of TV tuners use I2C as an internal control bus. 
The architecture in V4L basically involves all the various I2C modules 
separately "probing" the I2C bus of a newly attached device, in an attempt 
to discover if a particular chip is present that the module can drive. 
If such a part is found, then the module will associate itself and then 
pvrusb2 will start sending it commands to operate its part of the entire 
device.  This is how msp3400, tuner, and saa7115 all interact with the 
pvrusb2 driver (tveeprom is a somewhat strange special case).  The probing 
method is largely up to the module in question and there's no guarantee 
that two I2C chips out there can't be assigned the same I2C address.  So a 
given module might mistake as its own a chip that really belongs to 
somebody else and thus the probing mechanism can be fooled.  I think there 
are already known cases in V4L where devices can collide.  I'm wondering 
if this might be another such case, which is why I think looking at the 
debuginfo file in the driver might provide more info.

You might find it interesting to compare the output of debuginfo in the 
working and broken cases.

   -Mike

-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |