[GIT PULL] FSL QSPI device tree cleanup for 4.21

[GIT PULL] FSL QSPI device tree cleanup for 4.21

[Shawn Guo]

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(-)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Schrempf Frieder]

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

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Schrempf Frieder]

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

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Schrempf Frieder]

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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Schrempf Frieder]

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.

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Schrempf Frieder]

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.

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Schrempf Frieder]

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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Geert Uytterhoeven]

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

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Geert Uytterhoeven]

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

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Geert Uytterhoeven]

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

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

Re: [GIT PULL] FSL QSPI device tree cleanup for 4.21

[Arnd Bergmann]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel