Hi,
Sonasath, Moiz wrote:
From: Menon, Nishanth
Alexander Shishkin said the following on 12/17/2009 07:01 PM:
Well, I could calculate the timeout value based on current operating
speed,
I guess. Or a delay. Perhaps OMAP_I2C_TIMEOUT can be used here?
it might be an overkill trying to generate counter based on opp speeds.
wondering if this delay is required in the first place..
The reason why this timeout was not put in place was that if the I2C
controller is functional, the XUDF has to set after XRDY/XDR are set,
the only case where it might not be set is when there is a sudden
NACK | AL condition produced on the bus and the transfer stops
(thereby the FIFO is not getting empty). The code takes care of this
error situation so IMHO we can do without a timeout here.
We are able to reproduce an error situation, where none of XUDF|NACK|AL
gets set. In that case the kernel hangs. If we add the timeout, we are
able to recover. If you want to have a robust driver, you cannot have a
loop which is not guaranteed to terminate.
A.
--
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
