RE: [pacth] I2C bug fixes for L-O and L-Z

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eero,

> > From: Eero Nurkkala [mailto:ext-eero.nurkkala@xxxxxxxxx]
>
> > On Mon, 2009-02-16 at 15:19 +0100, ext Woodruff, Richard wrote:
> > > Hi,
> > >
> > > > Could you please also address the question of the load on the SCL line?
> > >
> > > Are you talking about rise/fall time?
> > >
> > Sorry for being unclear;
> >
> > The I2C standard addresses also rise/fall times, but more interesting,
> > the tLow and tHigh (and a number of other parameters).
> >
> > It seems with the open source drivers, that somehow they're after a
> > "balanced I2C clock" meaning tLow == tHigh, which is very, very
> > dangerous.
>
> Oh, I see. I didn't look at that angle. I can inquire/look.
>
> For sure wave forms on O-Scope and LA showed variable data line times,
> sometimes longer then one would expect (for stop/start/ack).  But yes, clocks
> were pretty even iirc.

I received the following comment from a HW Apps person whom has dealt with this at the board level.

<comment start>
Attached is the I2C spec that I have.  As I understand it, the I2C only specify the minimum tLow and tHigh (which is not "balanced").  However what is more important is that the appropriate setup and hold time are followed.

If the equal time still meets the setup/hold time then there should not be any issue from a compliance standpoint.
<comment end>

Regards,
Richard W.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux