On Thu, Jun 4, 2009 at 4:41 PM, Jagadeesh Bhaskar Pakaravoor <jagadees...@gmail.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
