[pvrusb2] Request: Check I2C addresses

[Mike Isely]

I'm in the process of making some fairly pervasive changes in the 
pvrusb2 driver to support a new V4L architecture that permits safer 
handling of I2C client modules.  (No, I haven't forgotten about raw 
mode, but this work has to come first due to some other issues.)

There's no point in getting into the details, however one difference 
between the "old" way vs the "new" way is that with the "old" way each 
I2C client module would try to detect the I2C address where its chip 
resided while with the "new" way the pvrusb2 driver now must tell the 
I2C client module what I2C address it should use.  This makes sense 
because the bridge driver (e.g. pvrusb2) will have more information 
about the device as a whole and should know where the various I2C chips 
are set up.

However this causes a slight problem because right now the pvrusb2 
driver doesn't actually KNOW what I2C addresses to assign, since it has 
been relying on the individual I2C client modules to figure this out.  
There are few things I can do to deal with this:

* For devices I have, I am going to check each one myself (duh).

* For devices I do not have, it's possible to tell the I2C client module 
to try several addresses - so I could in theory just tell it to try the 
same addresses that the module had previously been probing on its own.  
This partially defeats the point, but it does at least permit the driver 
to continue working as well as it had before.  But I'd rather avoid this 
if I can...

So I need some help here.  What I'd like is for pvrusb2 users to do 
this:

1. Plug in your device (if you haven't already).

2. cd /sys/class/pvrusb2/*

3. cat device_hardware_description debuginfo >/tmp/info.txt

4. E-mail /tmp/info.txt to me.

The device_hardware_description sysfs node will tell me which type of 
device you have and the debuginfo sysfs node will report a list of 
attached I2C client modules and their mapped I2C addresses.  (I need the 
first in order to establish the context for the second.)  This will 
allow me to construct proper maps in the pvrusb2 driver for all the 
device types.  If you have several devices, try each one - you might get 
differing results (in which case send me all the variations).

I have several samples here for the older PVR-USB2 tuners from 
Hauppauge, along with an HVR-1950 sample.  I also have the 2 OnAir 
tuners that the driver supports.  What I do NOT have are the Gotview 
tuners - there are two types for those.  But even for the Hauppauge 
tuners, it's possible that I2C addresses may shift around within a 
particular model line because Hauppauge relies on an internal eeprom to 
differentiate types without actually changing the model number.  So even 
though I have some samples it would still be useful for others to send 
me that info anyway so I can look for any variations.  It's probably 
likely that I will have to specify a set of I2C addresses for the tuner 
I2C module for this reason anyway, but having this data will help.

I might get flooded with data here, but I'll yelp if I get too much.  

Note that what I'm asking above will not do anything "bad" to your set 
up; you can even do that while the device is in use by an application.  
The data that gets returned should not cause any privacy issues beyond 
telling me what kind of pvrusb2-driven hardware you have.  Note also 
that if you don't have a "debuginfo" mode in the driver's sysfs 
directory then you driver was compiled without the debug interface.  In 
that case you can pull similar information from dmesg output, but it's 
harder to describe correctly so just tell me if you have this issue.

Thanks for your help.

  -Mike

-- 

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