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

[Marek Vasut]

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 at 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 ...

-- 
Best regards,
Marek Vasut