Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Boris Brezillon <boris.brezillon@free-electrons.com>]

On Mon, 28 Nov 2016 05:46:10 +0000
Yao Yuan <yao.yuan@nxp.com> wrote:

> On 11/26/2016 01:12am, Marek Vasut wrote:
> > On 11/08/2016 11:52 AM, Cyrille Pitchen wrote:  
> > > Hi all,
> > >
> > > Le 08/11/2016 à 09:07, Boris Brezillon a écrit :  
> > >> +Peter
> > >>
> > >> On Mon, 7 Nov 2016 18:01:15 -0800
> > >> Brian Norris <computersforpeace@gmail.com> wrote:
> > >>  
> > >>> + 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.  
> > >>
> > >> Yao, can you sync with Peter who is currently working on a SPI NAND
> > >> framework (which would sit in drivers/mtd/nand/spi/).
> > >>  
> > >>>>
> > >>>>    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.  
> > >>
> > >> I'm not sure identification of raw and SPI NAND is working the same
> > >> way, but that's true for the BBT. And, as Brian said, you don't
> > >> interact with NANDs the same way you do with NORs, so it should IMO
> > >> stay in different frameworks.
> > >>  
> > >
> > > I agree with Brian and Boris about separating NORs and NANDs in
> > > different frameworks. I know this is just a detail but for instance,
> > > the current spi-nor framework starts sending the JEDEC Read ID command
> > > 9Fh to probe the memory. At this point, you don't know yet what memory
> > > is connected to the SPI controller. Hence you don't even know wether it is a  
> > NAND or a NOR.  
> > > Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example, its
> > > datasheet claims that the JEDEC Read ID command (9Fh) requires 8 dummy
> > > clock cycles after the op code and before reading the actual memory ID.
> > > Those dummy cycles don't exist with SPI NOR memories.
> > > So spi_nor_scan() cannot be used probe (Q)SPI NAND memories.
> > >
> > > Also, the read operation can be performed with a single (Fast) Read
> > > command with (Q)SPI NOR memories whereas it has to be done in two
> > > steps for QSPI NAND memories:
> > > 1 - Page Read (13h): to transfer data from array to cache
> > > 2 - Random Data Read (03h or 0Bh): to read data from the cache and
> > >                                    transfer them on the SPI bus.
> > >
> > > So read operations are quite different as well between NORs and NANDs.
> > > I didn't have a look at the Page Program operation but I expect strong
> > > differences as well.
> > >
> > > I think there are too many differences to handle both kind of memories
> > > with a single framework.  
> > 
> > Can a QSPI controller handle both SPI NOR and SPI NAND ? That is the question
> > here. If so, we'd have the same driver for both, but different layer on top of it
> > (handling either NOR or NAND commands). I think the different command sets
> > are a detail which can be handled just fine and it should be a detail handled in
> > separate SPI NOR and SPI NAND layers.
> > Just my 5 cents ...
> > 
> > --  
> 
> Yes, at least the QSPI for Freescale(NXP) can support both SPI NOR and SPI NAND.
> So I think the QSPI driver can be the same, I agree with you that we can add a top 
> layer for different flash.
> 

Well, I'd like to see what can be shared before taking a decision.