On Fri, Aug 16, 2013 at 11:15:12AM +0900, Shinya Kuribayashi wrote:On 8/5/13 6:31 PM, Christian Ruppert wrote:On Wed, Jul 24, 2013 at 11:31:44PM +0900, Shinya Kuribayashi wrote:As said before, all t_SCL things should go away. Please forget
about 100kbps, 400kbps, and so on. Bus/clock speed is totally
pointless concept for the I2C bus systems. For example, as long
as tr/tf, tHIGH/tLOW, tHD;STA, etc. are met by _all_ devices in a
certain I2C bus, it doesn't matter that the resulting clock speed
is, say 120 kbps with Standard-mode, or even 800 kbps for Fast-mode.
Nobody in the I2C bus doesn't care about actual bus/clock speed.
We don't have to care about the resulting bus speed, or rather
we should/must not check to see if it's within the proper range.
Actually, the I2C specification clearly defines f_SCL;max (and thus
implies t_SCL;min), both in the tables and the timing diagrams. Why can
we ignore this constraint while having to meet all the others?
If we meet t_r, t_f, t_HIGH, t_LOW (and t_HIGH in this DW case),
f_SCL;max will be met by itself.
I'm not sure if I agree with this:
Standard mode:
t_r;min 0ns
t_f;min + 0ns
t_HIGH;min + 4000ns
t_LOW;min + 4700ns
1/f_SCL = 8700ns
==> f_SCL = 115kHz ==> violation of f_SCL;max=100kHz
Fast mode (let's assume V_DD = 5.5V):
t_r;min 20ns
t_f;min + 20ns
t_HIGH;min + 600ns
t_LIW;min + 1300ns
1/f_SCL = 1940ns
==> f_SCL = 515kHz ==> violation of f_SCL;max=400kHz
And again, all I2C master and
slave devices in the bus don't care about f_SCL; what they do care
are t_f, t_r, t_HIGH, t_LOW, and so on. That's why I'm saying
f_SCL is pointless and has no value for HCNT/LCNT calculations.
I partially agree: If I2C devices don't care about f_SCL but only about
t_r, t_f, t_HIGH and t_LOW there's no need to respect the f_SCL;max
constraint. If this is the case, I'm wondering why it is part of the
specification, though.
I'd make a compromise proposal; it's fine to make sure whether the
resulting f_SCL is within a supported range, but should not make a
correction of HCNT/LCNT values. Just report warning messages that
some parameters/calculations might be mis-configured an/or wrong.
Not sure if this is a good idea: If f_SCL is met by design I'm perfectly
happy with dropping the t_HIGH/t_LOW adjustment code, no need to bloat
the kernel with confusing warnings. If f_SCL is not automatically met we
must either make sure t_HIGH/t_LOW are adjusted or we must take the
decision to ignore that constraint and document the reasons behind that
decision accordingly.