| Message ID | 20181216084854.GJ13243@dragon |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL] FSL QSPI device tree cleanup for 4.21 | expand |
On Sun, Dec 16, 2018 at 9:50 AM Shawn Guo <shawnguo@kernel.org> wrote: > > Hi, > > As the series cleans up both i.MX/Freescale arm32 and arm64 device > trees, the pull request is based on a merge of tag imx-dt-4.21 and > imx-dt64-4.21 that have already been pulled into arm-soc next/dt branch. > This comes a bit late, and we appreciate it if you can pull it for 4.21, > as it paves the way for new QSPI driver under SPI framework to land in > the next release cycle. Thanks. Pulled into next/dt. For my understanding, what is going to happen with the fsl-quadspi mtd driver? Will it remain as part of the kernel to support old DTB files, or will that transitions mean those stop working with new kernels and have to be updated the same way? Thanks, Arnd
Hi Arnd, On 20.12.18 16:50, Arnd Bergmann wrote: > On Sun, Dec 16, 2018 at 9:50 AM Shawn Guo <shawnguo@kernel.org> wrote: >> >> Hi, >> >> As the series cleans up both i.MX/Freescale arm32 and arm64 device >> trees, the pull request is based on a merge of tag imx-dt-4.21 and >> imx-dt64-4.21 that have already been pulled into arm-soc next/dt branch. >> This comes a bit late, and we appreciate it if you can pull it for 4.21, >> as it paves the way for new QSPI driver under SPI framework to land in >> the next release cycle. Thanks. > > Pulled into next/dt. For my understanding, what is going to happen > with the fsl-quadspi mtd driver? Will it remain as part of the kernel > to support old DTB files, or will that transitions mean those stop > working with new kernels and have to be updated the same way? Thanks for pulling these late changes. The old SPI NOR driver (fsl-quadspi.c) will be replaced by the new SPI driver. Old dtb files will work with the new driver if they already have the reg properties set up correctly (which should be the case, but who knows what setups exist out-of-tree). There will be a performance penalty though if you do not set spi-[tx/rx]-bus-width to 4. For reference here is the latest set of patches: https://patchwork.ozlabs.org/cover/1007641/ Thanks, Frieder
On Thu, Dec 20, 2018 at 5:03 PM Schrempf Frieder <frieder.schrempf@kontron.de> wrote: > > Hi Arnd, > > On 20.12.18 16:50, Arnd Bergmann wrote: > > On Sun, Dec 16, 2018 at 9:50 AM Shawn Guo <shawnguo@kernel.org> wrote: > >> > >> Hi, > >> > >> As the series cleans up both i.MX/Freescale arm32 and arm64 device > >> trees, the pull request is based on a merge of tag imx-dt-4.21 and > >> imx-dt64-4.21 that have already been pulled into arm-soc next/dt branch. > >> This comes a bit late, and we appreciate it if you can pull it for 4.21, > >> as it paves the way for new QSPI driver under SPI framework to land in > >> the next release cycle. Thanks. > > > > Pulled into next/dt. For my understanding, what is going to happen > > with the fsl-quadspi mtd driver? Will it remain as part of the kernel > > to support old DTB files, or will that transitions mean those stop > > working with new kernels and have to be updated the same way? > > Thanks for pulling these late changes. The old SPI NOR driver > (fsl-quadspi.c) will be replaced by the new SPI driver. Old dtb files > will work with the new driver if they already have the reg properties > set up correctly (which should be the case, but who knows what setups > exist out-of-tree). Ok, good. > There will be a performance penalty though if you do not set > spi-[tx/rx]-bus-width to 4. I guess that's acceptable, but what is the reason for requiring this? Would it be possible to have the qspi driver add those properties and print a warning whenever the dtb doesn't already contain them? Arnd
On 20.12.18 17:11, Arnd Bergmann wrote: > On Thu, Dec 20, 2018 at 5:03 PM Schrempf Frieder > <frieder.schrempf@kontron.de> wrote: >> >> Hi Arnd, >> >> On 20.12.18 16:50, Arnd Bergmann wrote: >>> On Sun, Dec 16, 2018 at 9:50 AM Shawn Guo <shawnguo@kernel.org> wrote: >>>> >>>> Hi, >>>> >>>> As the series cleans up both i.MX/Freescale arm32 and arm64 device >>>> trees, the pull request is based on a merge of tag imx-dt-4.21 and >>>> imx-dt64-4.21 that have already been pulled into arm-soc next/dt branch. >>>> This comes a bit late, and we appreciate it if you can pull it for 4.21, >>>> as it paves the way for new QSPI driver under SPI framework to land in >>>> the next release cycle. Thanks. >>> >>> Pulled into next/dt. For my understanding, what is going to happen >>> with the fsl-quadspi mtd driver? Will it remain as part of the kernel >>> to support old DTB files, or will that transitions mean those stop >>> working with new kernels and have to be updated the same way? >> >> Thanks for pulling these late changes. The old SPI NOR driver >> (fsl-quadspi.c) will be replaced by the new SPI driver. Old dtb files >> will work with the new driver if they already have the reg properties >> set up correctly (which should be the case, but who knows what setups >> exist out-of-tree). > > Ok, good. > >> There will be a performance penalty though if you do not set >> spi-[tx/rx]-bus-width to 4. > > I guess that's acceptable, but what is the reason for requiring > this? Would it be possible to have the qspi driver add those > properties and print a warning whenever the dtb doesn't > already contain them? As the new driver is a SPI driver, the common rules in Documentation/devicetree/bindings/spi/spi-bus.txt apply and spi-[tx/rx]-bus-width are defined to default to 1 if not specified. So we can't set those properties in the driver if they are missing in the dtb as we would deviate from the standard, although it would make more sense for a *Quad*-SPI driver to default to 4.
On Thu, Dec 20, 2018 at 5:23 PM Schrempf Frieder <frieder.schrempf@kontron.de> wrote: > > On 20.12.18 17:11, Arnd Bergmann wrote: > > On Thu, Dec 20, 2018 at 5:03 PM Schrempf Frieder > > <frieder.schrempf@kontron.de> wrote: > >> > >> Hi Arnd, > >> > >> On 20.12.18 16:50, Arnd Bergmann wrote: > >>> On Sun, Dec 16, 2018 at 9:50 AM Shawn Guo <shawnguo@kernel.org> wrote: > >>>> > >>>> Hi, > >>>> > >>>> As the series cleans up both i.MX/Freescale arm32 and arm64 device > >>>> trees, the pull request is based on a merge of tag imx-dt-4.21 and > >>>> imx-dt64-4.21 that have already been pulled into arm-soc next/dt branch. > >>>> This comes a bit late, and we appreciate it if you can pull it for 4.21, > >>>> as it paves the way for new QSPI driver under SPI framework to land in > >>>> the next release cycle. Thanks. > >>> > >>> Pulled into next/dt. For my understanding, what is going to happen > >>> with the fsl-quadspi mtd driver? Will it remain as part of the kernel > >>> to support old DTB files, or will that transitions mean those stop > >>> working with new kernels and have to be updated the same way? > >> > >> Thanks for pulling these late changes. The old SPI NOR driver > >> (fsl-quadspi.c) will be replaced by the new SPI driver. Old dtb files > >> will work with the new driver if they already have the reg properties > >> set up correctly (which should be the case, but who knows what setups > >> exist out-of-tree). > > > > Ok, good. > > > >> There will be a performance penalty though if you do not set > >> spi-[tx/rx]-bus-width to 4. > > > > I guess that's acceptable, but what is the reason for requiring > > this? Would it be possible to have the qspi driver add those > > properties and print a warning whenever the dtb doesn't > > already contain them? > > As the new driver is a SPI driver, the common rules in > Documentation/devicetree/bindings/spi/spi-bus.txt apply and > spi-[tx/rx]-bus-width are defined to default to 1 if not specified. > So we can't set those properties in the driver if they are missing in > the dtb as we would deviate from the standard, although it would make > more sense for a *Quad*-SPI driver to default to 4. Right, I guess that makes sense. Now, you could change the binding for the fsl-quadspi driver to require the bus-width properties, which would then just make the old dtb files invalid, and you give us an excuse to override the properties by adding the =4 ones, once that is documented in the driver specific binding. Since it's only a performance difference, I suppose we can live with the limitation and stay a little closer to the normal binding. Arnd
Hi Arnd, On Thu, Dec 20, 2018 at 5:33 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Thu, Dec 20, 2018 at 5:23 PM Schrempf Frieder > <frieder.schrempf@kontron.de> wrote: > > On 20.12.18 17:11, Arnd Bergmann wrote: > > > On Thu, Dec 20, 2018 at 5:03 PM Schrempf Frieder > > > <frieder.schrempf@kontron.de> wrote: > > >> > > >> On 20.12.18 16:50, Arnd Bergmann wrote: > > >>> On Sun, Dec 16, 2018 at 9:50 AM Shawn Guo <shawnguo@kernel.org> wrote: > > >>>> As the series cleans up both i.MX/Freescale arm32 and arm64 device > > >>>> trees, the pull request is based on a merge of tag imx-dt-4.21 and > > >>>> imx-dt64-4.21 that have already been pulled into arm-soc next/dt branch. > > >>>> This comes a bit late, and we appreciate it if you can pull it for 4.21, > > >>>> as it paves the way for new QSPI driver under SPI framework to land in > > >>>> the next release cycle. Thanks. > > >>> > > >>> Pulled into next/dt. For my understanding, what is going to happen > > >>> with the fsl-quadspi mtd driver? Will it remain as part of the kernel > > >>> to support old DTB files, or will that transitions mean those stop > > >>> working with new kernels and have to be updated the same way? > > >> > > >> Thanks for pulling these late changes. The old SPI NOR driver > > >> (fsl-quadspi.c) will be replaced by the new SPI driver. Old dtb files > > >> will work with the new driver if they already have the reg properties > > >> set up correctly (which should be the case, but who knows what setups > > >> exist out-of-tree). > > > > > > Ok, good. > > > > > >> There will be a performance penalty though if you do not set > > >> spi-[tx/rx]-bus-width to 4. > > > > > > I guess that's acceptable, but what is the reason for requiring > > > this? Would it be possible to have the qspi driver add those > > > properties and print a warning whenever the dtb doesn't > > > already contain them? > > > > As the new driver is a SPI driver, the common rules in > > Documentation/devicetree/bindings/spi/spi-bus.txt apply and > > spi-[tx/rx]-bus-width are defined to default to 1 if not specified. > > So we can't set those properties in the driver if they are missing in > > the dtb as we would deviate from the standard, although it would make > > more sense for a *Quad*-SPI driver to default to 4. > > Right, I guess that makes sense. > > Now, you could change the binding for the fsl-quadspi driver to > require the bus-width properties, which would then just make > the old dtb files invalid, and you give us an excuse to override > the properties by adding the =4 ones, once that is documented > in the driver specific binding. > > Since it's only a performance difference, I suppose we can live > with the limitation and stay a little closer to the normal binding. Please note that a quad-capable SPI FLASH may be physically wired to a quad-capable SPI controller using only 2 wires, so defaulting to 4 may cause issues. Defaulting to 2 may work, if the device is dual-capable. Gr{oetje,eeting}s, Geert
On Thu, Dec 20, 2018 at 7:23 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Dec 20, 2018 at 5:33 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Dec 20, 2018 at 5:23 PM Schrempf Frieder > > > As the new driver is a SPI driver, the common rules in > > > Documentation/devicetree/bindings/spi/spi-bus.txt apply and > > > spi-[tx/rx]-bus-width are defined to default to 1 if not specified. > > > So we can't set those properties in the driver if they are missing in > > > the dtb as we would deviate from the standard, although it would make > > > more sense for a *Quad*-SPI driver to default to 4. > > > > Right, I guess that makes sense. > > > > Now, you could change the binding for the fsl-quadspi driver to > > require the bus-width properties, which would then just make > > the old dtb files invalid, and you give us an excuse to override > > the properties by adding the =4 ones, once that is documented > > in the driver specific binding. > > > > Since it's only a performance difference, I suppose we can live > > with the limitation and stay a little closer to the normal binding. > > Please note that a quad-capable SPI FLASH may be physically wired > to a quad-capable SPI controller using only 2 wires, so defaulting to > 4 may cause issues. Defaulting to 2 may work, if the device is > dual-capable. Right, this would only work because the old driver used 4 wires in the absence of the DT property, and the driver would warn when it's not there for new dtb files. Arnd
Hi, As the series cleans up both i.MX/Freescale arm32 and arm64 device trees, the pull request is based on a merge of tag imx-dt-4.21 and imx-dt64-4.21 that have already been pulled into arm-soc next/dt branch. This comes a bit late, and we appreciate it if you can pull it for 4.21, as it paves the way for new QSPI driver under SPI framework to land in the next release cycle. Thanks. Shawn The following changes since commit 744284fa15a1acc8601ddc0a349678e033100925: Merge tag 'imx-dt64-4.21' into imx/qspi-dt (2018-12-16 16:20:47 +0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-qspi-dt-clean for you to fetch changes up to 30648e9f864774388d261f42e79955362f4739e7: arm64: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller (2018-12-16 16:24:01 +0800) ---------------------------------------------------------------- Freescale QSPI device tree cleanup for 4.21: - It contains a series from Schrempf Frieder that cleans up FSL QSPI device tree nodes. The current device trees are broken because they use an inconsistent scheme for assigning the reg properties. It becomes a problem with ongoing QSPI driver under SPI framework. So the cleanup is a preparation for new driver landing in the next cycle. ---------------------------------------------------------------- Frieder Schrempf (5): ARM: dts: Remove unused properties from FSL QSPI driver nodes ARM: dts: imx6sx-sdb: Fix the reg properties for the FSL QSPI nodes ARM: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller arm64: dts: Remove unused properties from FSL QSPI driver nodes arm64: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller 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 | 5 ++--- arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 3 ++- arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 4 ++-- arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 6 ++++-- arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 4 ++++ 8 files changed, 28 insertions(+), 12 deletions(-)