Re: [PATCH v2 1/2] ARM: dts: imx7-tqma7: add SPI-NOR flash

[Matthias Schiffer]

On Mon, 2020-11-02 at 09:24 +0100, Marco Felsch wrote:
> Hi Matthias,
> 
> On 20-10-30 11:26, Matthias Schiffer wrote:
> > The SPI-NOR flash on the SoM was missing from the device tree.
> > 
> > Signed-off-by: Matthias Schiffer <matthias.schiffer@xxxxxxxxxxxxxxx>
> > ---
> >  arch/arm/boot/dts/imx7-tqma7.dtsi | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> > 
> > v2: change node name to flash@0

Sorry for the very late reply, I intend to address the review comments
soon.


> > 
> > 
> > diff --git a/arch/arm/boot/dts/imx7-tqma7.dtsi b/arch/arm/boot/dts/imx7-tqma7.dtsi
> > index 8773344b54aa..22f4194322ed 100644
> > --- a/arch/arm/boot/dts/imx7-tqma7.dtsi
> > +++ b/arch/arm/boot/dts/imx7-tqma7.dtsi
> > @@ -160,6 +160,20 @@
> >  		>;
> >  	};
> >  
> > +	pinctrl_qspi: qspigrp {
> > +		fsl,pins = <
> > +			MX7D_PAD_EPDC_DATA00__QSPI_A_DATA0	0x5A
> > +			MX7D_PAD_EPDC_DATA01__QSPI_A_DATA1	0x5A
> > +			MX7D_PAD_EPDC_DATA02__QSPI_A_DATA2	0x5A
> > +			MX7D_PAD_EPDC_DATA03__QSPI_A_DATA3	0x5A
> > +			MX7D_PAD_EPDC_DATA05__QSPI_A_SCLK	0x11
> > +			MX7D_PAD_EPDC_DATA06__QSPI_A_SS0_B	0x54
> > +			MX7D_PAD_EPDC_DATA07__QSPI_A_SS1_B	0x54
> 
> As far as I know we are using GPIO based chip selects and not the one
> from the controller-IP or is this different for qspi?

Native chip selects are used for QSPI. I don't think GPIO CS make sense
for this kind of QSPI controller that provides memory-mapped access to
SPI flash.


> 
> > +			/* #QSPI_RESET */
> > +			MX7D_PAD_EPDC_DATA04__GPIO2_IO4		0x40000052
> 
> Do you really need to mux the reset-gpio?

The muxing configures a pullup on the reset pin to ensure that a
connected flash chip is not held in reset. However, the signal is
marked as optional in the schematics, and on all SoMs I have here the
flash reset is wired to the board reset instead of this SoC GPIO.

Still, configuring the pullup seems like a good idea to me, in case
hardware variants with the optional signal actually exist - there
shouldn't be any downsides, as the pin is either unconnected or wired
to the flash reset.

I guess I could additionally add an input hog to ensure that the pin
cannot be changed?

The SION bit in the pad configuration seems to be a mistake, I'll
remove it.


> 
> > +		>;
> > +	};
> > +
> >  	pinctrl_usdhc3: usdhc3grp {
> >  		fsl,pins = <
> >  			MX7D_PAD_SD3_CMD__SD3_CMD		0x59
> > @@ -217,6 +231,22 @@
> >  	};
> >  };
> >  
> > +&qspi {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_qspi>;
> > +	status = "okay";
> > +
> > +	flash0: flash@0 {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		compatible = "jedec,spi-nor";
> > +		spi-max-frequency = <29000000>;
> > +		spi-rx-bus-width = <4>;
> > +		spi-tx-bus-width = <4>;
> > +		reg = <0>;
> 
> Please check Documentation/devicetree/bindings/mtd/partition.txt to see
> how partitions are added nowadays. With this in mind you should reorder
> the node to:
> 
> 	compatible = "jedec,spi-nor";
> 	reg = <0>;
> 	spi-max-frequency = <29000000>;
> 	spi-rx-bus-width = <4>;
> 	spi-tx-bus-width = <4>;
> 
> 
> Regards,
>   Marco
> 
> > +	};
> > +};
> > +
> >  &sdma {
> >  	status = "okay";
> >  };
> > -- 
> > 2.17.1
> > 
> > 
> >