On Thu, 13 Jan 2011 12:07:34 -0500, Devin Heitmueller wrote: > On Thu, Jan 13, 2011 at 11:48 AM, Jean Delvare <khali@xxxxxxxxxxxx> wrote: > > On Thu, 13 Jan 2011 11:34:42 -0500, Andy Walls wrote: > >> How should clock stretches by slaves be handled using i2c-algo-bit? > > > > It is already handled. But hdpvr-i2c doesn't use i2c-algo-bit. I2C > > support is done with USB commands instead. Maybe the hardware > > implementation doesn't support clock stretching by slaves. Apparently > > it doesn't support repeated start conditions either, so it wouldn't > > surprise me. > > The hardware implementation does support clock stretching, or else it > wouldn't be working under Windows. I think your conclusion is too fast and possibly incorrect. The traces Andy pointed us too earlier suggest that the windows driver is also "polling" the Zilog after the send operation to figure out when it is available again. If the Zilog was stretching the clock and the master was seeing that, it wouldn't return until the clock is released, so no polling would be necessary. So, either the Zilog isn't stretching the clock in the standard way, or the master doesn't notice. > That said, it's possible that the > driver for the i2c master isn't checking the proper bits to detect the > clock stretch. I haven't personally looked at the code for the i2c > master, so I cannot say one way or the other. If you're talking about hdpvr-i2c, it's sending USB commands, so it doesn't seem like we have much control over what happens behind the scene. If there is any way to improve its reliability, that will require external knowledge. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
