mbox series

[GIT,PULL] FSL QSPI device tree cleanup for 4.21

Message ID 20181216084854.GJ13243@dragon
State New
Headers show
Series [GIT,PULL] FSL QSPI device tree cleanup for 4.21 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-qspi-dt-clean

Message

Shawn Guo Dec. 16, 2018, 8:48 a.m. UTC
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(-)

Comments

Arnd Bergmann Dec. 20, 2018, 3:50 p.m. UTC | #1
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
Frieder Schrempf Dec. 20, 2018, 4:03 p.m. UTC | #2
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
Arnd Bergmann Dec. 20, 2018, 4:11 p.m. UTC | #3
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
Frieder Schrempf Dec. 20, 2018, 4:23 p.m. UTC | #4
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.
Arnd Bergmann Dec. 20, 2018, 4:32 p.m. UTC | #5
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
Geert Uytterhoeven Dec. 20, 2018, 6:23 p.m. UTC | #6
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
Arnd Bergmann Dec. 20, 2018, 10:41 p.m. UTC | #7
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