On 03/30/2012 06:06 AM, Alok Chauhan wrote: > In NACK error condition, I2C controller violates > clock-to-data setup time before stop. In Software, > because of this reset of controller is happening > before I2C controller could complete STOP condition. I'm not quite sure this description is correct. Surely what's happening is simply that the controller raises the NACK interrupt as soon as it detects a NACK condition. Then, the controller generates the STOP condition on the bus correctly. The issue is that if software resets the controller as soon as the NACK interrupt is raised, this will happen before the controller has completely delivered the STOP condition onto the bus, so we need to pause and wait for that? I think the commit description and comment in the code should be reworded to describe what I wrote above, assuming it's accurate. Is there really no idle bit we can poll in the I2C controller to determine when the STOP has completed, rather than just delaying a "hard-coded" time? Can I2C SCL clock-stretching affect the amount of time that must be delayed? -- 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
