All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.