From: "Bayi Cheng (程八意)" <bayi.cheng@mediatek.com>
To: "matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"ikjn@chromium.org" <ikjn@chromium.org>
Cc: "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [PATCH v1] spi: spi-mtk-nor: Unify write buffer on/off
Date: Mon, 21 Nov 2022 08:28:53 +0000 [thread overview]
Message-ID: <55717252d640f942a1e41d8b04c828e7fb0f57f4.camel@mediatek.com> (raw)
In-Reply-To: <20221115124655.10124-1-bayi.cheng@mediatek.com>
On Tue, 2022-11-15 at 20:46 +0800, Bayi Cheng wrote:
> From: bayi cheng <bayi.cheng@mediatek.com>
>
> The logical structures of mtk_nor_write_buffer_enable and
> mtk_nor_write_buffer_disable are very similar, So it is necessary to
> combine them into one.
>
> Signed-off-by: bayi cheng <bayi.cheng@mediatek.com>
> ---
> Change in v1:
> -Delete mtk_nor_write_buffer_enable.
> -Delete mtk_nor_write_buffer_disable.
> -Add mtk_nor_setup_write_buffer.
> ---
> ---
> drivers/spi/spi-mtk-nor.c | 40 ++++++++++++++++---------------------
> --
> 1 file changed, 16 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
> index d167699a1a96..e8b355f5be56 100644
> --- a/drivers/spi/spi-mtk-nor.c
> +++ b/drivers/spi/spi-mtk-nor.c
> @@ -443,36 +443,28 @@ static int mtk_nor_read_pio(struct mtk_nor *sp,
> const struct spi_mem_op *op)
> return ret;
> }
>
> -static int mtk_nor_write_buffer_enable(struct mtk_nor *sp)
> +static int mtk_nor_setup_write_buffer(struct mtk_nor *sp, bool on)
> {
> int ret;
> u32 val;
>
> - if (sp->wbuf_en)
> + if (!(sp->wbuf_en ^ on))
> return 0;
>
> val = readl(sp->base + MTK_NOR_REG_CFG2);
> - writel(val | MTK_NOR_WR_BUF_EN, sp->base + MTK_NOR_REG_CFG2);
> - ret = readl_poll_timeout(sp->base + MTK_NOR_REG_CFG2, val,
> - val & MTK_NOR_WR_BUF_EN, 0, 10000);
> - if (!ret)
> - sp->wbuf_en = true;
> - return ret;
> -}
> -
> -static int mtk_nor_write_buffer_disable(struct mtk_nor *sp)
> -{
> - int ret;
> - u32 val;
> + if (on) {
> + writel(val | MTK_NOR_WR_BUF_EN, sp->base +
> MTK_NOR_REG_CFG2);
> + ret = readl_poll_timeout(sp->base + MTK_NOR_REG_CFG2,
> val,
> + val & MTK_NOR_WR_BUF_EN, 0,
> 10000);
> + } else {
> + writel(val & ~MTK_NOR_WR_BUF_EN, sp->base +
> MTK_NOR_REG_CFG2);
> + ret = readl_poll_timeout(sp->base + MTK_NOR_REG_CFG2,
> val,
> + !(val & MTK_NOR_WR_BUF_EN), 0,
> 10000);
> + }
>
> - if (!sp->wbuf_en)
> - return 0;
> - val = readl(sp->base + MTK_NOR_REG_CFG2);
> - writel(val & ~MTK_NOR_WR_BUF_EN, sp->base + MTK_NOR_REG_CFG2);
> - ret = readl_poll_timeout(sp->base + MTK_NOR_REG_CFG2, val,
> - !(val & MTK_NOR_WR_BUF_EN), 0, 10000);
> if (!ret)
> - sp->wbuf_en = false;
> + sp->wbuf_en = on;
> +
> return ret;
> }
>
> @@ -482,7 +474,7 @@ static int mtk_nor_pp_buffered(struct mtk_nor
> *sp, const struct spi_mem_op *op)
> u32 val;
> int ret, i;
>
> - ret = mtk_nor_write_buffer_enable(sp);
> + ret = mtk_nor_setup_write_buffer(sp, true);
> if (ret < 0)
> return ret;
>
> @@ -501,7 +493,7 @@ static int mtk_nor_pp_unbuffered(struct mtk_nor
> *sp,
> const u8 *buf = op->data.buf.out;
> int ret;
>
> - ret = mtk_nor_write_buffer_disable(sp);
> + ret = mtk_nor_setup_write_buffer(sp, false);
> if (ret < 0)
> return ret;
> writeb(buf[0], sp->base + MTK_NOR_REG_WDATA);
> @@ -608,7 +600,7 @@ static int mtk_nor_exec_op(struct spi_mem *mem,
> const struct spi_mem_op *op)
> }
>
> if ((op->data.dir == SPI_MEM_DATA_IN) &&
> mtk_nor_match_read(op)) {
> - ret = mtk_nor_write_buffer_disable(sp);
> + ret = mtk_nor_setup_write_buffer(sp, false);
> if (ret < 0)
> return ret;
> mtk_nor_setup_bus(sp, op);
Hi Angelo, Hi David, Hi Matthias,
Just a gentle ping on this.
Could you please review this patch and give us some suggestion?
Thanks,
Bayi
next prev parent reply other threads:[~2022-11-21 8:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-15 12:46 [PATCH v1] spi: spi-mtk-nor: Unify write buffer on/off Bayi Cheng
2022-11-21 8:28 ` Bayi Cheng (程八意) [this message]
2022-11-28 16:19 ` Mark Brown
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=55717252d640f942a1e41d8b04c828e7fb0f57f4.camel@mediatek.com \
--to=bayi.cheng@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=broonie@kernel.org \
--cc=ikjn@chromium.org \
--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).