Re: [PATCH][RFC] OMAP4: I2C Support for OMAP_4430SDP

[Nishanth Menon <menon.nishanth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Thu, Jun 4, 2009 at 4:41 PM, Jagadeesh Bhaskar Pakaravoor
<jagadeeshbp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> why is this 2600? omap3 could do 3.3Mhz.
>>
> There is a silicon issue reported on TWL5030 which says that it can
> not operate at the stipulated highest frequency of 3.3MHz.
>
> The information I got is this:
> "I2C data hold time in HS mode is higher than specification when
> reading I2C registers. This leads to a data setup issue which
> introduces a frequency limitation in HS mode (can not reach 3.4MHz as
> specified in I2C standard). The limitation is for the Control I2C, and
> for SmartReflex I2C when using other products than OMAP34xx with SR.
> HS mode is working OK for SR I2C when using OMAP34xx."
>
Is this bug valid for OMAP4 already :) ? Is'nt it a bit early to post
erratas  :D...
btw, the topic was on OMAP4 I2C.. the point i was driving at is this:
we need options to do:
A) provide speed parameter per bus at a board level (which is implemented now).
or
B) also provide flexibility, when so desired to provide scll and sch
values per bus for the board.

Rationale:
a) using i2c speed is not a scalable technique to handle varied i2c
bus conditions -> what if you have 1 foot wiring to the i2c device?
b) bus capacitance and other factors have to be considered.
c) we need some mechanism to allow a board specific configuration of
i2c scll sclh (fast and hs mode) to be configurable for platform bus
-> note, in a bus with multiple devices, you need to measure the least
common factor -> the default equations may not scale well.
d) At the same time, ability which is in the driver today -
essentially to be able to provide speed as a i2c module parameter
should be scaled accross when we provide flexibility for i2c scll and
sclh value configuration..
e) for boards which are fine with default equations, the current
mechanism of providing speeds as parameter should be retained.

Unless we ensure we do it as part of initial driver, we will fall into
OMAP3 trap of inflexibility.. just my 2 cents

Regards,
Nishanth Menon