[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c353fa3cc60e8854404eaedebcebee07b103d7c.camel@ew.tq-group.com>
Date: Mon, 07 Sep 2020 09:40:41 +0200
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Fabio Estevam <festevam@...il.com>
Cc: Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
NXP Linux Team <linux-imx@....com>,
linux-spi <linux-spi@...r.kernel.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Mark Brown <broonie@...nel.org>
Subject: Re: (EXT) Re: (EXT) Re: (EXT) Re: [PATCH] spi-imx: remove num-cs
support, set num_chipselect to 4
On Fri, 2020-09-04 at 12:42 -0300, Fabio Estevam wrote:
> Hi Mark,
>
> On Fri, Sep 4, 2020 at 12:05 PM Mark Brown <broonie@...nel.org>
> wrote:
> >
> > On Fri, Sep 04, 2020 at 04:34:43PM +0200, Matthias Schiffer wrote:
> >
> > > Nevertheless, I don't see why we should deliberately remove the
> > > native
> > > CS support - my understanding was that we try to avoid breaking
> > > changes
> > > to DT interpretation even for unknown/out-of-tree DTS.
> >
> > Yes, we should try to maintain compatibility for anyone that was
> > using
> > it.
>
> We are not breaking compatibility.
>
> Prior to 8cdcd8aeee281 ("spi: imx/fsl-lpspi: Convert to GPIO
> descriptors") num_chipselect was 1 for all device tree users.
> i.MX board files will be removed, so we don't need to worry about
> them.
>
> What will cause breakage is to say that the driver supports the
> native
> chip-select.
>
> I have just done a quick test on an imx6q-sabresd.
>
> With the original dts that uses cs-gpios the SPI NOR is correctly
> probed:
>
> [ 5.402627] spi-nor spi0.0: m25p32 (4096 Kbytes)
>
> However, using native chip select with this dts change:
>
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -189,7 +189,6 @@
> };
>
> &ecspi1 {
> - cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_ecspi1>;
> status = "okay";
> @@ -506,7 +505,7 @@
> MX6QDL_PAD_KEY_COL1__ECSPI1_MISO
> 0x100b1
> MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI
> 0x100b1
> MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK
> 0x100b1
> - MX6QDL_PAD_KEY_ROW1__GPIO4_IO09
> 0x1b0b0
> + MX6QDL_PAD_KEY_ROW1__ECSPI1_SS0
> 0x1b0b0
> >;
> };
>
> Causes SPI NOR probe to fail:
>
> [ 5.388704] spi-nor spi0.0: unrecognized JEDEC id bytes: 00 00 00
> 00 00 00
>
> That's why I prefer we do not advertise that we can use the native
> chip-select with this driver.
My rationale here is the following: As broken as the native CS of these
controllers is, it isn't an unreasonable assumption that it is working
fine with *some* devices or for some usecases - after all the support
was implemented at some point, and has existed for a long time now. If
we really want to remove this feature, a deprecation period with a
warning message seems like the proper way to deal with this.
Hypothetically, existing out-of-tree DTS could have used the native CS
with num-cs set to 4. Always setting num_chipselect to 4 ensures that
we don't break such DTS with the num-cs removal.
Kind regards,
Matthias
Powered by blists - more mailing lists