[i2c] linux-i2c and smbalert

[Hendrik Sattler]

Am Freitag 25 August 2006 22:03 schrieb Jean Delvare:
> 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.

Yeah, right, it's i2c_i801.

> > 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.

Still, polling a memory-mapped register is far cheaper that polling via
i2c commands. Note that for i801, this can be done via polling the HST_STA bit 
5.

> 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.

I had hope that it would be the natural goal of drivers to be interrupt 
driven. After all, polling is the worst case for a driver, isn't it?

> 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.

Well, receiving the address should be done by i2c/smbus core to reduce code 
duplication. The bus driver only has to call that function. If a controller 
does this internally, it simply does not call that function but only the 
notifier.
That also means that finding the right i2c_client struct can be fully 
internal.

> 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.

calling it
 void (*smbus_alert) (struct i2c_client*)
seems the most natural thing. It would make clear that it is for smbus devices 
only.

I attached a simple patch that should work (well, it compiles). I did not 
implemented it for any bus or chip driver, thus it is untested. But maybe you 
can take a look at it. 10bit adress reading is not supported (only the 1.0 
spec tells about it), not sure how to read 2 or 1 byte from smbus (block 
read?).

The patch for i2c_i801 will follow based on this one. It is a bit tricky as 
the polled read/write from the register from a timer should be secured by a 
mutex to not interfere with the main transaction function.

HS

PS: I am not subscribed so please CC me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smbalert.patch
Type: text/x-diff
Size: 2945 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/i2c/attachments/20060826/0ab36ff9/attachment.bin