[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YaTMQQhENmJAIUk4@kunai>
Date: Mon, 29 Nov 2021 13:49:05 +0100
From: Wolfram Sang <wsa@...-dreams.de>
To: Kewei Xu <kewei.xu@...iatek.com>, matthias.bgg@...il.com,
robh+dt@...nel.org, linux-i2c@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
srv_heupstream@...iatek.com, leilk.liu@...iatek.com,
qii.wang@...iatek.com, liguo.zhang@...iatek.com,
caiyu.chen@...iatek.com, ot_daolong.zhu@...iatek.com,
yuhan.wei@...iatek.com
Subject: Re: [PATCH v7 6/7] i2c: mediatek: Isolate speed setting via dts for
special devices
> > 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.
>
> Isn't the new algorithm broken if it cannot support clock stretching?
> What was the problem of the old algorithm not meeting the 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."
>
> What I still do not get: the old algorithm was able to handle clock
> stretching. Why can't you update the new one to handle clock stretching
> as well. I might be missing something, but what is it?
I am still interested. Especially in the last question. Is the last
question clear to you? I can explain some more otherwise.
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists