From: Kewei Xu <kewei.xu@mediatek.com>
To: Wolfram Sang <wsa@the-dreams.de>, <matthias.bgg@gmail.com>,
<robh+dt@kernel.org>, <linux-i2c@vger.kernel.org>,
<devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>,
<srv_heupstream@mediatek.com>, <leilk.liu@mediatek.com>,
<qii.wang@mediatek.com>, <liguo.zhang@mediatek.com>,
<caiyu.chen@mediatek.com>, <ot_daolong.zhu@mediatek.com>,
<yuhan.wei@mediatek.com>
Subject: Re: [PATCH v7 6/7] i2c: mediatek: Isolate speed setting via dts for special devices
Date: Sat, 18 Dec 2021 17:44:32 +0800 [thread overview]
Message-ID: <dfd50de5149a38ad1bc5faf9bb26a8a04be7d314.camel@mediatek.com> (raw)
In-Reply-To: <YaTMQQhENmJAIUk4@kunai>
On Mon, 2021-11-29 at 13:49 +0100, Wolfram Sang wrote:
> > > 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.
>
Hi,Wolfram,
I'm very sorry that I didn't reply to your information in time due
to my many personal affairs.
The Old algorithm was designed to focus only on normal functions, and
need to add additional custom code to adjust ac-timing when the
communication timing did not meet the specifications. so when there is
no clock stretch, ac-timing does not meet the spec, but the function is
always normal.
The new algorithm(The commit patch: be5ce0e97cc7 ("i2c: mediatek: Add
i2c ac-timing adjust support") is based on the requirements of i2c spec
to calculate the hardware-related settings so that the function and ac-
timing are normal When there is no clock stretch or the clock stretch
time is short. When the stretching time is very long (>60us), i2c ac-
timing does not meet the specifications and causes function abnormal.
In order to make the i2c function normal, this patch was submitted,
that is, when the stretch is long, the old algorithm is used to ensure
the function is normal, and when the stretch is short, the new
algorithm is used to ensure that the ac-timing and function are normal.
We found that when the ac-timing calculation formula is updated, the
new algorithm can make i2c ac-timing meet the spec and function
normally. So we plan to replace this patch with a patch that updates
the calculation formula.
Thanks~
Kewei
next prev parent reply other threads:[~2021-12-18 9:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 10:14 [PATCH v7 0/7] Introducing an attribute to select the time setting Kewei Xu
2021-09-17 10:14 ` [PATCH v7 1/7] i2c: mediatek: fixing the incorrect register offset Kewei Xu
2021-10-02 6:28 ` Wolfram Sang
2021-09-17 10:14 ` [PATCH v7 2/7] i2c: mediatek: Reset the handshake signal between i2c and dma Kewei Xu
2021-10-02 6:30 ` Wolfram Sang
2021-10-08 6:19 ` Kewei Xu
2021-09-17 10:14 ` [PATCH v7 3/7] i2c: mediatek: Dump i2c/dma register when a timeout occurs Kewei Xu
2021-10-02 6:37 ` Wolfram Sang
2021-10-08 7:13 ` Kewei Xu
2021-09-17 10:14 ` [PATCH v7 4/7] dt-bindings: i2c: add attribute use-default-timing Kewei Xu
2021-09-17 10:14 ` [PATCH v7 5/7] i2c: mediatek: Add OFFSET_EXT_CONF setting back Kewei Xu
2021-10-02 6:40 ` Wolfram Sang
2021-09-17 10:14 ` [PATCH v7 6/7] i2c: mediatek: Isolate speed setting via dts for special devices Kewei Xu
2021-10-02 6:40 ` Wolfram Sang
2021-10-08 8:47 ` Kewei Xu
2021-10-11 10:56 ` Wolfram Sang
2021-11-29 12:49 ` Wolfram Sang
2021-12-18 9:44 ` Kewei Xu [this message]
2021-12-18 10:17 ` Wolfram Sang
2021-09-17 10:14 ` [PATCH v7 7/7] i2c: mediatek: modify bus speed calculation formula Kewei Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dfd50de5149a38ad1bc5faf9bb26a8a04be7d314.camel@mediatek.com \
--to=kewei.xu@mediatek.com \
--cc=caiyu.chen@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=leilk.liu@mediatek.com \
--cc=liguo.zhang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=ot_daolong.zhu@mediatek.com \
--cc=qii.wang@mediatek.com \
--cc=robh+dt@kernel.org \
--cc=srv_heupstream@mediatek.com \
--cc=wsa@the-dreams.de \
--cc=yuhan.wei@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).