Hi Samu, On Wed, 13 Oct 2010 16:45:08 +0300, Samu Onkalo wrote: > There are chips which doesn't work perfectly in certain > I2C operations. For example lp5523 led driver chip causes > always I2C timeout when SW reset is commanded to the chip. The timeout is a symptom as the controller level. What is the root cause at the LP5523 device level? What exactly happens on the wire? I am asking because maybe some of the already available protocol mangling flags would work for you, in particular I2C_M_IGNORE_NAK. See Documentation/i2c/i2c-protocol. > Patches add a possibility to tell that this access is likely > to cause time out and there is no need to wait normal time. > For example in omap time out is 1 second and the bus is reserved > all the time. You should ask yourself whether a 1 second timeout is a sane thing to have in the first place. You should also check why you hit the timeout condition. Ideally the hardware would report problems as they happen, quickly, rather than having to rely on the driver's timeout mechanism. The timeout should really only be a safety mechanism, for when the bus controller itself misbehaves at the hardware level. > By setting I2C_M_SHORT_TIMEOUT flag to i2c-message, adapter is > requested to use shorter timeout. > > Samu Onkalo (2): > drivers: i2c-core: Add a flag to allow short timeout > drivers: i2c-omap: Add support for shorten I2C timeout > > drivers/i2c/busses/i2c-omap.c | 9 ++++++++- > drivers/i2c/i2c-core.c | 2 +- > include/linux/i2c.h | 1 + > 3 files changed, 10 insertions(+), 2 deletions(-) I'm skeptical. If you know that the transfer will "fail" and you don't care, why do you want to wait a short time, rather than not waiting at all? -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
