[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YWQYbaTIhud2QHNP@kunai>
Date: Mon, 11 Oct 2021 12:56:45 +0200
From: Wolfram Sang <wsa@...-dreams.de>
To: Kewei Xu <kewei.xu@...iatek.com>
Cc: 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
Hi,
> 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?
Happy hacking,
Wolfram
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists