`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=400kHzIt's more realistic to calculate with say 50ns < tr,tf < 300ns,than with tt = tf = 0ns or <20ns.  Even if with such real tf/trtimes, 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-modeFast 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-modef_SCL;max is defined as a resulting clock frequency with thecombination of:(1) the max. conditions of t_r and t_f(2) the min. conditions of t_HIGH and t_LOWWe can try to meet t_HIGH;min and t_LOW;min, but we can't meett_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 themaster and the board designs, hence necessarily contain sometime 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 fasterclock speed than f_SCL;max, then it's a bonus and we can acceptit 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`