All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
To: Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	marek.vasut@gmail.com, linux-mtd@lists.infradead.org,
	jartur@cadence.com, kdasu.kdev@gmail.com,
	mar.krzeminski@gmail.com
Cc: boris.brezillon@free-electrons.com, richard@nod.at,
	nicolas.ferre@microchip.com, linux-kernel@vger.kernel.org,
	computersforpeace@gmail.com, dwmw2@infradead.org
Subject: Re: [PATCH v5 0/6] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories
Date: Wed, 29 Mar 2017 18:45:35 +0200	[thread overview]
Message-ID: <ed497188-b50a-8212-a04b-1f25e8b3e260@wedev4u.fr> (raw)
In-Reply-To: <cover.1490220411.git.cyrille.pitchen@atmel.com>

Hi all,

Le 23/03/2017 à 00:33, Cyrille Pitchen a écrit :
> Hi all,
> 
> based on git-hub/spi-nor and likely applicable on linux-next within the
> next few days.
> 
> 
> This new series of patchs aims to upgrade to spi-nor framework. We need to
> take into account latest SPI memories which cannot be handled correctly by
> the current implementation.
> 
> For instance, SPI NOR memories like Spansion S25FS512S or Macronix
> MX25U4035 support only the Fast Read 1-4-4 (EBh) command but not the
> Fast Read 1-1-4 (6Bh) command. However the current spi-nor framework
> supports only Fast Read 1-1-4 (6Bh).
> 
> Also the Spansion S25FS512S memory (and others) may use a non-uniform
> sector erase map, whereas the spi-nor framework assumes that a single
> sector erase size and opcode can be used anywhere inside the data array.
> This assumption is no longer valid.
> 
> Then parsing SFDP tables is an attempt to solve many of those issues by
> discovering dynamically most of the parameters and settings of the SPI NOR
> memory:
> - the flash size
> - the page size for Page Program commands
> - the supported Fast Read commands with the associated opcodes and number
>   of mode/wait-state (dummy) cycles.
> - the supported Sector/Block Erase commands with the associated opcodes
>   and sizes.
> - the erase sector map (for non-uniform memory).
> 
> 
> Besides, most QSPI controllers from the different vendors are capable to
> support the SPI 1-2-2 and 1-4-4 protocols but the spi-nor framework was
> not ready to use them. This series also fixes this issue and computes the
> best match between the hardware capabilies of both the SPI memory and the
> SPI controler (master) to select the right opcodes and dummy cycles for
> Fast Read and Page Program operations.
> 
> The new 'struct spi_nor_hwcaps' uses a bitmask to describe all the
> supported hardware capabilies and makes the difference between Fast Read
> and Page Program operations and also between the different SPI protocols
> (SPI 1-1-2 vs SPI 1-2-2 or SPI 1-1-4 vs SPI 1-4-4).
> 
> 
> IMHO, the first 3 patches of this series are ready to be merged into the
> github/spi-nor tree. Marek, do you agree with that?

Marek, if you have no comment on them, I will merge patches 1, 2, 3 in
the spi-nor tree within the next few days. Hence, people like Cédric
waiting for the series to merged could base their work on these patches.

Best regards,

Cyrille

> 
> Artur, patch 1 introduces some basic support to Octal SPI to help you with
> your series. About the op code values, I would like to wait for some JEDEC
> specification to provide the reference values or at least the datasheets
> of different vendors to guess the actual standard. For now, IMHO, only one
> manufacturer is not enough.
> 
> Kamal, if you don't mind I've put your Signed-off-by in patch 3 since the
> original patch is from you so I wanted to give you the credits :)
> I've just fixed some issue: in the original version, set4_byte() was
> called from spi_nor_init() even if (nor->addr_width == 3).
> I hope it will help you with the suspend/resume series.
> 
> 
> The 3 last patches are RFC and are provided so it's more easy for
> reviewers to understand the direction I would like to follow to upgrade
> the spi-nor framework.
> 
> Marcin, I haven't finished yet another 7th patch to parse the sector erase
> map table from SFDP so for now patch 4 is almost useless. Besides I only
> tested it with uniform memories to avoid regressions. I may need your help
> to test it with non-uniform memories, if you don't mind :)
> 
> 
> Best regards,
> 
> Cyrille
> 
> 
> ChangeLog:
> 
> v4 -> v5
> - rework the whole series.
> - introduce support for Octo SPI protocols.
> - introduce support for Double Transfer Rate (DTR) protocols.
> - introduce support for memories with non-uniform sector erase sizes.
> 
> v3 -> v4
> - replace dev_info() by dev_dbg() in patch 1.
> - split former patch 2 into 2 patches:
>   + new patch 2 deals with the rename of SPINOR_OP_READ4_* macros
>   + new patch 3 deals with the alternative methode to support memory
>> 16MiB
> - add comment in patch 3 to describe the dichotomic search performed by
>   spi_nor_convert_opcode().
> - change return type from int to void for m25p80_proto2nbits() in patch 6.
> - remove former patches 8 & 9 from the v2 series: the support of the
>   Macronix mx66l1g45g memory will be sent in a separated patch.
> 
> v2 -> v3
> - tested with new samples: Micron n25q512, n25q01g and Macronix
>   mx25v1635f, mx25l3235f, mx25l3273f.
> - add "Reviewed-by: Jagan Teki <jagan@openedev.com>" on patch 1.
> - add "Tested-by: Vignesh R <vigneshr@ti.com>" on patch 2.
> - fix some checkpatch warnings.
> - add call of spi_nor_wait_till_ready() in spansion_new_quad_enable()
>   and sr2_bit7_quad_enable(), as suggested by Joel Esponde on patch 6.
> - test JESD216 rev A (minor 5) instead of rev B (minor 6) with the return
>   code of spi_nor_parse_sfdp() from spi_nor_init_params() on patch 6.
>   The seven additional DWORDs of the Basic Flash Parameter Table were
>   introduced in rev A, not rev B, so the 15th DWORD was already available
>   in rev A. The 15th DWORD provides us with the Quad Enable Requirements
>   (QER) bits.
>   Basic Flash Parameter Table size:
>   + JESD216 :  9 DWORDS
>   + JESD216A: 16 DWORDS
>   + JESD216B: 16 DWORDS
> 
> v1 -> v2
> - fix patch 3 to resolve compiler errors on hisi-sfc.c and cadence-quadspi.c
>   drivers
> 
> 
> Cyrille Pitchen (6):
>   mtd: spi-nor: introduce more SPI protocols and the Dual Transfer Mode
>   mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols
>   mtd: spi-nor: add spi_nor_init() function
>   mtd: spi-nor: add support to non-uniform SPI NOR flash memories
>   mtd: spi-nor: parse Serial Flash Discoverable Parameters (SFDP) tables
>   mtd: spi-nor: parse SFDP 4-byte Address Instruction Table
> 
>  drivers/mtd/devices/m25p80.c          |  130 ++-
>  drivers/mtd/spi-nor/aspeed-smc.c      |   23 +-
>  drivers/mtd/spi-nor/atmel-quadspi.c   |   80 +-
>  drivers/mtd/spi-nor/cadence-quadspi.c |   18 +-
>  drivers/mtd/spi-nor/fsl-quadspi.c     |    8 +-
>  drivers/mtd/spi-nor/hisi-sfc.c        |   31 +-
>  drivers/mtd/spi-nor/intel-spi.c       |    7 +-
>  drivers/mtd/spi-nor/mtk-quadspi.c     |   16 +-
>  drivers/mtd/spi-nor/nxp-spifi.c       |   22 +-
>  drivers/mtd/spi-nor/spi-nor.c         | 1722 +++++++++++++++++++++++++++++----
>  include/linux/mtd/spi-nor.h           |  228 ++++-
>  11 files changed, 1983 insertions(+), 302 deletions(-)
> 

  parent reply	other threads:[~2017-03-29 17:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-22 23:33 [PATCH v5 0/6] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories Cyrille Pitchen
2017-03-22 23:33 ` [PATCH v5 1/6] mtd: spi-nor: introduce more SPI protocols and the Dual Transfer Mode Cyrille Pitchen
2017-03-23 15:13   ` Cédric Le Goater
2017-03-23 19:10     ` Cyrille Pitchen
2017-03-24 10:03       ` Cédric Le Goater
2017-03-24 11:39         ` Cyrille Pitchen
2017-04-02 17:05   ` Cyrille Pitchen
2017-04-06 23:30   ` Marek Vasut
2017-04-09 21:16     ` Cyrille Pitchen
2017-04-09 21:40       ` Marek Vasut
2017-03-22 23:33 ` [PATCH v5 2/6] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols Cyrille Pitchen
2017-04-02 17:05   ` Cyrille Pitchen
2017-04-06 23:37   ` Marek Vasut
2017-04-09 19:37     ` Cyrille Pitchen
2017-04-09 20:46       ` Marek Vasut
2017-04-09 21:30         ` Cyrille Pitchen
2017-04-09 21:46           ` Marek Vasut
2017-03-22 23:33 ` [PATCH v5 3/6] mtd: spi-nor: add spi_nor_init() function Cyrille Pitchen
2017-04-02 17:06   ` Cyrille Pitchen
2017-03-22 23:33 ` [RFC PATCH v5 4/6] mtd: spi-nor: add support to non-uniform SPI NOR flash memories Cyrille Pitchen
2017-04-15 15:24   ` Marek Vasut
2017-03-22 23:33 ` [RFC PATCH v5 5/6] mtd: spi-nor: parse Serial Flash Discoverable Parameters (SFDP) tables Cyrille Pitchen
2017-04-15 15:34   ` Marek Vasut
2017-03-22 23:39 ` [RFC PATCH v5 6/6] mtd: spi-nor: parse SFDP 4-byte Address Instruction Table Cyrille Pitchen
2017-04-15 15:36   ` Marek Vasut
2017-03-29 16:45 ` Cyrille Pitchen [this message]
2017-04-02 18:32   ` [PATCH v5 0/6] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories Marek Vasut

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=ed497188-b50a-8212-a04b-1f25e8b3e260@wedev4u.fr \
    --to=cyrille.pitchen@wedev4u.fr \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=dwmw2@infradead.org \
    --cc=jartur@cadence.com \
    --cc=kdasu.kdev@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mar.krzeminski@gmail.com \
    --cc=marek.vasut@gmail.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=richard@nod.at \
    /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.