From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
To: Brian Norris <computersforpeace@gmail.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 18:16:32 +0100 [thread overview]
Message-ID: <56F02C70.6050106@atmel.com> (raw)
In-Reply-To: <20160321170107.GG2545@google.com>
Hi Brian,
Le 21/03/2016 18:01, Brian Norris a écrit :
> 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
>
Well, the only reason why I've chosen a Kconfig option is to be as safe as
possible, if for some reason someone still wants to use the former
implementation. Honestly I don't know why one would do so but I'm cautious
so I also set "default n". This way no regression is introduced.
If you think it's better to use a dedicated flag like SECT_4K or
SPI_NOR_QUAD_READ in the spi_nor_ids[] table, I'm perfectly fine with it as
well.
Just let me know your choice then I'll update my patch accordingly if needed.
Best regards,
Cyrille
next prev parent reply other threads:[~2016-03-21 17:16 UTC|newest]
Thread overview: 10+ 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
2016-03-21 17:16 ` Cyrille Pitchen [this message]
2016-03-21 17:55 ` Brian Norris
2016-03-22 11:27 ` Cyrille Pitchen
2016-03-22 11:27 ` Cyrille Pitchen
2016-04-01 20:38 ` Brian Norris
2016-04-01 20:38 ` Brian Norris
2016-04-04 14:27 ` Cyrille Pitchen
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=56F02C70.6050106@atmel.com \
--to=cyrille.pitchen@atmel.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.