lkml.org 
[lkml]   [2013]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] i2c-designware: make *CNT values configurable
Hi,

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. 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.

Is that clear? What is the point to make sure whether f_SCL
constraint is met or not? Is there any combination where t_f,
t_r, t_HIGH, t_LOW, t_HD;SATA are met, but f_SCL is out of range?
I don't think there is.

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.

Shinya


\
 
 \ /
  Last update: 2013-08-16 04:41    [W:0.205 / U:1.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site