Re: [PATCH v2 3/3] arm64: dts: freescale: add initial support for verdin imx8m plus

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Marcel,

On Fri, Mar 25, 2022 at 08:17:18AM +0000, Marcel Ziswiler wrote:
> On Fri, 2022-03-25 at 01:06 +0200, Laurent Pinchart wrote:
> > On Wed, Mar 23, 2022 at 03:36:00PM +0100, Marcel Ziswiler wrote:
> > > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > 
> > > This patch adds the device tree to support Toradex Verdin iMX8M Plus [1]
> > > a computer on module which can be used on different carrier boards.
> > > 
> > > The module consists of an NXP i.MX 8M Plus family SoC (either i.MX 8M
> > > Plus Quad or 8M Plus QuadLite), a PCA9450C PMIC, a Gigabit Ethernet PHY,
> > > 1, 2, 4 or 8 GB of LPDDR4 RAM, an eMMC, a TLA2024 ADC, an I2C EEPROM, an
> > > RX8130 RTC, an optional I2C temperature sensor plus an optional
> > > Bluetooth/Wi-Fi module.
> > > 
> > > Anything that is not self-contained on the module is disabled by
> > > default.
> > > 
> > > The device tree for the Dahlia includes the module's device tree and
> > > enables the supported peripherals of the carrier board.
> > > 
> > > The device tree for the Verdin Development Board includes the module's
> > > device tree as well as the Dahlia one as it is a superset and supports
> > > almost all peripherals available.
> > > 
> > > So far there is no display functionality supported at all but basic
> > > console UART, USB host, eMMC and Ethernet functionality work fine.
> > > 
> > > [1] https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-plus
> > > 
> > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > 
> > > ---
> > > 
> > > Changes in v2:
> > > - Fix capitatlisation of verdin in comments as reported by Laurent.
> > > - Add/modify todo comments as suggested by Laurent.
> > > - Add Laurent's reviewed- and tested-by tags.
> > > 
> > >  arch/arm64/boot/dts/freescale/Makefile        |    4 +
> > >  .../dts/freescale/imx8mp-verdin-dahlia.dtsi   |  129 ++
> > >  .../boot/dts/freescale/imx8mp-verdin-dev.dtsi |   44 +
> > >  .../imx8mp-verdin-nonwifi-dahlia.dts          |   18 +
> > >  .../freescale/imx8mp-verdin-nonwifi-dev.dts   |   18 +
> > >  .../dts/freescale/imx8mp-verdin-nonwifi.dtsi  |   54 +
> > >  .../freescale/imx8mp-verdin-wifi-dahlia.dts   |   18 +
> > >  .../dts/freescale/imx8mp-verdin-wifi-dev.dts  |   18 +
> > >  .../dts/freescale/imx8mp-verdin-wifi.dtsi     |   82 +
> > >  .../boot/dts/freescale/imx8mp-verdin.dtsi     | 1373 +++++++++++++++++
> > >  10 files changed, 1758 insertions(+)
> > >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi
> > >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-dev.dtsi
> > >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-dahlia.dts
> > >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-dev.dts
> > >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi.dtsi
> > >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-dahlia.dts
> > >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-dev.dts
> > >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi.dtsi
> > >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
> > 
> > [snip]
> > 
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-
> > > verdin.dtsi
> > > new file mode 100644
> > > index 000000000000..8cad1d865720
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
> > > @@ -0,0 +1,1373 @@
> > 
> > [snip]
> > 
> > > +/* Verdin I2C_2_DSI */
> > > +&i2c2 {
> > > +       clock-frequency = <10000>;
> > 
> > Did you really mean 10kHz here, not 100kHz ?
> 
> Yes, we really saw issues with certain displays/screens in the past. I mean, it's not like reading a few bytes
> off a DDC/EDID at such low-speed makes much of a difference time-wise. So we rather avoid issues. Anyway, could
> easily be overridden in a custom carrier board device tree should that I2C bus be used for something where
> speed might matter.

Adding a comment to explain this issue may be useful.

> > > +       pinctrl-names = "default", "gpio";
> > > +       pinctrl-0 = <&pinctrl_i2c2>;
> > > +       pinctrl-1 = <&pinctrl_i2c2_gpio>;
> > 
> > Shouldn't you also specify scl-gpios and sda-gpios, like for the other
> > I2C buses ?
> 
> Yes, working on the Verdin iMX8M Mini update patch set of late and comparing stuff I also just discovered that
> one yesterday. Will send a v3 shortly. Thanks!
> 
> > > +
> > > +       atmel_mxt_ts_mezzanine: touch-mezzanine@4a {
> > > +               compatible = "atmel,maxtouch";
> > > +               /* Verdin GPIO_3 (SODIMM 210) */
> > > +               interrupt-parent = <&gpio1>;
> > > +               interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
> > > +               reg = <0x4a>;
> > > +               /* Verdin GPIO_2 (SODIMM 208) */
> > > +               reset-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
> > > +               status = "disabled";
> > > +       };
> > > +};
> > 
> > [snip]

-- 
Regards,

Laurent Pinchart