I'm entering this discussion a little late, but I think I'm going to be heading the xbox-linux i2c work, so I thought I would introduce myself and add a few comments. > > The ADM1032 is compatible with an existing driver we > > have, I believe. > >Don't think so. >As shown on our 'new drivers' page the ADM1032/LM90/MAX6657/8 >are new chips we don't yet support. At first glance it >looks like we would need a new driver. >But the devices are fairly simple so we could whip up a >driver quickly if you wanted it. Since 3 companies >have come out with compatible chips I assume it will >be popular and we'll be developing a driver sooner or >later. If you're willing to test it, great. We'd definitely be interested in testing the driver if you create it. Otherwise we will, in time, have to code it ourselves. Either does work, but you could certainly do it faster than us. > > > A different question: I haven't had a thorough > > > look into your code yet - > > > can drivers using i2c-amd756 register to receive > > > interrupts issued by the SMBus controller? The > > PIC includes some >watchdog functions (the box > > > gets reset/turned off when the eject or power > > > button gets pressed and the CPU does not respond > > > to the I2C message), and it would of course be > > > better to add interrupt handlers than do polling. > > > > Good question. I'm not sure how best to address > > that, or which interrupt to use or who would listen > > to it. Perhaps if a PIC monitoring daemon were > > written, and listened to that interrupt. It could > > check that PIC status (either directly via > /dev/i2c-*, or by a chip >driver) when it received > > an interrupt. I don't believe that the i2c-amd756 > > lists to an interrupt... and I'm not sure what it > > would do if we configured it to... it would need to > > punt that to something else (probably a user-space > > app) to do something about it (like shutdown the > > system). > >Most of our drivers don't have interrupt support in >them. If we add it we'll have to make sure we do it >in the "right" way, whatever that is :) I have looked through the kernel i2c code (or at least I did about 6 months ago) and I didn't see any support for "multi-master" i2c buses. As far as I can tell, these should be treated (from user space) as two separate devices. The first is what you have, mastering of the i2c bus. The second implements a blocking ioctl interface which unblocks when the client portion of the i2c device is addressed. If I'm not completely off-base, I'd love to work on development of multimaster mode (possibly extending the bit algo to include multi-master support). I'm not intimately familiar with the i2c core, but it didn't look overwhelmingly complex when last I looked. If I *am* completely off-base, please let me know where my logic is flawed. Let me know how I should procede in starting work on i2c multimastering. You can contact me directly or through the xbox-linux mailing list. -SpeedBump _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com
