mtd layer: support of hybrid flash(W25M161AW) having both NOR and NAND flash

[Jonas Gorski]

On 5 January 2018 at 11:21, Prabhakar Kushwaha
<prabhakar.kushwaha at nxp.com> wrote:
> Thanks Boris for the encouragement.
>
>> -----Original Message-----
>> From: Boris Brezillon [mailto:boris.brezillon at free-electrons.com]
>> Sent: Thursday, January 04, 2018 11:17 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>
>> Cc: linux-mtd at lists.infradead.org; Cyrille Pitchen <cyrille.pitchen at wedev4u.fr>;
>> Richard Weinberger <richard at nod.at>; Marek Vasut <marex at denx.de>; Brian
>> Norris <computersforpeace at gmail.com>
>> Subject: Re: mtd layer: support of hybrid flash(W25M161AW) having both NOR
>> and NAND flash
>>
>> +MTD maintainers.
>>
>> On Thu, 4 Jan 2018 14:08:42 +0000
>> Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com> wrote:
>>
>> > Hi All,
>> >
>> > Winbond has come up with special flash i.e.  W25M161AW. It consist of Serial
>> NOR(Die #0) and Serial NAND(Die #1) flash.
>> > Means both NOR, NAND flashes are placed in W25M161AW controlled by
>> single chip-select.
>> >
>> > "Software Die Select (C2h)" command is being used to switch die or flash.
>>
>> Why are they so mean to us?! :-)
>>
>> >
>> > It looks to be quite unique chip and wondering if any kind framework or work in
>> progress available to handle it.
>> > I know that SPI-NAND framework discussions is still in progress.
>>
>> Well, nothing impossible to handle, we just need to declare 2 MTD
>> devices (one NAND and one NOR). This being said, it looks like we'll
>> need this spi-flash abstraction we have been talking about with Marek
>> and Cyrille to properly support these use cases: flash devices will be
>> exposed through different sub-layers (spi-nor or spi-nand), but we need
>> a common way to detect those spi-flash chips. I looked at a few SPI
>> NAND and SPI NOR chips, and from what I've seen so far they were quite
>> different (the opcodes and CMD+ADDR+DATA sequences were quite
>> different) so I thought we were safe to start with a completely
>> unconnected SPI NAND framework and merge some bits in a spi-flash layer
>> afterwards, but this chip proves me wrong :-/.
>
> I am thinking of following changes with fsl_qspi.c as controller
>
> &qspi {
>         num-cs = <2>;
>         bus-num = <0>;
>         status = "okay";
>         compatible = " fsl,ls1021a-qspi ", "fsl,ls1021a-qspi-nand"; <-- updated compatibility for drivers
>         qflash0: w25q16fw @0 {
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 spi-max-frequency = <20000000>;
>                 reg = <0>;
>                 type = "serial-nor"   <-- Proposed New binding
>                 is-hybrid <-- Proposed New binding
>                 die-num <-- Proposed New binding
>         };
>
>         qflash1: w25n01gw at 1 {
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 spi-max-frequency = <20000000>;
>                 reg = <1>;
>                 type = "serial-nand" <-- Proposed New binding
>                 is-hybrid <-- Proposed New binding
>                 die-num <-- Proposed New binding
>         }
> };

assuming the NOR and NAND parts behave like "normal" SPI-NOR /
SPI-NAND chips when selected, a more appropriate binding might be

&qspi {
    ...
        qflash0: dual-flash at 0 {
                compatible = "winbond,w25q16fw";
                reg = <0>;
                spi-max-frequency = <20000000>;
                #address-cells = <1>;
                #size-cells = <0>;

                nor at 0 {
                                compatible = "jedec,spi-nor";
                                reg = <0>;
                                #address-cells = <1>;
                                #size-cells = <1>;

                                partitions {
                                                ...
                                };
                };

                nand at 1 {
                                compatible = "jedec,spi-nand"; /* or
whatever the correct nand-compatible would be */
                                reg = <1>;
                                #address-cells = <1>;
                                #size-cells = <1>;

                                partitions {
                                                ...
                                };
                };

    };
};

with the "windbond,w25q16fw" driver modeled as a simple
"spi-multiplexer" that registers its own virtual spi-bus. Then when
spi-nor or spi-nand tries to communicate with their appropriate die,
it sends the Software Die Select command if needed and then passes on
the message to its parent bus.

That way there should be no changes needed for spi-nor / spi-nand
themselves. (The devil is probably in the details ;-)


Regards
Jonas