public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <menon.nishanth@gmail.com>
To: ext-eero.nurkkala@nokia.com
Cc: "ext Woodruff, Richard" <r-woodruff2@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z)
Date: Mon, 23 Feb 2009 19:01:35 +0200	[thread overview]
Message-ID: <49A2D66F.9050809@gmail.com> (raw)
In-Reply-To: <1235396273.12653.8.camel@eenurkka-desktop>

Eero Nurkkala said the following on 02/23/2009 03:37 PM:
> On Fri, 2009-02-20 at 21:59 +0100, ext Woodruff, Richard wrote:
>   
>> 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.
>>     
> With out board, the tLow and tHigh values are in line with I2C standard
> with the patch:
> http://marc.info/?l=linux-omap&m=122770723311340&w=2
>
> Would that risk the setup and hold times? (If I remember correctly, the
> values (setup, hold) were within the I2C standard even with the patch.)
>
> I think it's a risk not to meet tLow and tHigh. I'm saying, with open
> source values with our board, the tLow was not in standard. If using
> TRM minimum values, things get even worse. Why? because it states, for
> example, Fast Mode SCLL = 5 and SCLH = 7. This means that the low
> period is smaller than the high! Shouldn't it be vice versa? (scope
> verified).
>   
just couple of views: (Disclaimer - it might be good if someone could re
validate my math :( )..
a) tHigh and tLow could be device dependent. for an I2C bus with
multiple devices, we probably need a common denominator. the question is
- is there a min and max for the tHigh and tLow? some of the datasheets
I have seen seem to have this.
b) the drivers/i2c/busses/i2c-omap.c does computation based on
dev->speed. the equation is based on:
tHigh  = ( sclh +6 )*iclk period
tLow  = ( scll +6 )*iclk period
the TRM ([2] table18-12(page 2942)) instead speaks of:
tHigh  = ( sclh +5 )*iclk period
tLow  = ( scll +7 )*iclk period
current i2c driver attempts to put the same value to scll and sclh reg.
The result would be that tHigh != tLow, unless I am missing something.

I am not entirely sure about the basis of Eero's equation:

scll = (scl+3) * iclk
sclh = (scl+9) * iclk


Now computing a bit, i2c spec [1] says in table 5 for minimum for FS as
tLow as 1.3uS and tHigh as 0.6uS. max is not mentioned :(.. OMAP3430 TRM
([2] table 18-13 (page 2943)) says:
psc=9, scl = 5, sch =7 - for fclk = 96Mhz.
translating this:
iclk =96M/(9+1) = 9.6Mhz = 0.104167uSec.
tHigh  = ( sclh +5 )*iclk = (7+5)*0.104167 = 1.250004 uSec (spec min is
0.6uSec)
tLow  = ( scll +7 )*iclk =(5+7)*0.104167 = 1.250004 uSec (spec min is
1.3uSec <== I might be missing something here - but does that look like
some sort of violation?

Now, from a s/w perspective, If we would like to have it so that we can
configure tHigh and tLow based on devices, electrical characteristics on
a bus, not just speed of the bus, the current implementation would
probably need to change(I think).

Regards,
Nishanth Menon

Ref:
[1] http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf
[2] http://focus.ti.com/pdfs/wtbu/SWPU114I_PrelimFinalEPDF_06_10_2008.pdf

  reply	other threads:[~2009-02-23 17:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-16  7:02 [pacth] I2C bug fixes for L-O and L-Z Eero Nurkkala
2009-02-16 14:19 ` Woodruff, Richard
2009-02-17  6:02   ` Eero Nurkkala
2009-02-17  6:22     ` Woodruff, Richard
2009-02-20 20:59       ` Woodruff, Richard
2009-02-23 13:37         ` Eero Nurkkala
2009-02-23 17:01           ` Nishanth Menon [this message]
2009-02-23 18:10             ` tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z) ext-Eero.Nurkkala
2009-02-23 18:19               ` Nishanth Menon
2009-02-23 18:20                 ` ext-Eero.Nurkkala
2009-02-23 18:25                   ` Nishanth Menon
2009-02-23 18:27                     ` ext-Eero.Nurkkala
2009-02-23 18:34                       ` Nishanth Menon
2009-02-23 18:38                         ` ext-Eero.Nurkkala
2009-02-24  9:09                 ` Aaro Koskinen
2009-02-24  9:43                   ` ext-Eero.Nurkkala
2009-02-24 11:43                   ` Nishanth Menon
2009-02-24 12:47                     ` Aaro Koskinen
2009-02-24 12:57                       ` Woodruff, Richard
2009-02-24 13:17                       ` Woodruff, Richard
2009-02-24 13:23                         ` Pakaravoor, Jagadeesh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49A2D66F.9050809@gmail.com \
    --to=menon.nishanth@gmail.com \
    --cc=ext-eero.nurkkala@nokia.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=r-woodruff2@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox