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