Re: [PATCH v7 6/7] i2c: mediatek: Isolate speed setting via dts for special devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
> > 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~




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux