From: Tudor Ambarus <tudor.ambarus@microchip.com>
To: <p.yadav@ti.com>, <michael@walle.cc>, <broonie@kernel.org>
Cc: <miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
<linux-spi@vger.kernel.org>, <nicolas.ferre@microchip.com>,
Tudor Ambarus <tudor.ambarus@microchip.com>
Subject: [PATCH v2 0/6] spi-mem: Allow specifying the byte order in DTR mode
Date: Fri, 11 Mar 2022 10:01:41 +0200 [thread overview]
Message-ID: <20220311080147.453483-1-tudor.ambarus@microchip.com> (raw)
There are NOR flashes (Macronix) that swap the bytes on a 16-bit boundary
when configured in Octal DTR mode. The byte order of 16-bit words is
swapped when read or written in Octal Double Transfer Rate (DTR) mode
compared to Single Transfer Rate (STR) modes. If one writes D0 D1 D2 D3
bytes using 1-1-1 mode, and uses 8D-8D-8D SPI mode for reading, it will
read back D1 D0 D3 D2. Swapping the bytes is a bad design decision because
it may introduce some endianness problems. It can affect the boot sequence
if the entire boot sequence is not handled in either 8D-8D-8D mode or 1-1-1
mode. So we must swap the bytes back to have the same byte order as in STR
modes. Fortunately there are controllers that can swap the bytes back at
runtime, addressing the flash's endiannesses requirements.
If the controllers are not capable of swapping the bytes, the protocol is
downgraded via spi_nor_spimem_adjust_hwcaps(). When available, the swapping
of the bytes is always done regardless if it's a data or register access,
so that we comply with the JESD216 requirements: "Byte order of 16-bit
words is swapped when read in 8D-8D-8D mode compared to 1-1-1".
Tested with atmel-quadspi driver, both in 8D-8D-8D mode and 1-1-1 mode
(via the protocol downgrade).
This patch set depends on the SPI MEM changes from linux-mtd/mtd/next and
also on some SPI NOR patches that are waiting for R-b tags. You can find
a branch if you want to test it at:
To github.com:ambarus/linux-0day.git
* [new branch] spi-nor/next-mx-byte-swap-v2 -> spi-nor/next-mx-byte-swap-v2
v2:
- all: s/bswap16/swab16 to comply with linux naming scheme
- SPI MEM: add dtr_swab16 cap to spi_controller_mem_caps and update
spi_mem_default_supports_op() to check for it.
- SPI NOR: do not encode swab16 info in the SPI NOR protocol, use a helper
instead
- SPI NOR: downgrade the SPI NOR protocol in case the SPI Controller does
not support swab16
- add SPI_NOR_SOFT_RESET and support for mx66lm1g45g
Tudor Ambarus (6):
spi: spi-mem: Allow specifying the byte order in DTR mode
mtd: spi-nor: core: Allow specifying the byte order in DTR mode
mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT
mtd: spi-nor: core: Introduce SPI_NOR_DTR_BSWAP16 no_sfdp_flag
mtd: spi-nor: core: Introduce SPI_NOR_SOFT_RESET flash_info fixup_flag
mtd: spi-nor: macronix: Add support for mx66lm1g45g
drivers/mtd/spi-nor/core.c | 16 +++-
drivers/mtd/spi-nor/core.h | 10 ++-
drivers/mtd/spi-nor/macronix.c | 130 +++++++++++++++++++++++++++++++++
drivers/mtd/spi-nor/sfdp.c | 4 +
drivers/spi/spi-mem.c | 4 +
include/linux/spi/spi-mem.h | 6 ++
6 files changed, 168 insertions(+), 2 deletions(-)
--
2.25.1
next reply other threads:[~2022-03-11 8:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 8:01 Tudor Ambarus [this message]
2022-03-11 8:01 ` [PATCH v2 1/6] spi: spi-mem: Allow specifying the byte order in DTR mode Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 2/6] mtd: spi-nor: core: " Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 3/6] mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 4/6] mtd: spi-nor: core: Introduce SPI_NOR_DTR_BSWAP16 no_sfdp_flag Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 5/6] mtd: spi-nor: core: Introduce SPI_NOR_SOFT_RESET flash_info fixup_flag Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 6/6] mtd: spi-nor: macronix: Add support for mx66lm1g45g Tudor Ambarus
2022-03-15 6:08 ` [PATCH v2 0/6] spi-mem: Allow specifying the byte order in DTR mode Vignesh Raghavendra
2022-03-15 6:58 ` Tudor.Ambarus
2022-03-16 7:08 ` Vignesh Raghavendra
2022-03-16 8:39 ` Michael Walle
2022-03-15 7:19 ` Michael Walle
2022-03-16 7:05 ` Vignesh Raghavendra
2022-03-16 7:57 ` Tudor.Ambarus
2022-03-16 13:55 ` David Laight
2022-03-17 9:40 ` Michael Walle
2022-03-17 10:14 ` David Laight
2022-03-17 10:23 ` Vignesh Raghavendra
2022-03-17 11:10 ` David Laight
2022-03-17 16:49 ` Vignesh Raghavendra
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=20220311080147.453483-1-tudor.ambarus@microchip.com \
--to=tudor.ambarus@microchip.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=nicolas.ferre@microchip.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--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).