From: Brian Norris <computersforpeace@gmail.com>
To: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Cc: linux-mtd@lists.infradead.org, nicolas.ferre@atmel.com,
boris.brezillon@free-electrons.com, marex@denx.de,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mtd: spi-nor: add an alternative method to support memory >16MiB
Date: Mon, 21 Mar 2016 10:01:07 -0700 [thread overview]
Message-ID: <20160321170107.GG2545@google.com> (raw)
In-Reply-To: <1458556429-11741-1-git-send-email-cyrille.pitchen@atmel.com>
On Mon, Mar 21, 2016 at 11:33:49AM +0100, Cyrille Pitchen wrote:
> This patch provides an alternative mean to support memory above 16MiB
> (128Mib) by replacing 3byte address op codes by their associated 4byte
> address versions.
>
> Using the dedicated 4byte address op codes doesn't change the internal
> state of the SPI NOR memory as opposed to using other means such as
> updating a Base Address Register (BAR) and sending command to enter/leave
> the 4byte mode.
>
> Hence when a CPU reset occurs, early bootloaders don't need to be aware
> of BAR value or 4byte mode being enabled: they can still access the first
> 16MiB of the SPI NOR memory using the regular 3byte address op codes.
>
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
I understand this reasoning, and that's all well and good. I'd like to
see this happen for all flash that support it, since the stateful 4-byte
modes just seem to break things a lot. But one question below.
> ---
>
> Hi all,
>
> This patch was tested on a sama5d2 xplained board + Macronix mx25l25635e.
>
> Best regards,
>
> Cyrille
>
> drivers/mtd/spi-nor/Kconfig | 12 +++++
> drivers/mtd/spi-nor/spi-nor.c | 105 +++++++++++++++++++++++++++++++++---------
> include/linux/mtd/spi-nor.h | 23 ++++++---
> 3 files changed, 113 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index d42c98e1f581..7fae36fc8526 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -29,6 +29,18 @@ config MTD_SPI_NOR_USE_4K_SECTORS
> Please note that some tools/drivers/filesystems may not work with
> 4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
>
> +config MTD_SPI_NOR_USE_4B_OPCODES
> + bool "Use 4-byte address op codes"
> + default n
> + help
> + This is an alternative to the "Enter/Exit 4-byte mode" commands and
> + Base Address Register (BAR) updates to support flash size above 16MiB.
> + Using dedicated 4-byte address op codes for (Fast) Read, Page Program
> + and Sector Erase operations avoids changing the internal state of the
> + SPI NOR memory. Hence if a CPU reset occurs, early bootloaders can
> + still use regular 3-byte address op codes and read from the very first
> + 16MiB of the flash memory.
> +
Why does this need to be a Kconfig option? Can't it just as well be
supported by keeping entries in the ID table, to show which flash
support these opcodes and which don't? Kconfig is really a bad mechanism
for trying to configure your flash.
> config SPI_FSL_QUADSPI
> tristate "Freescale Quad SPI controller"
> depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
[snip the rest for now, since I don't think it's relevant]
Brian
next prev parent reply other threads:[~2016-03-21 17:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-21 10:33 [PATCH 1/1] mtd: spi-nor: add an alternative method to support memory >16MiB Cyrille Pitchen
2016-03-21 17:01 ` Brian Norris [this message]
2016-03-21 17:16 ` Cyrille Pitchen
2016-03-21 17:55 ` Brian Norris
2016-03-22 11:27 ` Cyrille Pitchen
2016-04-01 20:38 ` Brian Norris
2016-04-04 14:27 ` Cyrille Pitchen
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=20160321170107.GG2545@google.com \
--to=computersforpeace@gmail.com \
--cc=boris.brezillon@free-electrons.com \
--cc=cyrille.pitchen@atmel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=nicolas.ferre@atmel.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).