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

[Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>]

Hi Arnd,

On Thu, Dec 20, 2018 at 5:33 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Thu, Dec 20, 2018 at 5:23 PM Schrempf Frieder
> <frieder.schrempf@xxxxxxxxxx> wrote:
> > On 20.12.18 17:11, Arnd Bergmann wrote:
> > > On Thu, Dec 20, 2018 at 5:03 PM Schrempf Frieder
> > > <frieder.schrempf@xxxxxxxxxx> wrote:
> > >>
> > >> On 20.12.18 16:50, Arnd Bergmann wrote:
> > >>> On Sun, Dec 16, 2018 at 9:50 AM Shawn Guo <shawnguo@xxxxxxxxxx> 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@xxxxxxxxxxxxxx

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