| Message ID | 1530789310-16254-1-git-send-email-frieder.schrempf@exceet.de |
|---|---|
| Headers | show |
| Series | Port the FSL QSPI driver to the SPI framework | expand |
Hi Frieder, These patch series also depends on the patches [1][2] for the controller which can't write nor->page_size bytes in single write command step. Thus, have to invoke Write sequence again and before sending WRITE command, need to send WREN command. [1] https://patchwork.ozlabs.org/patch/928677/ [2] https://patchwork.ozlabs.org/patch/928678/ -- Regards Yogesh Gaur. > -----Original Message----- > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de] > Sent: Thursday, July 5, 2018 4:45 PM > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; linux- > spi@vger.kernel.org > Cc: dwmw2@infradead.org; computersforpeace@gmail.com; > marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com; > broonie@kernel.org; David Wolfe <david.wolfe@nxp.com>; Fabio Estevam > <fabio.estevam@nxp.com>; Prabhakar Kushwaha > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>; > shawnguo@kernel.org; Frieder Schrempf <frieder.schrempf@exceet.de> > Subject: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework > > Now that the SPI memory interface was introduced by Boris [1], it is possible to > move drivers from mtd/spi-nor to the SPI framework in order to use them for > different type of SPI memory chips. > > Patch 1 adds a function spi_mem_get_name() to the SPI memory interface and a > ->name field to struct spi_mem. > Patch 2 uses it in m25p80.c to make it possible for SPI controller drivers to > provide a custom naming scheme for the flash chip. > This is needed to avoid breaking compatibility of mtdparts when switching from > the old to the new driver. > > Patch 3 adds a driver for the Freescale QSPI controller to the SPI framework. > Together with m25p80.c it can be used to interface SPI NOR flashes just as the > old driver did. For this to work properly a few minor changes to the devicetrees > are necessary (see patches 5 to 7). > > Patch 8 changes the defconfigs to use the new driver and patch 9 removes the > old driver. > > Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. > Patch 12 adjusts the MAINTAINERS file. > > The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. > The read performance of the new driver is almost the same or even better than > the old driver, depending on the block size. > The write performance is a bit slower on average (~10-15%). > > The new driver was also tested with the SPI NAND framework [2] and a Winbond > W25M02GV flash. > > If someone has a board that uses both chips selects and/or both busses, it would > be really nice to have the driver be tested on such a setup. > > [1] > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker > nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fbroonie%2Fspi.git%2Fcom > mit%2F%3Fh%3Dfor- > 4.18%26id%3Dc36ff266dc82f4ae797a6f3513c6ffa344f7f1c7&data=02%7C01%7 > Cyogeshnarayan.gaur%40nxp.com%7C77846565197d44d7413008d5e268ccb2% > 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636663862101876439& > sdata=Y8dyVYysfK3Q6vDXUMEBs%2BBygMxh9qM%2ByWdtk9hGyQU%3D&rese > rved=0 > [2] > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch > work.ozlabs.org%2Fcover%2F913728%2F&data=02%7C01%7Cyogeshnarayan.g > aur%40nxp.com%7C77846565197d44d7413008d5e268ccb2%7C686ea1d3bc2b4 > c6fa92cd99c5c301635%7C0%7C0%7C636663862101876439&sdata=VUE5kVY7V > DW0a3PKmQvsUC9TyHZUhhntgM1SJC3EUWU%3D&reserved=0 > > Changes in v2: > ============== > * Rebase on top of nand/next > * Add a name field to struct spi_mem and fill it while probing > * Add Yogesh Gaur and Suresh Gupta as authors > * Use GENMASK() for generating bitmasks > * Use callback functions for read/write of registers > * Attach the seq variable to the selected CS > * Avoid using conditional in read/write loop > * Avoid infinite loop and use a timeout instead > * Return error pointer when allocation in fsl_qspi_get_name() fails > * Remove redundant iounmap() > * Put suspend()/resume() in struct dev_pm_ops instead of struct platform_driver > * Split the moving and editing of the dt-bindings in two patches > > Frieder Schrempf (12): > spi: spi-mem: Extend the SPI mem interface to set a custom memory name > mtd: m25p80: Call spi_mem_get_name() to let controller set a custom > name > spi: Add a driver for the Freescale/NXP QuadSPI controller > dt-bindings: spi: Move the bindings for the FSL QSPI driver > dt-bindings: spi: Adjust the bindings for the FSL QSPI driver > ARM: dts: Reflect change of FSL QSPI driver and remove unused > properties > arm64: dts: Reflect change of FSL QSPI driver and remove unused > properties > ARM: defconfig: Use the new FSL QSPI driver under the SPI framework > mtd: fsl-quadspi: Remove the driver as it was replaced by > spi-fsl-qspi.c > ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used > ARM64: dts: ls1046a: Remove fsl,qspi-has-second-chip as it is not used > MAINTAINERS: Move the Freescale QSPI driver to the SPI framework > > .../devicetree/bindings/mtd/fsl-quadspi.txt | 65 - > .../devicetree/bindings/spi/spi-fsl-qspi.txt | 65 + > MAINTAINERS | 4 +- > arch/arm/boot/dts/imx6sx-sdb-reva.dts | 8 +- > arch/arm/boot/dts/imx6sx-sdb.dts | 8 +- > arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 + > arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 6 +- > arch/arm/configs/imx_v6_v7_defconfig | 2 +- > arch/arm/configs/multi_v7_defconfig | 2 +- > .../boot/dts/freescale/fsl-ls1043a-qds.dts | 3 +- > .../boot/dts/freescale/fsl-ls1046a-qds.dts | 4 +- > .../boot/dts/freescale/fsl-ls1046a-rdb.dts | 6 +- > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 - > .../boot/dts/freescale/fsl-ls208xa-qds.dtsi | 4 + > drivers/mtd/devices/m25p80.c | 3 +- > drivers/mtd/spi-nor/Kconfig | 9 - > drivers/mtd/spi-nor/Makefile | 1 - > drivers/mtd/spi-nor/fsl-quadspi.c | 1217 ------------------ > drivers/spi/Kconfig | 11 + > drivers/spi/Makefile | 1 + > drivers/spi/spi-fsl-qspi.c | 954 ++++++++++++++ > drivers/spi/spi-mem.c | 30 + > include/linux/spi/spi-mem.h | 7 +- > 23 files changed, 1100 insertions(+), 1313 deletions(-) delete mode 100644 > Documentation/devicetree/bindings/mtd/fsl-quadspi.txt > create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt > delete mode 100644 drivers/mtd/spi-nor/fsl-quadspi.c create mode 100644 > drivers/spi/spi-fsl-qspi.c > > -- > 2.7.4
Hi Frieder, Yogesh, On Thu, 5 Jul 2018 13:14:56 +0200 Frieder Schrempf <frieder.schrempf@exceet.de> wrote: > Now that the SPI memory interface was introduced by Boris [1], it is > possible to move drivers from mtd/spi-nor to the SPI framework in order > to use them for different type of SPI memory chips. > > Patch 1 adds a function spi_mem_get_name() to the SPI memory interface > and a ->name field to struct spi_mem. > Patch 2 uses it in m25p80.c to make it possible for SPI controller > drivers to provide a custom naming scheme for the flash chip. > This is needed to avoid breaking compatibility of mtdparts when switching > from the old to the new driver. > > Patch 3 adds a driver for the Freescale QSPI controller to the SPI > framework. Together with m25p80.c it can be used to interface SPI > NOR flashes just as the old driver did. For this to work properly a few > minor changes to the devicetrees are necessary (see patches 5 to 7). > > Patch 8 changes the defconfigs to use the new driver and patch 9 removes > the old driver. > > Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. > Patch 12 adjusts the MAINTAINERS file. > > The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. > The read performance of the new driver is almost the same or even better > than the old driver, depending on the block size. > The write performance is a bit slower on average (~10-15%). > > The new driver was also tested with the SPI NAND framework [2] and a > Winbond W25M02GV flash. > > If someone has a board that uses both chips selects and/or both busses, > it would be really nice to have the driver be tested on such a setup. Any progress on this front? Yogesh, can you please remind us the remaining issues? I'd really like to make some progress, otherwise the conversion to spi-mem will take ages. Regards, Boris
Hi Boris, On 31.10.18 14:40, Boris Brezillon wrote: > Hi Frieder, Yogesh, > > On Thu, 5 Jul 2018 13:14:56 +0200 > Frieder Schrempf <frieder.schrempf@exceet.de> wrote: > >> Now that the SPI memory interface was introduced by Boris [1], it is >> possible to move drivers from mtd/spi-nor to the SPI framework in order >> to use them for different type of SPI memory chips. >> >> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface >> and a ->name field to struct spi_mem. >> Patch 2 uses it in m25p80.c to make it possible for SPI controller >> drivers to provide a custom naming scheme for the flash chip. >> This is needed to avoid breaking compatibility of mtdparts when switching >> from the old to the new driver. >> >> Patch 3 adds a driver for the Freescale QSPI controller to the SPI >> framework. Together with m25p80.c it can be used to interface SPI >> NOR flashes just as the old driver did. For this to work properly a few >> minor changes to the devicetrees are necessary (see patches 5 to 7). >> >> Patch 8 changes the defconfigs to use the new driver and patch 9 removes >> the old driver. >> >> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. >> Patch 12 adjusts the MAINTAINERS file. >> >> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. >> The read performance of the new driver is almost the same or even better >> than the old driver, depending on the block size. >> The write performance is a bit slower on average (~10-15%). >> >> The new driver was also tested with the SPI NAND framework [2] and a >> Winbond W25M02GV flash. >> >> If someone has a board that uses both chips selects and/or both busses, >> it would be really nice to have the driver be tested on such a setup. > > Any progress on this front? Yogesh, can you please remind us the > remaining issues? I'd really like to make some progress, otherwise the > conversion to spi-mem will take ages. I definitely want to continue this. I just did not have the time to work on it. I think the only remaining blocking issues is the one that Yogesh reported while testing with two chips on the same bus. Han and I have both successfully tested with two chips, but on separate buses. Regards, Frieder
On Wed, 31 Oct 2018 13:54:29 +0000 Schrempf Frieder <frieder.schrempf@kontron.De> wrote: > Hi Boris, > > On 31.10.18 14:40, Boris Brezillon wrote: > > Hi Frieder, Yogesh, > > > > On Thu, 5 Jul 2018 13:14:56 +0200 > > Frieder Schrempf <frieder.schrempf@exceet.de> wrote: > > > >> Now that the SPI memory interface was introduced by Boris [1], it is > >> possible to move drivers from mtd/spi-nor to the SPI framework in order > >> to use them for different type of SPI memory chips. > >> > >> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface > >> and a ->name field to struct spi_mem. > >> Patch 2 uses it in m25p80.c to make it possible for SPI controller > >> drivers to provide a custom naming scheme for the flash chip. > >> This is needed to avoid breaking compatibility of mtdparts when switching > >> from the old to the new driver. > >> > >> Patch 3 adds a driver for the Freescale QSPI controller to the SPI > >> framework. Together with m25p80.c it can be used to interface SPI > >> NOR flashes just as the old driver did. For this to work properly a few > >> minor changes to the devicetrees are necessary (see patches 5 to 7). > >> > >> Patch 8 changes the defconfigs to use the new driver and patch 9 removes > >> the old driver. > >> > >> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. > >> Patch 12 adjusts the MAINTAINERS file. > >> > >> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. > >> The read performance of the new driver is almost the same or even better > >> than the old driver, depending on the block size. > >> The write performance is a bit slower on average (~10-15%). > >> > >> The new driver was also tested with the SPI NAND framework [2] and a > >> Winbond W25M02GV flash. > >> > >> If someone has a board that uses both chips selects and/or both busses, > >> it would be really nice to have the driver be tested on such a setup. > > > > Any progress on this front? Yogesh, can you please remind us the > > remaining issues? I'd really like to make some progress, otherwise the > > conversion to spi-mem will take ages. > > I definitely want to continue this. I just did not have the time to work > on it. > > I think the only remaining blocking issues is the one that Yogesh > reported while testing with two chips on the same bus. Maybe you can send a new version rebased on v4.20-rc1 (when it's out) and push it somewhere so that Yogesh can test it (again). Yogesh, can we please make some progress on this? If you really have a bug, that'd be great to have a serious investigation on what is causing this bug. The explanation we had so far were not really helpful in understanding the problem.
Hi Frieder, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] > Sent: Wednesday, October 31, 2018 8:01 PM > To: Schrempf Frieder <frieder.schrempf@kontron.De> > Cc: linux-mtd@lists.infradead.org; linux-spi@vger.kernel.org; > dwmw2@infradead.org; computersforpeace@gmail.com; > marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com; > broonie@kernel.org; David Wolfe <david.wolfe@nxp.com>; Fabio Estevam > <fabio.estevam@nxp.com>; Prabhakar Kushwaha > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>; > shawnguo@kernel.org > Subject: Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework > > On Wed, 31 Oct 2018 13:54:29 +0000 > Schrempf Frieder <frieder.schrempf@kontron.De> wrote: > > > Hi Boris, > > > > On 31.10.18 14:40, Boris Brezillon wrote: > > > Hi Frieder, Yogesh, > > > > > > On Thu, 5 Jul 2018 13:14:56 +0200 > > > Frieder Schrempf <frieder.schrempf@exceet.de> wrote: > > > > > >> Now that the SPI memory interface was introduced by Boris [1], it > > >> is possible to move drivers from mtd/spi-nor to the SPI framework > > >> in order to use them for different type of SPI memory chips. > > >> > > >> Patch 1 adds a function spi_mem_get_name() to the SPI memory > > >> interface and a ->name field to struct spi_mem. > > >> Patch 2 uses it in m25p80.c to make it possible for SPI controller > > >> drivers to provide a custom naming scheme for the flash chip. > > >> This is needed to avoid breaking compatibility of mtdparts when > > >> switching from the old to the new driver. > > >> > > >> Patch 3 adds a driver for the Freescale QSPI controller to the SPI > > >> framework. Together with m25p80.c it can be used to interface SPI > > >> NOR flashes just as the old driver did. For this to work properly a > > >> few minor changes to the devicetrees are necessary (see patches 5 to 7). > > >> > > >> Patch 8 changes the defconfigs to use the new driver and patch 9 > > >> removes the old driver. > > >> > > >> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. > > >> Patch 12 adjusts the MAINTAINERS file. > > >> > > >> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. > > >> The read performance of the new driver is almost the same or even > > >> better than the old driver, depending on the block size. > > >> The write performance is a bit slower on average (~10-15%). > > >> > > >> The new driver was also tested with the SPI NAND framework [2] and > > >> a Winbond W25M02GV flash. > > >> > > >> If someone has a board that uses both chips selects and/or both > > >> busses, it would be really nice to have the driver be tested on such a setup. > > > > > > Any progress on this front? Yogesh, can you please remind us the > > > remaining issues? I'd really like to make some progress, otherwise > > > the conversion to spi-mem will take ages. > > > > I definitely want to continue this. I just did not have the time to > > work on it. > > > > I think the only remaining blocking issues is the one that Yogesh > > reported while testing with two chips on the same bus. > > Maybe you can send a new version rebased on v4.20-rc1 (when it's out) and > push it somewhere so that Yogesh can test it (again). In next version, please take care of the comments being raised by Boris in NXP FlexSPI controller driver patch series. E.g. 1. Redefine all mask fields and use BIT(X) for single bit set/unset. 2. Remove function pointer hooks for ->read/->write function. 3. Remove dependency from 'endianess' property from DTS node. 4. Usage of readl_poll_timeout() instead of busy looping. -- Regards Yogesh Gaur Yogesh, can we please > make some progress on this? If you really have a bug, that'd be great to have a > serious investigation on what is causing this bug. The explanation we had so far > were not really helpful in understanding the problem.
Hi Yogesh, On 31.10.18 17:03, Yogesh Narayan Gaur wrote: > Hi Frieder, > >> -----Original Message----- >> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] >> Sent: Wednesday, October 31, 2018 8:01 PM >> To: Schrempf Frieder <frieder.schrempf@kontron.De> >> Cc: linux-mtd@lists.infradead.org; linux-spi@vger.kernel.org; >> dwmw2@infradead.org; computersforpeace@gmail.com; >> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com; >> broonie@kernel.org; David Wolfe <david.wolfe@nxp.com>; Fabio Estevam >> <fabio.estevam@nxp.com>; Prabhakar Kushwaha >> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur >> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>; >> shawnguo@kernel.org >> Subject: Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework >> >> On Wed, 31 Oct 2018 13:54:29 +0000 >> Schrempf Frieder <frieder.schrempf@kontron.De> wrote: >> >>> Hi Boris, >>> >>> On 31.10.18 14:40, Boris Brezillon wrote: >>>> Hi Frieder, Yogesh, >>>> >>>> On Thu, 5 Jul 2018 13:14:56 +0200 >>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote: >>>> >>>>> Now that the SPI memory interface was introduced by Boris [1], it >>>>> is possible to move drivers from mtd/spi-nor to the SPI framework >>>>> in order to use them for different type of SPI memory chips. >>>>> >>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory >>>>> interface and a ->name field to struct spi_mem. >>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller >>>>> drivers to provide a custom naming scheme for the flash chip. >>>>> This is needed to avoid breaking compatibility of mtdparts when >>>>> switching from the old to the new driver. >>>>> >>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI >>>>> framework. Together with m25p80.c it can be used to interface SPI >>>>> NOR flashes just as the old driver did. For this to work properly a >>>>> few minor changes to the devicetrees are necessary (see patches 5 to 7). >>>>> >>>>> Patch 8 changes the defconfigs to use the new driver and patch 9 >>>>> removes the old driver. >>>>> >>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. >>>>> Patch 12 adjusts the MAINTAINERS file. >>>>> >>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. >>>>> The read performance of the new driver is almost the same or even >>>>> better than the old driver, depending on the block size. >>>>> The write performance is a bit slower on average (~10-15%). >>>>> >>>>> The new driver was also tested with the SPI NAND framework [2] and >>>>> a Winbond W25M02GV flash. >>>>> >>>>> If someone has a board that uses both chips selects and/or both >>>>> busses, it would be really nice to have the driver be tested on such a setup. >>>> >>>> Any progress on this front? Yogesh, can you please remind us the >>>> remaining issues? I'd really like to make some progress, otherwise >>>> the conversion to spi-mem will take ages. >>> >>> I definitely want to continue this. I just did not have the time to >>> work on it. >>> >>> I think the only remaining blocking issues is the one that Yogesh >>> reported while testing with two chips on the same bus. >> >> Maybe you can send a new version rebased on v4.20-rc1 (when it's out) and >> push it somewhere so that Yogesh can test it (again). > In next version, please take care of the comments being raised by Boris in NXP FlexSPI controller driver patch series. E.g. > 1. Redefine all mask fields and use BIT(X) for single bit set/unset. > 2. Remove function pointer hooks for ->read/->write function. > 3. Remove dependency from 'endianess' property from DTS node. > 4. Usage of readl_poll_timeout() instead of busy looping. Thanks for reminding me. I have these on my list. Thanks, Frieder > > -- > Regards > Yogesh Gaur > > Yogesh, can we please >> make some progress on this? If you really have a bug, that'd be great to have a >> serious investigation on what is causing this bug. The explanation we had so far >> were not really helpful in understanding the problem.
Hi Boris, hi Yogesh, On 31.10.18 15:31, Boris Brezillon wrote: > On Wed, 31 Oct 2018 13:54:29 +0000 > Schrempf Frieder <frieder.schrempf@kontron.De> wrote: > >> Hi Boris, >> >> On 31.10.18 14:40, Boris Brezillon wrote: >>> Hi Frieder, Yogesh, >>> >>> On Thu, 5 Jul 2018 13:14:56 +0200 >>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote: >>> >>>> Now that the SPI memory interface was introduced by Boris [1], it is >>>> possible to move drivers from mtd/spi-nor to the SPI framework in order >>>> to use them for different type of SPI memory chips. >>>> >>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface >>>> and a ->name field to struct spi_mem. >>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller >>>> drivers to provide a custom naming scheme for the flash chip. >>>> This is needed to avoid breaking compatibility of mtdparts when switching >>>> from the old to the new driver. >>>> >>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI >>>> framework. Together with m25p80.c it can be used to interface SPI >>>> NOR flashes just as the old driver did. For this to work properly a few >>>> minor changes to the devicetrees are necessary (see patches 5 to 7). >>>> >>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes >>>> the old driver. >>>> >>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. >>>> Patch 12 adjusts the MAINTAINERS file. >>>> >>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. >>>> The read performance of the new driver is almost the same or even better >>>> than the old driver, depending on the block size. >>>> The write performance is a bit slower on average (~10-15%). >>>> >>>> The new driver was also tested with the SPI NAND framework [2] and a >>>> Winbond W25M02GV flash. >>>> >>>> If someone has a board that uses both chips selects and/or both busses, >>>> it would be really nice to have the driver be tested on such a setup. >>> >>> Any progress on this front? Yogesh, can you please remind us the >>> remaining issues? I'd really like to make some progress, otherwise the >>> conversion to spi-mem will take ages. >> >> I definitely want to continue this. I just did not have the time to work >> on it. >> >> I think the only remaining blocking issues is the one that Yogesh >> reported while testing with two chips on the same bus. > > Maybe you can send a new version rebased on v4.20-rc1 (when it's out) > and push it somewhere so that Yogesh can test it (again). Yogesh, can we > please make some progress on this? If you really have a bug, that'd be > great to have a serious investigation on what is causing this bug. The > explanation we had so far were not really helpful in understanding the > problem. I have sent a v4 that is based on v4.20-rc1. I only applied small fixes and cosmetic changes. There is still the hack to avoid AHB buffer invalidation delay (not sure if we should keep it for now) and we still need to figure out the reported problems with two chips on one bus. As Yogesh is the only one how has a hardware setup for this, maybe you can retry and provide some debugging info? Unfortunately I'll probably do not have time to switch to the dirmap API now, so I'd rather do that as a second step, as it probably won't solve our problems either. Thanks, Frieder
Hi Frieder, On Thu, 8 Nov 2018 08:15:55 +0000 Schrempf Frieder <frieder.schrempf@kontron.De> wrote: > Hi Boris, hi Yogesh, > > On 31.10.18 15:31, Boris Brezillon wrote: > > On Wed, 31 Oct 2018 13:54:29 +0000 > > Schrempf Frieder <frieder.schrempf@kontron.De> wrote: > > > >> Hi Boris, > >> > >> On 31.10.18 14:40, Boris Brezillon wrote: > >>> Hi Frieder, Yogesh, > >>> > >>> On Thu, 5 Jul 2018 13:14:56 +0200 > >>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote: > >>> > >>>> Now that the SPI memory interface was introduced by Boris [1], it is > >>>> possible to move drivers from mtd/spi-nor to the SPI framework in order > >>>> to use them for different type of SPI memory chips. > >>>> > >>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface > >>>> and a ->name field to struct spi_mem. > >>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller > >>>> drivers to provide a custom naming scheme for the flash chip. > >>>> This is needed to avoid breaking compatibility of mtdparts when switching > >>>> from the old to the new driver. > >>>> > >>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI > >>>> framework. Together with m25p80.c it can be used to interface SPI > >>>> NOR flashes just as the old driver did. For this to work properly a few > >>>> minor changes to the devicetrees are necessary (see patches 5 to 7). > >>>> > >>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes > >>>> the old driver. > >>>> > >>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. > >>>> Patch 12 adjusts the MAINTAINERS file. > >>>> > >>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. > >>>> The read performance of the new driver is almost the same or even better > >>>> than the old driver, depending on the block size. > >>>> The write performance is a bit slower on average (~10-15%). > >>>> > >>>> The new driver was also tested with the SPI NAND framework [2] and a > >>>> Winbond W25M02GV flash. > >>>> > >>>> If someone has a board that uses both chips selects and/or both busses, > >>>> it would be really nice to have the driver be tested on such a setup. > >>> > >>> Any progress on this front? Yogesh, can you please remind us the > >>> remaining issues? I'd really like to make some progress, otherwise the > >>> conversion to spi-mem will take ages. > >> > >> I definitely want to continue this. I just did not have the time to work > >> on it. > >> > >> I think the only remaining blocking issues is the one that Yogesh > >> reported while testing with two chips on the same bus. > > > > Maybe you can send a new version rebased on v4.20-rc1 (when it's out) > > and push it somewhere so that Yogesh can test it (again). Yogesh, can we > > please make some progress on this? If you really have a bug, that'd be > > great to have a serious investigation on what is causing this bug. The > > explanation we had so far were not really helpful in understanding the > > problem. > > I have sent a v4 that is based on v4.20-rc1. I only applied small fixes > and cosmetic changes. > > There is still the hack to avoid AHB buffer invalidation delay (not sure > if we should keep it for now) IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay. Maybe you can try that. > and we still need to figure out the > reported problems with two chips on one bus. > > As Yogesh is the only one how has a hardware setup for this, maybe you > can retry and provide some debugging info? > > Unfortunately I'll probably do not have time to switch to the dirmap API > now, so I'd rather do that as a second step, as it probably won't solve > our problems either. Totally agree with that. Thanks for sending a v4. Boris
On 08.11.18 09:19, Boris Brezillon wrote: > Hi Frieder, > > On Thu, 8 Nov 2018 08:15:55 +0000 > Schrempf Frieder <frieder.schrempf@kontron.De> wrote: > >> Hi Boris, hi Yogesh, >> >> On 31.10.18 15:31, Boris Brezillon wrote: >>> On Wed, 31 Oct 2018 13:54:29 +0000 >>> Schrempf Frieder <frieder.schrempf@kontron.De> wrote: >>> >>>> Hi Boris, >>>> >>>> On 31.10.18 14:40, Boris Brezillon wrote: >>>>> Hi Frieder, Yogesh, >>>>> >>>>> On Thu, 5 Jul 2018 13:14:56 +0200 >>>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote: >>>>> >>>>>> Now that the SPI memory interface was introduced by Boris [1], it is >>>>>> possible to move drivers from mtd/spi-nor to the SPI framework in order >>>>>> to use them for different type of SPI memory chips. >>>>>> >>>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface >>>>>> and a ->name field to struct spi_mem. >>>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller >>>>>> drivers to provide a custom naming scheme for the flash chip. >>>>>> This is needed to avoid breaking compatibility of mtdparts when switching >>>>>> from the old to the new driver. >>>>>> >>>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI >>>>>> framework. Together with m25p80.c it can be used to interface SPI >>>>>> NOR flashes just as the old driver did. For this to work properly a few >>>>>> minor changes to the devicetrees are necessary (see patches 5 to 7). >>>>>> >>>>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes >>>>>> the old driver. >>>>>> >>>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. >>>>>> Patch 12 adjusts the MAINTAINERS file. >>>>>> >>>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. >>>>>> The read performance of the new driver is almost the same or even better >>>>>> than the old driver, depending on the block size. >>>>>> The write performance is a bit slower on average (~10-15%). >>>>>> >>>>>> The new driver was also tested with the SPI NAND framework [2] and a >>>>>> Winbond W25M02GV flash. >>>>>> >>>>>> If someone has a board that uses both chips selects and/or both busses, >>>>>> it would be really nice to have the driver be tested on such a setup. >>>>> >>>>> Any progress on this front? Yogesh, can you please remind us the >>>>> remaining issues? I'd really like to make some progress, otherwise the >>>>> conversion to spi-mem will take ages. >>>> >>>> I definitely want to continue this. I just did not have the time to work >>>> on it. >>>> >>>> I think the only remaining blocking issues is the one that Yogesh >>>> reported while testing with two chips on the same bus. >>> >>> Maybe you can send a new version rebased on v4.20-rc1 (when it's out) >>> and push it somewhere so that Yogesh can test it (again). Yogesh, can we >>> please make some progress on this? If you really have a bug, that'd be >>> great to have a serious investigation on what is causing this bug. The >>> explanation we had so far were not really helpful in understanding the >>> problem. >> >> I have sent a v4 that is based on v4.20-rc1. I only applied small fixes >> and cosmetic changes. >> >> There is still the hack to avoid AHB buffer invalidation delay (not sure >> if we should keep it for now) > > IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay. > Maybe you can try that. Right, I will do some experiments. >> and we still need to figure out the >> reported problems with two chips on one bus. >> >> As Yogesh is the only one how has a hardware setup for this, maybe you >> can retry and provide some debugging info? >> >> Unfortunately I'll probably do not have time to switch to the dirmap API >> now, so I'd rather do that as a second step, as it probably won't solve >> our problems either. > > Totally agree with that. > > Thanks for sending a v4. > > Boris >
On 08.11.18 09:19, Boris Brezillon wrote: > Hi Frieder, > > On Thu, 8 Nov 2018 08:15:55 +0000 > Schrempf Frieder <frieder.schrempf@kontron.De> wrote: > >> Hi Boris, hi Yogesh, >> >> On 31.10.18 15:31, Boris Brezillon wrote: >>> On Wed, 31 Oct 2018 13:54:29 +0000 >>> Schrempf Frieder <frieder.schrempf@kontron.De> wrote: >>> >>>> Hi Boris, >>>> >>>> On 31.10.18 14:40, Boris Brezillon wrote: >>>>> Hi Frieder, Yogesh, >>>>> >>>>> On Thu, 5 Jul 2018 13:14:56 +0200 >>>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote: >>>>> >>>>>> Now that the SPI memory interface was introduced by Boris [1], it is >>>>>> possible to move drivers from mtd/spi-nor to the SPI framework in order >>>>>> to use them for different type of SPI memory chips. >>>>>> >>>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface >>>>>> and a ->name field to struct spi_mem. >>>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller >>>>>> drivers to provide a custom naming scheme for the flash chip. >>>>>> This is needed to avoid breaking compatibility of mtdparts when switching >>>>>> from the old to the new driver. >>>>>> >>>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI >>>>>> framework. Together with m25p80.c it can be used to interface SPI >>>>>> NOR flashes just as the old driver did. For this to work properly a few >>>>>> minor changes to the devicetrees are necessary (see patches 5 to 7). >>>>>> >>>>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes >>>>>> the old driver. >>>>>> >>>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. >>>>>> Patch 12 adjusts the MAINTAINERS file. >>>>>> >>>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. >>>>>> The read performance of the new driver is almost the same or even better >>>>>> than the old driver, depending on the block size. >>>>>> The write performance is a bit slower on average (~10-15%). >>>>>> >>>>>> The new driver was also tested with the SPI NAND framework [2] and a >>>>>> Winbond W25M02GV flash. >>>>>> >>>>>> If someone has a board that uses both chips selects and/or both busses, >>>>>> it would be really nice to have the driver be tested on such a setup. >>>>> >>>>> Any progress on this front? Yogesh, can you please remind us the >>>>> remaining issues? I'd really like to make some progress, otherwise the >>>>> conversion to spi-mem will take ages. >>>> >>>> I definitely want to continue this. I just did not have the time to work >>>> on it. >>>> >>>> I think the only remaining blocking issues is the one that Yogesh >>>> reported while testing with two chips on the same bus. >>> >>> Maybe you can send a new version rebased on v4.20-rc1 (when it's out) >>> and push it somewhere so that Yogesh can test it (again). Yogesh, can we >>> please make some progress on this? If you really have a bug, that'd be >>> great to have a serious investigation on what is causing this bug. The >>> explanation we had so far were not really helpful in understanding the >>> problem. >> >> I have sent a v4 that is based on v4.20-rc1. I only applied small fixes >> and cosmetic changes. I forgot to add, that I have pushed the v4 here if someone needs it: https://github.com/fschrempf/linux/commits/fsl-qspi-next-4 >> >> There is still the hack to avoid AHB buffer invalidation delay (not sure >> if we should keep it for now) > > IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay. > Maybe you can try that. > >> and we still need to figure out the >> reported problems with two chips on one bus. >> >> As Yogesh is the only one how has a hardware setup for this, maybe you >> can retry and provide some debugging info? >> >> Unfortunately I'll probably do not have time to switch to the dirmap API >> now, so I'd rather do that as a second step, as it probably won't solve >> our problems either. > > Totally agree with that. > > Thanks for sending a v4. > > Boris >
Now that the SPI memory interface was introduced by Boris [1], it is possible to move drivers from mtd/spi-nor to the SPI framework in order to use them for different type of SPI memory chips. Patch 1 adds a function spi_mem_get_name() to the SPI memory interface and a ->name field to struct spi_mem. Patch 2 uses it in m25p80.c to make it possible for SPI controller drivers to provide a custom naming scheme for the flash chip. This is needed to avoid breaking compatibility of mtdparts when switching from the old to the new driver. Patch 3 adds a driver for the Freescale QSPI controller to the SPI framework. Together with m25p80.c it can be used to interface SPI NOR flashes just as the old driver did. For this to work properly a few minor changes to the devicetrees are necessary (see patches 5 to 7). Patch 8 changes the defconfigs to use the new driver and patch 9 removes the old driver. Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees. Patch 12 adjusts the MAINTAINERS file. The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz. The read performance of the new driver is almost the same or even better than the old driver, depending on the block size. The write performance is a bit slower on average (~10-15%). The new driver was also tested with the SPI NAND framework [2] and a Winbond W25M02GV flash. If someone has a board that uses both chips selects and/or both busses, it would be really nice to have the driver be tested on such a setup. [1] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/commit/?h=for-4.18&id=c36ff266dc82f4ae797a6f3513c6ffa344f7f1c7 [2] https://patchwork.ozlabs.org/cover/913728/ Changes in v2: ============== * Rebase on top of nand/next * Add a name field to struct spi_mem and fill it while probing * Add Yogesh Gaur and Suresh Gupta as authors * Use GENMASK() for generating bitmasks * Use callback functions for read/write of registers * Attach the seq variable to the selected CS * Avoid using conditional in read/write loop * Avoid infinite loop and use a timeout instead * Return error pointer when allocation in fsl_qspi_get_name() fails * Remove redundant iounmap() * Put suspend()/resume() in struct dev_pm_ops instead of struct platform_driver * Split the moving and editing of the dt-bindings in two patches Frieder Schrempf (12): spi: spi-mem: Extend the SPI mem interface to set a custom memory name mtd: m25p80: Call spi_mem_get_name() to let controller set a custom name spi: Add a driver for the Freescale/NXP QuadSPI controller dt-bindings: spi: Move the bindings for the FSL QSPI driver dt-bindings: spi: Adjust the bindings for the FSL QSPI driver ARM: dts: Reflect change of FSL QSPI driver and remove unused properties arm64: dts: Reflect change of FSL QSPI driver and remove unused properties ARM: defconfig: Use the new FSL QSPI driver under the SPI framework mtd: fsl-quadspi: Remove the driver as it was replaced by spi-fsl-qspi.c ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used ARM64: dts: ls1046a: Remove fsl,qspi-has-second-chip as it is not used MAINTAINERS: Move the Freescale QSPI driver to the SPI framework .../devicetree/bindings/mtd/fsl-quadspi.txt | 65 - .../devicetree/bindings/spi/spi-fsl-qspi.txt | 65 + MAINTAINERS | 4 +- arch/arm/boot/dts/imx6sx-sdb-reva.dts | 8 +- arch/arm/boot/dts/imx6sx-sdb.dts | 8 +- arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 + arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 6 +- arch/arm/configs/imx_v6_v7_defconfig | 2 +- arch/arm/configs/multi_v7_defconfig | 2 +- .../boot/dts/freescale/fsl-ls1043a-qds.dts | 3 +- .../boot/dts/freescale/fsl-ls1046a-qds.dts | 4 +- .../boot/dts/freescale/fsl-ls1046a-rdb.dts | 6 +- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 - .../boot/dts/freescale/fsl-ls208xa-qds.dtsi | 4 + drivers/mtd/devices/m25p80.c | 3 +- drivers/mtd/spi-nor/Kconfig | 9 - drivers/mtd/spi-nor/Makefile | 1 - drivers/mtd/spi-nor/fsl-quadspi.c | 1217 ------------------ drivers/spi/Kconfig | 11 + drivers/spi/Makefile | 1 + drivers/spi/spi-fsl-qspi.c | 954 ++++++++++++++ drivers/spi/spi-mem.c | 30 + include/linux/spi/spi-mem.h | 7 +- 23 files changed, 1100 insertions(+), 1313 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/fsl-quadspi.txt create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt delete mode 100644 drivers/mtd/spi-nor/fsl-quadspi.c create mode 100644 drivers/spi/spi-fsl-qspi.c