Adding an async I2C interface
mds4 at verizon.net
Fri Jan 28 01:18:28 CET 2005
is there a way to do this solely in i2c-core without having to
add support to all the drivers?
Corey Minyard wrote:
> I have an IPMI interface driver that sits on top of the I2C code. I'd
> like to get it into the mainstream kernel, but I have a few problems
> to solve first before I can do that. The I2C code is synchronous and
> must run from a task context. The IPMI driver has certain
> operations that occur at panic time, including:
> * Storing panic information in IPMI's system event log
> * Extending the watchdog timer so it doesn't go off during panic
> operations (like kernel coredumps).
> * Powering the system off
> I can't really put the IPMI SMB interface into the kernel until I can
> do those operations. Also, I understand that some vendors put RTC
> chips onto the I2C bus and this must be accessed outside task context,
> too. I would really like add asynchronous interface to the I2C bus
> drivers. I propose:
> * Adding an async send interface to the busses that does a callback
> when the operation is complete.
> * Adding a poll interface to the busses. The I2C core code could
> call this if a synchronous call is made from task context (much
> like all the current drivers do right now). For asyncronous
> operation, the I2C core code would call it from a timer
> interrupt. If the driver supported interrupts, polling from the
> timer interrupt would not be necessary.
> * Add async operations for the user to call, including access to the
> polling code.
> * If the driver didn't support an async send, it would work as it
> does today and the async calls would return ENOSYS.
> This way, the bus drivers on I2C could be converted on a
> driver-by-driver basis. The IPMI code could query to see if the
> driver supported async operations. And the RTC code could use it,
> Is this ok with the I2C community? I would do the base work and
> convert over a few drivers.
More information about the lm-sensors