All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <p.yadav@ti.com>
To: <Tudor.Ambarus@microchip.com>
Cc: <jaimeliao.tw@gmail.com>, <u-boot@lists.denx.de>,
	<jagan@amarulasoutions.com>, <vigneshr@ti.com>,
	<miquel.raynal@bootlin.com>, <zhengxunli@mxic.com.tw>,
	<jaimeliao@mxic.com.tw>
Subject: Re: [PATCH v6 3/4] mtd: spi-nor-core: Add support for Macronix Octal flash
Date: Mon, 10 Jan 2022 10:59:02 +0530	[thread overview]
Message-ID: <20220110052900.qesnya47jzsidcud@ti.com> (raw)
In-Reply-To: <194eca01-3af0-093b-4738-6a171118eb4a@microchip.com>

On 03/01/22 10:47AM, Tudor.Ambarus@microchip.com wrote:
> On 12/29/21 7:56 AM, JaimeLiao wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > Adding Macronix Octal flash for Octal DTR support.
> > 
> > The octaflash series can be divided into the following types:
> > 
> > MX25 series : Serial NOR Flash.
> > MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb)
> > LM/UM series : Up to 250MHz clock frequency with both DTR/STR operation.
> > LW/UW series : Support simultaneous Read-while-Write operation in multiple
> >                bank architecture. Read-while-write feature which means read
> >                data one bank while another bank is programing or erasing.
> > 
> > MX25LM : 3.0V Octal I/O
> >  -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
> > 
> > MX25UM : 1.8V Octal I/O
> >  -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf
> > 
> > MX66LM : 3.0V Octal I/O with stacked die
> >  -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf
> > 
> > MX66UM : 1.8V Octal I/O with stacked die
> >  -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf
> > 
> > MX25LW : 3.0V Octal I/O with Read-while-Write
> > MX25UW : 1.8V Octal I/O with Read-while-Write
> > MX66LW : 3.0V Octal I/O with Read-while-Write and stack die
> > MX66UW : 1.8V Octal I/O with Read-while-Write and stack die
> > 
> > About LW/UW series, please contact us freely if you have any
> > questions. For adding Octal NOR Flash IDs, we have validated
> > each Flash on plateform zynq-picozed.
> > 
> > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com>
> > ---
> >  drivers/mtd/spi/spi-nor-ids.c | 22 +++++++++++++++++++++-
> >  1 file changed, 21 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> > index cb3a08872d..5c13ea3a78 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = {
> >         { INFO("mx66l1g45g",  0xc2201b, 0, 64 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> >         { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024,   32, SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | SECT_4K) },
> >         { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024,   128,  SECT_4K) },
> > -       { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx66lm1g45g",    0xc2853b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25lm51245g",   0xc2853a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25lw51245g",   0xc2863a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25lm25645g",   0xc28539, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx66um2g45g",    0xc2803c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx66uw2g345g",   0xc2843c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx66um1g45g",    0xc2803b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx66uw1g45g",    0xc2813b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25um51245g",   0xc2803a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25uw51245g",   0xc2813a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25uw51345g",   0xc2843a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25um25645g",   0xc28039, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25uw25645g",   0xc28139, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25um25345g",   0xc28339, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25uw25345g",   0xc28439, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25uw12845g",   0xc28138, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25uw12a45g",   0xc28938, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25uw12345g",   0xc28438, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25uw6445g",    0xc28137, 0, 2 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > +       { INFO("mx25uw6345g",    0xc28437, 0, 2 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> 
> You need to at least specify which of these flashes support SFDP (describing the
> supported tables) and which not, otherwise this will become a maintenance burden.
> Best would be to dump all the SFDP tables for all the flashes.
> 
> My general feeling is that we should re-sync u-boot's SPI NOR subsystem with the
> one on linux sooner or later, or the code will become harder to maintain.
> Volunteers, thoughts? :)

I think that would be very nice indeed. But unfortunately I do not have 
any bandwidth to spare right now for this.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

  reply	other threads:[~2022-01-10  5:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-29  5:56 [PATCH v6 0/4] Add octal DTR support for Macronix flash JaimeLiao
2021-12-29  5:56 ` [PATCH v6 1/4] mtd: spi-nor: macronix: add support for Macronix Octal JaimeLiao
2022-01-03  9:30   ` Miquel Raynal
2022-01-06  1:20     ` liao jaime
2022-01-03 10:38   ` Tudor.Ambarus
2022-01-06  1:57     ` liao jaime
2022-01-10  5:27     ` Pratyush Yadav
2021-12-29  5:56 ` [PATCH v6 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset JaimeLiao
2021-12-29  5:56 ` [PATCH v6 3/4] mtd: spi-nor-core: Add support for Macronix Octal flash JaimeLiao
2022-01-03 10:47   ` Tudor.Ambarus
2022-01-10  5:29     ` Pratyush Yadav [this message]
2022-01-14  3:08       ` liao jaime
2021-12-29  5:56 ` [PATCH v6 4/4] mtd: spi-nor: Parse SFDP SCCR Map JaimeLiao

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=20220110052900.qesnya47jzsidcud@ti.com \
    --to=p.yadav@ti.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=jagan@amarulasoutions.com \
    --cc=jaimeliao.tw@gmail.com \
    --cc=jaimeliao@mxic.com.tw \
    --cc=miquel.raynal@bootlin.com \
    --cc=u-boot@lists.denx.de \
    --cc=vigneshr@ti.com \
    --cc=zhengxunli@mxic.com.tw \
    /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.