On Thu, Jul 11, 2013 at 10:36:00AM +0300, Mika Westerberg wrote: > On Wed, Jul 10, 2013 at 06:56:35PM +0200, Christian Ruppert wrote: > > On Wed, Jul 10, 2013 at 01:52:15PM +0300, Mika Westerberg wrote: > > > On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian Ruppert wrote: > > > > What I meant is the following: The clock cycle time Tc is composed of > > > > the four components > > > > > > > > Tc = Th + Tf + Tl + Tr > > > > > > > > where > > > > Th: Time during which the signal is high > > > > Tf: Falling edge transition time > > > > Tl: Time during which the signal is low > > > > Tr: Rising edge transition time > > > > > > > > The I2C specification specifies a minimum for Tl and Th and a range (or > > > > maximum) for Tr and Tf. A maximum frequency is specified as the > > > > frequency obtained by adding the minima for Th and Tl to the maxima of > > > > Tr ant Tf. > > > > Since as you said, transition times are very much PCB dependent, one way > > > > to guarantee the max. frequency constraint (and to achieve a constant > > > > frequency at its max) is to define the constants > > > > Th' = Th + Tf := Th_min + Tf_max > > > > Tl' = Tl + Tr := Tl_min + Tr_max > > > > > > > > and to calculate the variables > > > > Th = Th' - Tf > > > > Tl = Tl' - Tr > > > > in function of Tf and Tr of the given PCB. > > > > > > If I understand the above, it leaves Tf and Tr to be PCB specific and then > > > these values are passed to the core driver from platform data, right? > > > > That would be the idea: Calculate Th' and Tl' in function of the desired > > clock frequency and duty cycle and then adapt these values using > > measured transition times. What prevented me from implementing this > > rather academic approach are the following comments in > > i2c-designware-core.c: > > > > /* > > * DesignWare I2C core doesn't seem to have solid strategy to meet > > * the tHD;STA timing spec. Configuring _HCNT based on tHIGH spec > > * will result in violation of the tHD;STA spec. > > */ > > > > /* ... > > * This is just experimental rule; the tHD;STA period > > * turned out to be proportinal to (_HCNT + 3). With this setting, > > * we could meet both tHIGH and tHD;STA timing specs. > > * ... > > */ > > > > If I interpret this right, the slow down of the clock is intentional to > > meet tHD;STA timing constraints. > > Yeah, looks like so. tHD;STA is the SDA hold time. I wonder if the above > comments apply to some earlier version of the IP that didn't have the SDA > hold register? Scratch that. I re-read the spec and tHD;STA is hold time for (repeated) start. There is a constraint that says that the device must internally provide a hold time of at least 300ns for the SDA signal. Maybe that's the constraint the comment above is referring to? -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
