| Message ID | 20180515150825.19835-1-boris.brezillon@bootlin.com |
|---|---|
| Headers | show |
| Series | mtd: Add a SPI NAND driver | expand |
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. What about the controllers which are supporting NOR and NAND flash. How they are going to co-exist. Are we supposed to have 2 flavor of driver. One in driver/mtd/spi-nor and driver/spi? --pk
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.
> -----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. Hence driver/spi/fsl_qspi has to support both SP NOR and SP NAND under control of mtd/nand or mtd/mp2580.c driver. --pk
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 > > > >