linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Yao Yuan <yao.yuan@nxp.com>
Cc: "dwmw2@infradead.org" <dwmw2@infradead.org>,
	"hramrach@gmail.com" <hramrach@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd@lists.infradead.org,
	Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Subject: Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c
Date: Mon, 7 Nov 2016 18:01:15 -0800	[thread overview]
Message-ID: <20161108020115.GA116407@google.com> (raw)
In-Reply-To: <DB6PR0401MB2407AE783B4F57D09750D8DA89A70@DB6PR0401MB2407.eurprd04.prod.outlook.com>

+ others

On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:
>    Hi All,

Hi Yao,

I'm not that interested in handling private requests, and this is
generally informative, so I've added the linux-mtd list, as well as the
other maintainers.

Also, when you're ready to send patches, make sure you use plain text
instead of HTML email.

>    I’m trying to add the QSPI NAND support in MTD.
> 
>    But I have reached a junction, could you please take some minutes and
>    give me some suggestions?
> 
> 
>    You know, we have the QSPI NOR support in
>    drivers/mtd/spi-nor/spi-nor.c,
> 
>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
>    and erase is different with SPI-NOR.

How similar is the controller hardware? Does your IP support standard
SPI protocol, or is it specialized for accelerating SPI NAND (e.g.,
memory-mapped, DMA, etc.)? Does it support SPI NOR?

>    So I have two ways to add QSPI-NAND:

I'll leave your options intact below, but I don't think either of them
are that good. SPI NOR and SPI NAND are different enough, I doubt that
we'll get much benefit from using the same framework, unless you happen
to have IP that's designed for both NOR and NAND, yet doesn't quite do
traditional SPI.

Particularly, NAND flash has a lot of issues that NOR flash generally
does not, around bad block management and wear leveling. Also, there may
be something to share around identification/ONFI? (Not sure how similar
the implementations are there.) There's been some prior discussion about
it, and maybe one of the CC'd people can direct you toward the latest
opinions, or else you can search the archives youreself ("SPI NAND"
should turn up several results).

So the main issues would probably be around abstracting out the
bad-block-related and chip identification code so you can share code
with existing (parallel) NAND support. At least, that's what I think
based on the last time I looked at things, and I think some of the other
active maintainers had ideas along the same lines.

Brian

>    1, rename
> 
>    drivers/mtd/spi-nor/spi-nor.c
> 
>    As
> 
>    drivers/mtd/spi-flash/spi-flash.c
> 
>    And then add:
> 
>    spi_nand_erase
> 
>    spi_nand_read
> 
>    spi_nand_write
> 
>    to support QSPI NAND.
> 
> 
>    2, rename
> 
>    drivers/mtd/spi-nor/
> 
>    to
> 
>    drivers/mtd/spi-flash/
> 
>    and then add:
> 
>    drivers/mtd/spi-flash/spi-nand.c
> 
>    to support QSPI NAND.
> 
> 
>    Thanks for your suggestions, and I will send the RFC patch once I can
>    select a way.
> 
> 
>    Best Regards,
> 
>    Yao

       reply	other threads:[~2016-11-08  2:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <DB6PR0401MB2407AE783B4F57D09750D8DA89A70@DB6PR0401MB2407.eurprd04.prod.outlook.com>
2016-11-08  2:01 ` Brian Norris [this message]
2016-11-08  8:07   ` SPI NAND support in drivers/mtd/spi-nor/spi-nor.c Boris Brezillon
2016-11-08 10:52     ` Cyrille Pitchen
2016-11-25 17:11       ` Marek Vasut
2016-11-25 18:35         ` Boris Brezillon
2016-11-25 19:07           ` Marek Vasut
2016-11-28  6:57           ` Yao Yuan
2016-11-28  8:10             ` Boris Brezillon
2016-11-28  5:46         ` Yao Yuan
2016-11-28  7:56           ` Boris Brezillon

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=20161108020115.GA116407@google.com \
    --to=computersforpeace@gmail.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=dwmw2@infradead.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=hramrach@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=richard@nod.at \
    --cc=yao.yuan@nxp.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).