Messages in this thread | | | From | David Brownell <> | Subject | Re: Adding an async I2C interface | Date | Mon, 24 Jan 2005 08:36:38 -0800 |
| |
Quoth Corey Minyard: > I would really like add asynchronous interface to the I2C bus drivers.
Applause! This is IMO overdue, but maybe sensor systems don't need it as much as other I2C applications do. For example, see the isp1301_omap driver, which could have been hugely simpler if there were an async I2C framework to build on. That's probably one of the more complex examples floating around ... but it's hardly the only place where needing to talk synchronously to I2C chips creates trouble.
> I propose: > > * Adding an async send interface to the busses that does a callback > when the operation is complete.
It'd have to have a queue, so that several different chips could have operations pending concurrently. I suspect you wouldn't need to cancel operations once they're queued ... useful simplification, compared to for example USB. (Which in retrospect needs a "kill queue" operation, per endpoint, rather than the "cancel request" operation we've got. But when 2.2 started with USB, we didn't quite know that ... ;)
> * 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.
To the extent I've thought about it, that sounds like a good approach.
- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |