On Jan 19, 2011, at 8:50 AM, Jean Delvare wrote: > Hi Andy, > > On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote: >> As I understand it, the rules/guidelines for I2C probing are now >> something like this: >> >> 1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not >> do hardware probes at all. They are to assume the bridge or platform >> drivers verified the I2C slave hardware's existence somehow. >> >> 2. Bridge drivers (pvrusb, hdpvr, cx18, ivtv, etc.) should not ask the >> I2C subsystem to probe hardware that it knows for sure exists, or knows >> for sure does not exist. Just add the I2C device or not. >> >> 3. Bridge drivers should generally ask the I2C subsystem to probe for >> hardware that _may_ exist. >> >> 4. If the default I2C subsystem hardware probe method doesn't work on a >> particular hardware unit, the bridge driver may perform its own hardware >> probe or provide a custom hardware probe method to the I2C subsystem. >> hdpvr and pvrusb2 currently do the former. > > Yes, that's exactly how things are supposed to work now. And hopefully > it makes sense and helps you all write cleaner code (that was the > intent at least.) One more i2c question... Am I correct in assuming that since the zilog is a single device, which can be accessed via two different addresses (0x70 for tx, 0x71 for rx), that i2c_new_device() just once with both addresses in i2c_board_info is correct, vs. calling i2c_new_device() once for each address? At least, I'm reasonably sure that was the key to making the hdpvr IR behave with lirc_zilog, and after lunch, I should know if that's also the case for pvrusb2 devices w/a zilog IR chip. -- Jarod Wilson jarod@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
