From: Michael Walle <mwalle@kernel.org>
To: Jaime Liao <jaimeliao.tw@gmail.com>
Cc: linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org,
tudor.ambarus@linaro.org, pratyush@kernel.org,
miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
broonie@kernel.org, leoyu@mxic.com.tw, jaimeliao@mxic.com.tw
Subject: Re: [PATCH v8 5/9] spi: mxic: Add support for swapping byte
Date: Thu, 01 Feb 2024 16:39:32 +0100 [thread overview]
Message-ID: <8e834cd19cf896d792a0338a3fb5465c@kernel.org> (raw)
In-Reply-To: <20240201094353.33281-6-jaimeliao.tw@gmail.com>
Hi,
> From: JaimeLiao <jaimeliao@mxic.com.tw>
>
> Some SPI-NOR flash swap the bytes on a 16-bit boundary when
> configured in Octal DTR mode. It means data format D0 D1 D2 D3
> would be swapped to D1 D0 D3 D2. So that whether controller
> support swapping bytes should be checked before enable Octal
> DTR mode. Add swap byte support on a 16-bit boundary when
> configured in Octal DTR mode for Macronix xSPI host controller
> dirver.
>
> According dtr_swab in operation to enable/disable Macronix
> xSPI host controller swap byte feature.
>
> To make sure swap byte feature is working well, program data in
> 1S-1S-1S mode then read back and compare read data in 8D-8D-8D
> mode.
>
> This feature have been validated on byte-swap flash and
> non-byte-swap flash.
>
> Macronix xSPI host controller bit "HC_CFG_DATA_PASS" determine
> the byte swap feature disabled/enabled and swap byte feature is
> working on 8D-8D-8D mode only.
>
> Suggested-by: Michael Walle <mwalle@kernel.org>
> Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
> ---
> drivers/spi/spi-mxic.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
> index 60c9f3048ac9..8ac302e48c9f 100644
> --- a/drivers/spi/spi-mxic.c
> +++ b/drivers/spi/spi-mxic.c
> @@ -294,7 +294,8 @@ static void mxic_spi_hw_init(struct mxic_spi *mxic)
> mxic->regs + HC_CFG);
> }
>
> -static u32 mxic_spi_prep_hc_cfg(struct spi_device *spi, u32 flags)
> +static u32 mxic_spi_prep_hc_cfg(struct spi_device *spi, u32 flags,
> + bool swap16)
> {
> int nio = 1;
>
> @@ -305,6 +306,11 @@ static u32 mxic_spi_prep_hc_cfg(struct spi_device
> *spi, u32 flags)
> else if (spi->mode & (SPI_TX_DUAL | SPI_RX_DUAL))
> nio = 2;
>
> + if (!swap16)
> + flags |= HC_CFG_DATA_PASS;
> + else
> + flags &= ~HC_CFG_DATA_PASS;
Again, not my driver and I don't care too much, but you are changing
the behavior of this driver. If I had to guess, with this patch applied,
you'd read data (in octal mode) with the bytes swapped compared to
kernel
without this patch.
And compared to the former version, you just made it harder to read
by using negated logic.
-michael
> +
> return flags | HC_CFG_NIO(nio) |
> HC_CFG_TYPE(spi_get_chipselect(spi, 0), HC_CFG_TYPE_SPI_NOR) |
> HC_CFG_SLV_ACT(spi_get_chipselect(spi, 0)) |
> HC_CFG_IDLE_SIO_LVL(1);
> @@ -397,7 +403,8 @@ static ssize_t mxic_spi_mem_dirmap_read(struct
> spi_mem_dirmap_desc *desc,
> if (WARN_ON(offs + desc->info.offset + len > U32_MAX))
> return -EINVAL;
>
> - writel(mxic_spi_prep_hc_cfg(desc->mem->spi, 0), mxic->regs + HC_CFG);
> + writel(mxic_spi_prep_hc_cfg(desc->mem->spi, 0,
> desc->info.op_tmpl.data.swap16),
> + mxic->regs + HC_CFG);
>
> writel(mxic_spi_mem_prep_op_cfg(&desc->info.op_tmpl, len),
> mxic->regs + LRD_CFG);
> @@ -441,7 +448,8 @@ static ssize_t mxic_spi_mem_dirmap_write(struct
> spi_mem_dirmap_desc *desc,
> if (WARN_ON(offs + desc->info.offset + len > U32_MAX))
> return -EINVAL;
>
> - writel(mxic_spi_prep_hc_cfg(desc->mem->spi, 0), mxic->regs + HC_CFG);
> + writel(mxic_spi_prep_hc_cfg(desc->mem->spi, 0,
> desc->info.op_tmpl.data.swap16),
> + mxic->regs + HC_CFG);
>
> writel(mxic_spi_mem_prep_op_cfg(&desc->info.op_tmpl, len),
> mxic->regs + LWR_CFG);
> @@ -518,7 +526,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem
> *mem,
> if (ret)
> return ret;
>
> - writel(mxic_spi_prep_hc_cfg(mem->spi, HC_CFG_MAN_CS_EN),
> + writel(mxic_spi_prep_hc_cfg(mem->spi, HC_CFG_MAN_CS_EN,
> op->data.swap16),
> mxic->regs + HC_CFG);
>
> writel(HC_EN_BIT, mxic->regs + HC_EN);
> @@ -572,6 +580,7 @@ static const struct spi_controller_mem_ops
> mxic_spi_mem_ops = {
>
> static const struct spi_controller_mem_caps mxic_spi_mem_caps = {
> .dtr = true,
> + .swap16 = true,
> .ecc = true,
> };
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2024-02-01 15:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-01 9:43 [PATCH v8 0/9] Add octal DTR support for Macronix flash Jaime Liao
2024-02-01 9:43 ` [PATCH v8 1/9] mtd: spi-nor: add Octal " Jaime Liao
2024-02-01 9:43 ` [PATCH v8 2/9] spi: spi-mem: Allow specifying the byte order in Octal DTR mode Jaime Liao
2024-02-01 12:04 ` Mark Brown
2024-02-01 15:18 ` Michael Walle
2024-02-01 9:43 ` [PATCH v8 3/9] mtd: spi-nor: core: " Jaime Liao
2024-02-01 15:28 ` Michael Walle
2024-02-01 9:43 ` [PATCH v8 4/9] mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT Jaime Liao
2024-02-01 9:43 ` [PATCH v8 5/9] spi: mxic: Add support for swapping byte Jaime Liao
2024-02-01 12:05 ` Mark Brown
2024-02-01 15:39 ` Michael Walle [this message]
2024-02-01 9:43 ` [PATCH v8 6/9] mtd: spi-nor: add support for Macronix Octal flash MX25 series with RWW feature Jaime Liao
2024-02-01 15:48 ` Michael Walle
2024-02-01 9:43 ` [PATCH v8 7/9] mtd: spi-nor: add support for Macronix Octal flash MX66 " Jaime Liao
2024-02-01 9:43 ` [PATCH v8 8/9] mtd: spi-nor: add support for Macronix Octal flash MX25 series Jaime Liao
2024-02-01 9:43 ` [PATCH v8 9/9] mtd: spi-nor: add support for Macronix Octal flash MX66 series Jaime Liao
2024-02-01 15:52 ` Michael Walle
2024-02-22 9:32 ` [PATCH v8 0/9] Add octal DTR support for Macronix flash Tudor Ambarus
2024-02-22 9:55 ` liao jaime
2024-02-26 2:02 ` Alvin Zhou
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=8e834cd19cf896d792a0338a3fb5465c@kernel.org \
--to=mwalle@kernel.org \
--cc=broonie@kernel.org \
--cc=jaimeliao.tw@gmail.com \
--cc=jaimeliao@mxic.com.tw \
--cc=leoyu@mxic.com.tw \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.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).