[i2c] linux-i2c and smbalert

[Jean Delvare]

Hi Hendrik,

I am moving this thread to the i2c list, as it doesn't appear to have
anything to do with sensors but rather with I2C/SMBus.

> in my notebook, I have a chip (namely O2 Micro OZ99x) that probably can do 
> SMBALERTs for events (panel buttons in this case).
> The SMBus specification[1] says that it's optional.
> 
> The only mentioning of alert reponse address (ARA) in the i2c-ali1535. And 
> according to specs from intel[2], the i815 has it, too.

The i2c-ali1535 driver mentions it but doesn't actually support it.

I don't think you are really interested in Intel's i815, but rather in
the i801, which is the chip with the SMBus controller.

> I guess, the interrupt handler should check if the interrupt was due to an 
> SMBALERT and then handle the alert properly by issuing a read from the ARA 
> (0x0C), thus finding the device address. Then it should call the driver that 
> was registered for that address.

Yes, something like this.

> Was there any work done on this? I would really like to try this out with the 
> above device combination, however the i2c-i810 doesn't even listen on the 
> irq ?!?

No, I don't remember anyone working on this. You will face two
different problems:

1* As you noticed already, most SMBus bus drivers used in regular PCs
are poll-based rather than interrupt-driven (i2c-i801, i2c-viapro,
i2c-nforce2, i2c-amd756...) That being said, the interrupt you would
get from an SMBus alert would be of a different nature than the
interrupt the driver would get on transaction completion. In theory
they could even be different interrupt lines as I understand it. But
converting the drivers to be interrupt-driven would be very welcome
anyway, and there might be common code.

I remember Mark M. Hoffman had been working on getting i2c-i801 to be
interrupt driven, but he stopped working on that while his driver did
not support all transaction types supported by the mainline driver, so
his version of the driver couldn't be merged.

2* As I understand it, ARA support would require some cooperation from
the i2c core. Once your receive an ARA's interrupt in your bus driver
you can easily get the address of the chip which sent it, but from
there, you have currently no way to callback the driver for that chip,
if any.

You would need to add a callback function in struct i2c_driver, I guess.
It's probably not too difficult but we need to agree on what exactly is
needed, so that we get it right at once.

-- 
Jean Delvare