Messages in this thread | | | Date | Sat, 24 Aug 2013 13:58:47 +0900 | From | Shinya Kuribayashi <> | Subject | Re: [PATCH 1/2] i2c-designware: make *CNT values configurable |
| |
On 8/21/13 11:39 PM, Christian Ruppert wrote: > 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
It's more realistic to calculate with say 50ns < tr,tf < 300ns, than with tt = tf = 0ns or <20ns. Even if with such real tf/tr times, there is cases where f_SCL can be greater than 100/400Hz.
I understand what you mean, but that was not my point. See below.
>> 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.
With t_r;max and t_f;max,
Standard mode: t_r;max 1000ns (max time applied) t_f;max + 300ns (max time applied) t_HIGH;min + 4000ns t_LOW;min + 4700ns 1/f_SCL =10000ns ==> f_SCL = 100kHz ==> f_SCL;max for Standard-mode
Fast mode: t_r;max 300ns (max time applied) t_f;max + 300ns (max time applied) t_HIGH;min + 600ns t_LIW;min + 1300ns 1/f_SCL = 2500ns ==> f_SCL = 400kHz ==> f_SCL;max for Fast-mode
f_SCL;max is defined as a resulting clock frequency with the combination of:
(1) the max. conditions of t_r and t_f (2) the min. conditions of t_HIGH and t_LOW
We can try to meet t_HIGH;min and t_LOW;min, but we can't meet t_r;min nor t_f;min in the actual systems. The t_r and t_f are _minimum requisites_ for the I/O buffer characteristic of the master and the board designs, hence necessarily contain some time margin.
f_SCL is anything more than the resulting speed of (1) + (2), so I don't think we need to adjust HCNT/LCNT values at all. If with t_r < t_r;max and t_f < t_f;max, and you've got a faster clock speed than f_SCL;max, then it's a bonus and we can accept it gratefully.
>> 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.
I tried to write my thought down, not sure well-explained, though.
Notes:
* As long as tHD;SDA issue remains in the DW I2C core, we need to have t_HIGH with a relatively lager value than necessary. In such a case, the resulting f_SCL can never exceed f_SCL;max.
* I also wonder which values do you think should be adjusted to meet f_SCL;max, HCNT or LCNT, and why is that? I think it's hard to explain, isn't it?
Shinya
| |