All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	Michael Walle <michael@walle.cc>,
	linux-mtd@lists.infradead.org
Cc: Julien Su <juliensu@mxic.com.tw>,
	Jaime Liao <jaimeliao@mxic.com.tw>,
	Alvin Zhou <alvinzhou@mxic.com.tw>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v3 2/9] mtd: spi-nor: Introduce the concept of bank
Date: Thu, 19 Jan 2023 16:34:28 +0000	[thread overview]
Message-ID: <9e5f4a2b-b232-880f-e1dd-37e23e4a98b6@linaro.org> (raw)
In-Reply-To: <20221215081241.407098-3-miquel.raynal@bootlin.com>

Hi, Miquel,

On 12/15/22 08:12, Miquel Raynal wrote:
> SPI-NOR chips are made of pages, which gathered in small groups make

nit: s/SPI-NOR/ SPI NOR

> (erase) sectors. Sectors, gathered together, make banks inside the
> chip. So far there was only one bank per device supported, but we are
> about to introduce support for new chips featuring several banks (up to
> 4 so far) where different operations may happen in parallel.
> 
> Let's allow describing these additional bank parameters.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
> ---
>   drivers/mtd/spi-nor/core.c |  3 ++-
>   drivers/mtd/spi-nor/core.h | 16 +++++++++++-----
>   2 files changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index f2c64006f8d7..38a57aac6754 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2539,7 +2539,8 @@ static void spi_nor_init_default_params(struct spi_nor *nor)
>   
>   	/* Set SPI NOR sizes. */
>   	params->writesize = 1;
> -	params->size = (u64)info->sector_size * info->n_sectors;
> +	params->bank_size = (u64)info->sector_size * info->n_sectors;
> +	params->size = params->bank_size * info->n_banks;

Is the datasheet for these chips public? I see JESD216 says nothing
about flash banks.

I'm wondering whether we should keep the n_sectors as the total number 
of sectors per flash or not. Does this flash type support Software Block
Protection? How do they count the sectors on Block Protection, per flash
or per bank?

>   	params->page_size = info->page_size;
>   
>   	if (!(info->flags & SPI_NOR_NO_FR)) {
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index dc74c7be3e28..8a067d56c995 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -336,7 +336,8 @@ struct spi_nor_otp {
>    * by the spi_nor_fixups hooks, or dynamically when parsing the JESD216
>    * Serial Flash Discoverable Parameters (SFDP) tables.
>    *
> - * @size:		the flash memory density in bytes.
> + * @bank_size:		the flash memory bank density in bytes.
> + * @size:		the total flash memory density in bytes.
>    * @writesize		Minimal writable flash unit size. Defaults to 1. Set to
>    *			ECC unit size for ECC-ed flashes.
>    * @page_size:		the page size of the SPI NOR flash memory.
> @@ -374,6 +375,7 @@ struct spi_nor_otp {
>    * @locking_ops:	SPI NOR locking methods.
>    */
>   struct spi_nor_flash_parameter {
> +	u64				bank_size;
>   	u64				size;
>   	u32				writesize;
>   	u32				page_size;
> @@ -434,7 +436,8 @@ struct spi_nor_fixups {
>    * @id_len:         the number of bytes of ID.
>    * @sector_size:    the size listed here is what works with SPINOR_OP_SE, which
>    *                  isn't necessarily called a "sector" by the vendor.
> - * @n_sectors:      the number of sectors.
> + * @n_sectors:      the number of sectors per bank.
> + * @n_banks:        the number of banks.
>    * @page_size:      the flash's page size.
>    * @addr_nbytes:    number of address bytes to send.
>    *
> @@ -493,6 +496,7 @@ struct flash_info {
>   	u8 id_len;
>   	unsigned sector_size;
>   	u16 n_sectors;
> +	u16 n_banks;
>   	u16 page_size;

We can try u8 nbanks for now. And we would define it here, to avoid
struct padding.
>   	u8 addr_nbytes;
>   
> @@ -538,23 +542,25 @@ struct flash_info {
>   	.id = { SPI_NOR_ID_3ITEMS(_jedec_id), SPI_NOR_ID_3ITEMS(_ext_id) }, \
>   	.id_len = 6
>   
> -#define SPI_NOR_GEOMETRY(_sector_size, _n_sectors)			\
> +#define SPI_NOR_GEOMETRY(_sector_size, _n_sectors, _n_banks)		\
>   	.sector_size = (_sector_size),					\
>   	.n_sectors = (_n_sectors),					\
> +	.n_banks = (_n_banks),						\
>   	.page_size = 256
>   
>   /* Used when the "_ext_id" is two bytes at most */
>   #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors)		\
>   	SPI_NOR_ID((_jedec_id), (_ext_id)),				\
> -	SPI_NOR_GEOMETRY((_sector_size), (_n_sectors)),
> +	SPI_NOR_GEOMETRY((_sector_size), (_n_sectors), 1),
>   
>   #define INFO6(_jedec_id, _ext_id, _sector_size, _n_sectors)		\
>   	SPI_NOR_ID6((_jedec_id), (_ext_id)),				\
> -	SPI_NOR_GEOMETRY((_sector_size), (_n_sectors)),
> +	SPI_NOR_GEOMETRY((_sector_size), (_n_sectors), 1),
>   
>   #define CAT25_INFO(_sector_size, _n_sectors, _page_size, _addr_nbytes)	\
>   		.sector_size = (_sector_size),				\
>   		.n_sectors = (_n_sectors),				\
> +		.n_banks = 1,						\
>   		.page_size = (_page_size),				\
>   		.addr_nbytes = (_addr_nbytes),				\
>   		.flags = SPI_NOR_NO_ERASE | SPI_NOR_NO_FR,		\

you need to update S3AN_INFO as well.

Cheers,
ta

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2023-01-19 16:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-15  8:12 [PATCH v3 0/9] mtd: spi-nor: read while write support Miquel Raynal
2022-12-15  8:12 ` [PATCH v3 1/9] mtd: spi-nor: Create macros to define chip IDs and geometries Miquel Raynal
2023-01-31  8:58   ` Tudor Ambarus
2022-12-15  8:12 ` [PATCH v3 2/9] mtd: spi-nor: Introduce the concept of bank Miquel Raynal
2023-01-19 16:34   ` Tudor Ambarus [this message]
2023-02-01 11:32     ` Miquel Raynal
2023-03-17  3:33       ` Tudor Ambarus
2023-03-24 15:13         ` Miquel Raynal
2022-12-15  8:12 ` [PATCH v3 3/9] mtd: spi-nor: Add a macro to define more banks Miquel Raynal
2022-12-15  8:12 ` [PATCH v3 4/9] mtd: spi-nor: Reorder the preparation vs locking steps Miquel Raynal
2023-01-31  5:11   ` Tudor Ambarus
2023-02-01 11:36     ` Miquel Raynal
2022-12-15  8:12 ` [PATCH v3 5/9] mtd: spi-nor: Separate preparation and locking Miquel Raynal
2022-12-15  8:12 ` [PATCH v3 6/9] mtd: spi-nor: Prepare the introduction of a new locking mechanism Miquel Raynal
2023-01-31  5:29   ` Tudor Ambarus
2022-12-15  8:12 ` [PATCH v3 7/9] mtd: spi-nor: Add a RWW flag Miquel Raynal
2022-12-15  8:12 ` [PATCH v3 8/9] mtd: spi-nor: Enhance locking to support reads while writes Miquel Raynal
2022-12-15  8:12 ` [PATCH v3 9/9] mtd: spi-nor: macronix: Add support for mx25uw51245g with RWW Miquel Raynal

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=9e5f4a2b-b232-880f-e1dd-37e23e4a98b6@linaro.org \
    --to=tudor.ambarus@linaro.org \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=alvinzhou@mxic.com.tw \
    --cc=jaimeliao@mxic.com.tw \
    --cc=juliensu@mxic.com.tw \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@bootlin.com \
    --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 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.