Hello,
Woodruff, Richard wrote:
Recently one custom board was having some I2C issues. In looking at it a couple
things stood out.
I've attached a patches for l-o and l-z for anyone to comment on which cares.
I hope these fixes are not ignored. Maybe they should be resent as they
are missing
ode/Oulu); linux-omap@vger.kernel.org
> Subject: RE: tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z)
>
>
>
> BTW, I'll reemphasize the controller bugs I pointed out last week are real
> and did impact a couple
> different boards. Adding those fixes made what once
> > Well, it's implicite... Check the i2c spec table 7 for speeds 3400 and
> > 1700. If you use TRM calculcations so that tLow == tHigh you get too
> > tLow that's below the minimum in both cases. So you must increase tLow,
> > and when you do that you must make tHigh shorter, otherwise you don't
> From: Aaro Koskinen [mailto:aaro.koski...@nokia.com]
> Sent: Tuesday, February 24, 2009 6:47 AM
> ext Nishanth Menon wrote:
> > Aaro Koskinen said the following on 02/24/2009 11:09 AM:
> >>> TRM:
> >>> tHigh = ( sclh +5 )*iclk period
> >>> tLow = ( scll +7 )*iclk period
> >>>
> >>> But my que
Hello,
ext Nishanth Menon wrote:
Aaro Koskinen said the following on 02/24/2009 11:09 AM:
TRM:
tHigh = ( sclh +5 )*iclk period
tLow = ( scll +7 )*iclk period
But my question is this: why are we trying to a different equation
here compared to the equation in the TRM?
The problem with TRM (th
Aaro Koskinen said the following on 02/24/2009 11:09 AM:
> ext Nishanth Menon wrote:
>> Oops.. copy-paste typo.. :(
>> tLow = (scll+3) * iclk
>> tHigh = (sclh+9) * iclk
>> Vs:
>> TRM:
>> tHigh = ( sclh +5 )*iclk period
>> tLow = ( scll +7 )*iclk period
>>
>> But my question is this: why are we tr
> The problem with Eero's patch is that it changes the internal clock
> (again thanks to that confusing table). You should be able to use same
> for all modes. Also note that the noise filter is one internel clock
> period. Currently the driver uses 19.2 MHz which exceeds the I2C spec
> max. So 24
Hello,
ext Nishanth Menon wrote:
Oops.. copy-paste typo.. :(
tLow = (scll+3) * iclk
tHigh = (sclh+9) * iclk
Vs:
TRM:
tHigh = ( sclh +5 )*iclk period
tLow = ( scll +7 )*iclk period
But my question is this: why are we trying to a different equation
here compared to the equation in the TRM?
Th
> So, it might be worth considering my following proposition?"
> 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 t
On Mon, Feb 23, 2009 at 8:27 PM, wrote:
>
>
>> ;) Aye Aye I wonder if the equation you provided is based on
>> emperical measurement? if so would it vary based on electrical
>> characteristics of a platform? I mean beagleboard Vs Zoom Vs SDP
>> atleast have variances of i2c trace lengths and
> ;) Aye Aye I wonder if the equation you provided is based on
> emperical measurement? if so would it vary based on electrical
> characteristics of a platform? I mean beagleboard Vs Zoom Vs SDP
> atleast have variances of i2c trace lengths and number of devices per
> i2c bus.. wont the equat
On Mon, Feb 23, 2009 at 8:20 PM, wrote:
>
> Don't just blindly trust the TRM, all that matters is the real signal
> caught in the scope. That is what you want to verify.
;) Aye Aye I wonder if the equation you provided is based on
emperical measurement? if so would it vary based on electrica
> But my question is this: why are we trying to a different equation
> here compared to the equation in the TRM?
Don't just blindly trust the TRM, all that matters is the real signal
caught in the scope. That is what you want to verify.
- Eero
--
To unsubscribe from this list: send the line "uns
On Mon, Feb 23, 2009 at 8:10 PM, wrote:
>> I am not entirely sure about the basis of Eero's equation:
>>
>> scll = (scl+3) * iclk
>> sclh = (scl+9) * iclk
>
> No, no:
>
> Exactly the opposite,
> + fsscll = internal_clk / (dev->speed * 2) - 3;
> + fssclh
> I am not entirely sure about the basis of Eero's equation:
>
> scll = (scl+3) * iclk
> sclh = (scl+9) * iclk
No, no:
Exactly the opposite,
+ fsscll = internal_clk / (dev->speed * 2) - 3;
+ fssclh = internal_clk / (dev->speed * 2) - 9;
means a longer
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.
>>
>>
>> Attached is the I2C spec that I have. As I understand
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.
>
>
> Attached is the I2C spec that I have. As I understand it, the I2C only
> specify the minimum tLow and tHigh (which is
Eero,
> > From: Eero Nurkkala [mailto:ext-eero.nurkk...@nokia.com]
>
> > 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
> From: Eero Nurkkala [mailto:ext-eero.nurkk...@nokia.com]
> 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;
>
> T
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 tL
Hi,
> Could you please also address the question of the load on the SCL line?
Are you talking about rise/fall time?
I can comment on bits I picked up reading and talking to others.
The current data sheets I looked at give a couple kinds of guidance for
resistor usage. One type has you measure
Could you please also address the question of the load on the SCL line?
In my understanding, many boards are using the experimental values
from TRM for SCLL, SCLH, HSSCLL and HSSCLH. I have notices that those
"default" values fail to provide a standard I2C clock for, at least,
boards that I have t
Hi,
Recently one custom board was having some I2C issues. In looking at it a couple
things stood out. I've attached a patches for l-o and l-z for anyone to
comment on which cares.
Bug Fixes:
-1- OMAP_I2C_WE_STC_WE should never be enabled for wake up unless I+F
clk is cut. Having it
23 matches
Mail list logo
