Re: [PATCH v7 0/5] mtd: Add a SPI NAND driver

[Frieder Schrempf <frieder.schrempf@exceet.de>]

Hi Prabhakar,

On 17.05.2018 12:01, Prabhakar Kushwaha wrote:
> 
>> -----Original Message-----
>> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
>> Sent: Thursday, May 17, 2018 12:35 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
>> Cc: David Woodhouse <dwmw2@infradead.org>; Brian Norris
>> <computersforpeace@gmail.com>; Marek Vasut
>> <marek.vasut@gmail.com>; Richard Weinberger <richard@nod.at>; linux-
>> mtd@lists.infradead.org; Miquel Raynal <miquel.raynal@bootlin.com>; Peter
>> Pan <peterpansjtu@gmail.com>; Frieder Schrempf
>> <frieder.schrempf@exceet.de>; Vignesh R <vigneshr@ti.com>; Xiangsheng
>> Hou <xiangsheng.hou@mediatek.com>; Ashish Kumar
>> <ashish.kumar@nxp.com>; Yogesh Narayan Gaur
>> <yogeshnarayan.gaur@nxp.com>; Poonam Aggrwal
>> <poonam.aggrwal@nxp.com>
>> Subject: Re: [PATCH v7 0/5] mtd: Add a SPI NAND driver
>>
>> On Thu, 17 May 2018 06:33:36 +0000
>> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> wrote:
>>
>>> Dear Boris,
>>>
>>>
>>>> -----Original Message-----
>>>> From: linux-mtd [mailto:linux-mtd-bounces@lists.infradead.org] On
>>>> Behalf Of Boris Brezillon
>>>> Sent: Tuesday, May 15, 2018 8:38 PM
>>>> To: David Woodhouse <dwmw2@infradead.org>; Brian Norris
>>>> <computersforpeace@gmail.com>; Boris Brezillon
>>>> <boris.brezillon@bootlin.com>; Marek Vasut <marek.vasut@gmail.com>;
>>>> Richard Weinberger <richard@nod.at>; linux-mtd@lists.infradead.org;
>>>> Miquel Raynal <miquel.raynal@bootlin.com>
>>>> Cc: Peter Pan <peterpansjtu@gmail.com>; Frieder Schrempf
>>>> <frieder.schrempf@exceet.de>; Vignesh R <vigneshr@ti.com>;
>>>> Xiangsheng Hou <xiangsheng.hou@mediatek.com>
>>>> Subject: [PATCH v7 0/5] mtd: Add a SPI NAND driver
>>>>
>>>> Hello,
>>>>
>>>> This is a brand new version of the SPI NAND framework initially
>>>> proposed by Peter. Note that this version has little in common with
>>>> the previous one, mainly because it's been reworked to use the SPI
>>>> mem interface (which allowed us to get rid of the complex NAND
>> initialization/registration logic).
>>>>
>>>> Also, this version now natively supports on-die ECC and multi-die
>>>> chips (which was required to expose the 256MB of the W25M02GV chip).
>>>> I know I initially asked Peter to not support on-die ECC in the
>>>> first version of the framework so that we can work on a proper
>>>> abstraction for ECC controllers, but I ended up implementing it,
>>>> since all the chips seem to have on-die ECC and the implementation was
>> not that complicated.
>>>>
>>>> I'm not giving up on the "ECC controller abstraction" stuff, but
>>>> with this initial implementation we at least have usable SPI NAND
>>>> support, which should give us some time for complex setups with
>> external ECC controllers.
>>>>
>>>> Just a few details about the patches in this series:
>>>>
>>>> Patch 1 is just extending the nand_page_io_req structure to pass
>>>> information about the access mode (ECC enabled/disabled) so that we
>>>> can use that in the SPI NAND framework to decide whether on-die ECC
>>>> should be enabled or not.
>>>>
>>>> Patch 2 is adding the core infrastructure to handle SPI NANDs, and
>>>> patch 3 is decribing the SPI NAND bindings.
>>>>
>>>> Patch 4 and 5 add support for 2 different chips, one from Micron and
>>>> one from Winbond.
>>>>
>>>> Comments/reviews are welcome.
>>>>
>>>> Thanks,
>>>>
>>>> Boris
>>>>
>>>> v7 changes:
>>>> - Use the spi-mem interface
>>>
>>> This is putting requirement for having controller driver in  driver/spi.
>>
>> Yes.
>>
>>> What about the controllers which are supporting NOR and NAND flash.
>> How they are going to co-exist.
>>
>> Can you give an example (with a datasheet or a detailed description) of what
>> you call a controller that supports NOR or NAND. AFAICT, all SPI controllers
>> can support NANDs and NORs, because all they do is send spi-mem
>> operations to the device, no matter if the operation is NAND or NOR related.
>>
>>>
>>> Are we supposed to have 2 flavor of driver. One in driver/mtd/spi-nor and
>> driver/spi?
>>
>> Definitely not. You should have one driver in drivers/spi/ and the SPI NOR
>> layer should access this controller through the m25p80 driver. If you need
>> features that are not yet supported by the spi-mem API, then we should
>> discuss it, 'cause the goal is to have all SPI controller drivers in drivers/spi/
>> instead of creating one interface per memory type.
>>
> 
> Currently NXP has fsl_qspi driver is placed in driver/mtd/spi-nor.  QSPI controller(hardware) can support both SPI NOR,  SPI NAND flashes.
> 
> fsl_qspi is currently supporting Serial NOR.
> 
> As NXP will be adding support SPI NAND with fsl_qspi driver in near future.
> This means  a transition is required from driver/mtd/spi-nor/fsl_qspi.c to driver/spi.

I'm currently working on this transition based on Boris' PoC driver [1]. 
I have to do some testing with SPI NOR and then I think I'm ready to 
prepare a first version. Have you already started working on this?

Also it would be nice to test this with hardware that uses multiple 
(2-4) SPI NAND / SPI NOR chips on both buses and using chip selects. Do 
you have such hardware available for testing?

> 
> Hence driver/spi/fsl_qspi has to support both SP NOR and SP NAND under control of mtd/nand or mtd/mp2580.c driver.

The new driver will use the spi-mem interface and therefore can be used 
by mtd/nand/spi and by m25p80.c. So it doesn't need to support two 
interfaces.

Regards,

Frieder

[1] 
https://github.com/bbrezillon/linux-0day/blob/spi-mem/drivers/spi/spi-fsl-qspi.c

> 
> --pk
> 
> 
> 
>