> > Well, it's implicite... Check the i2c spec table 7 for speeds 3400 and > > 1700. If you use TRM calculcations so that tLow == tHigh you get too > > tLow that's below the minimum in both cases. So you must increase tLow, > > and when you do that you must make tHigh shorter, otherwise you don't > > match the rate. > > ... I didn't take a deep study but I did just skim a couple sections. > > And it looks like it I2C spec does NOT require the clock high/low to be > unbalanced (or balanced). It would seem to recommend it being unbalanced > because doing so should allow timing requirements to be more easily met for a > range of frequencies. This would allow a more general equation. > > In the end it is a question if rise/fall times and relative clock-line/data- > line requirements are met. > > It does seem to say in the spec that after 100pf of bus capacitance all bets > are off and you need to measure and degrade speed unit conditions are met. BTW, I'll reemphasize the controller bugs I pointed out last week are real and did impact a couple different boards. Adding those fixes made what once would trip up after a few million near-back-to-back read/writes work for with out error so far. I've not spent enough time on low/high to know anything absolutely. It does seem like a more board friendly way to go but may not be required. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
