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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
