From: "Bayi Cheng (程八意)" <bayi.cheng@mediatek.com>
To: "angelogioacchino.delregno@collabora.com"
<angelogioacchino.delregno@collabora.com>,
"David.Laight@ACULAB.COM" <David.Laight@ACULAB.COM>,
"broonie@kernel.org" <broonie@kernel.org>
Cc: "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"gch981213@gmail.com" <gch981213@gmail.com>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [PATCH v1] spi: spi-mtk-nor: Optimize timeout for dma read
Date: Sat, 12 Nov 2022 06:06:49 +0000 [thread overview]
Message-ID: <e546de4ea3b1e29da6f9cdf56c8bf1582b70944e.camel@mediatek.com> (raw)
In-Reply-To: <34de22c0-1773-10b4-c3fd-387fd311ac11@collabora.com>
On Fri, 2022-11-11 at 10:16 +0100, AngeloGioacchino Del Regno wrote:
> Il 11/11/22 05:16, Bayi Cheng (程八意) ha scritto:
> > On Fri, 2022-11-04 at 07:53 +0000, Bayi Cheng (程八意) wrote:
> > > On Thu, 2022-11-03 at 22:35 +0000, David Laight wrote:
> > > > From: AngeloGioacchino Del Regno
> > > > > Sent: 03 November 2022 09:44
> > > > >
> > > > > Il 03/11/22 06:28, Bayi Cheng ha scritto:
> > > > > > From: bayi cheng <bayi.cheng@mediatek.com>
> > > > > >
> > > > > > The timeout value of the current dma read is unreasonable.
> > > > > > For
> > > > > > example,
> > > > > > If the spi flash clock is 26Mhz, It will takes about 1.3ms
> > > > > > to
> > > > > > read a
> > > > > > 4KB data in spi mode. But the actual measurement exceeds
> > > > > > 50s
> > > > > > when
> > > > > > a
> > > > > > dma read timeout is encountered.
> > > > > >
> > > > > > In order to be more accurately, It is necessary to use
> > > > > > msecs_to_jiffies,
> > > > > > After modification, the measured timeout value is about
> > > > > > 130ms.
> > > > > >
> > > > > > Signed-off-by: bayi cheng <bayi.cheng@mediatek.com>
> > > > > > ---
> > > > > > drivers/spi/spi-mtk-nor.c | 7 ++++---
> > > > > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-
> > > > > > mtk-
> > > > > > nor.c
> > > > > > index d167699a1a96..3d989db80ee9 100644
> > > > > > --- a/drivers/spi/spi-mtk-nor.c
> > > > > > +++ b/drivers/spi/spi-mtk-nor.c
> > > > > > @@ -354,7 +354,7 @@ static int mtk_nor_dma_exec(struct
> > > > > > mtk_nor
> > > > > > *sp, u32 from, unsigned int length,
> > > > > > dma_addr_t dma_addr)
> > > > > > {
> > > > > > int ret = 0;
> > > > > > - ulong delay;
> > > > > > + ulong delay, timeout;
> > > > > > u32 reg;
> > > > > >
> > > > > > writel(from, sp->base + MTK_NOR_REG_DMA_FADR);
> > > > > > @@ -376,15 +376,16 @@ static int mtk_nor_dma_exec(struct
> > > > > > mtk_nor
> > > > > > *sp, u32 from, unsigned int length,
> > > > > > mtk_nor_rmw(sp, MTK_NOR_REG_DMA_CTL, MTK_NOR_DMA_START,
> > > > > > 0);
> > > > > >
> > > > > > delay = CLK_TO_US(sp, (length + 5) * BITS_PER_BYTE);
> > > > > > + timeout = (delay + 1) * 100;
> > > > > >
> > > > > > if (sp->has_irq) {
> > > > > > if (!wait_for_completion_timeout(&sp->op_done,
> > > > > > - (delay + 1) *
> > > > > > 100))
> > > > > > + msecs_to_jiffies(max_t(size_t, timeout /
> > > > > > 1000,
> > > > > > 10))))
> > > > >
> > > > > You're giving a `size_t` variable to msecs_to_jiffies(), but
> > > > > checking `jiffies.h`,
> > > > > this function takes a `const unsigned int` param.
> > > > > Please change the type to match that.
> > > >
> > > > The type shouldn't matter at all.
> > > > What matters is the domain of the value.
> > > >
> > > > Quite why you need to use max_t(size_t, ...) is another matter.
> > > > timeout is ulong so max(timeout/1000, 10ul) should be fine.
> > > >
> > > > But is ulong even right?
> > > > The domain of the value is almost certainly the same on 32bit
> > > > and
> > > > 64bit.
> > > > So you almost certainly need u32 or u64.
> > > >
> > > > David
> > > >
> > >
> > > Hi David & Angelo
> > >
> > > Thank you for your comments!
> > > To sum up, I think the next version will make the following two
> > > changes:
> > > 1, The timeout value will not exceed u32, so the type of timeout
> > > will
> > > be changed from ulong to u32.
> > > 2, Change msecs_to_jiffies(max_t(size_t, timeout / 1000, 10)) to
> > > be
> > > msecs_to_jiffies(max(timeout / 1000, 10U)).
> > >
> > > If you think these changes are not enough, please let me know,
> > > Thanks!
> > >
> > > Best Regards,
> > > Bayi
> > >
> >
> > Hi Angelo, Hi David,
> >
> > Just a gentle ping on this.
> > Could you please review this patch and give us some suggestion?
> >
> > PS: With your permission, I will make the following changes in the
> > next
> > version:
> >
> > Change in v2:
> > -Change the type of "timeout" from ulong to u32.
> > -Replace max_t with max.
> >
>
> I still recommend to use usecs_to_jiffies() when appropriate, instead
> of
> converting usecs to msecs and using msecs_to_jiffies().
>
> As for the rest in your list: yes, please.
>
> Regards,
> Angelo
>
Hi Angelo,
Thanks for your comments!
I will change it to be usecs_to_jiffies(max(timeout, 10000U)) in the
next patch.
BRs,
Bayi Cheng
> >
> > Thanks.
> >
> > BRs,
> > Bayi Cheng
> >
> > > > >
> > > > > Aside from that, your `timeout` variable contains a timeout
> > > > > in
> > > > > microseconds and
> > > > > this means that actually using msecs_to_jiffies() is
> > > > > suboptimal
> > > > > here.
> > > > >
> > > > > Please use usecs_to_jiffies() instead.
> > > > >
> > > > > Regards,
> > > > > Angelo
> > > >
> > > > -
> > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton
> > > > Keynes,
> > > > MK1 1PT, UK
> > > > Registration No: 1397386 (Wales)
>
>
next prev parent reply other threads:[~2022-11-12 6:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-03 5:28 [PATCH v1] spi: spi-mtk-nor: Optimize timeout for dma read Bayi Cheng
2022-11-03 5:28 ` Bayi Cheng
2022-11-03 9:43 ` AngeloGioacchino Del Regno
2022-11-03 22:35 ` David Laight
2022-11-04 7:53 ` Bayi Cheng (程八意)
2022-11-11 4:16 ` Bayi Cheng (程八意)
2022-11-11 9:16 ` AngeloGioacchino Del Regno
2022-11-12 6:06 ` Bayi Cheng (程八意) [this message]
2022-11-03 5:43 ` Allen-KH Cheng (程冠勳)
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=e546de4ea3b1e29da6f9cdf56c8bf1582b70944e.camel@mediatek.com \
--to=bayi.cheng@mediatek.com \
--cc=David.Laight@ACULAB.COM \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=broonie@kernel.org \
--cc=gch981213@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=matthias.bgg@gmail.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).