On Sat, 2021-10-02 at 08:40 +0200, Wolfram Sang wrote:

On Fri, Sep 17, 2021 at 06:14:15PM +0800, Kewei Xu wrote:

quoted

In the commit be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing
adjust
support"), the I2C timing calculation has been revised to support
ac-timing adjustment, however that will break on some I2C
components.
As a result we want to introduce a new setting "default-adjust-
timing"
so those components can choose to use the old (default) timing
algorithm.

Why can't the new calculation be updated in a way that it works for
all
I2C components?

Hi, In the commit be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing
adjust support"), the I2C timing calculation has been revised to
support ac-timing adjustment.But in our design, it will make
tSU,STA/tHD,STA/tSU,STO shorter when the slave device have clock-
stretching feature. Then we upload the commit a80f24945fcf ("i2c:
mediatek: Use scl_int_delay_ns to compensate clock-stretching") to
support adjusting tSU,STA/tHD,STA/tSU,STO when the slave device clock-
stretching. But if the slave device stretch the SCL line for too long
time, our design still cannot make tSU,STA/tHD,STA/tSU,STO meet spec.
However in the old (default) timing algorithm before the commit
be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing adjust support"),
tSU,STA/tHD,STA/tSU,STO can meet spec. So we want to define a new
setting "default-adjust-timing" for using the old (default) timing
algorithm. Thanks~
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel