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

[Marek Vasut]

On 11/25/2016 07:35 PM, Boris Brezillon wrote:
> On Fri, 25 Nov 2016 18:11:41 +0100
> Marek Vasut <marek.vasut at gmail.com> 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 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 ...
> 
> That was my feeling too, but as I said, I know almost nothing about
> spi-nor/nand, so I trust people who already worked on this topic.
> If we have enough code to share (everything that is storage agnostic),
> then let's do that, but AFAIU, there's not much to share. And if it's
> really storage agnostic, shouldn't we place that code in the spi
> framework?

Either spi framework, or some spi-flash abstraction library, yes.
I really need to look into SPI NAND asap.

-- 
Best regards,
Marek Vasut