mbox series

[v2,0/5] Add DT bindings and device tree for Compulab SB-UCM-iMX8MPLUS

Message ID 20240317164850.32708-1-laurent.pinchart@ideasonboard.com
Headers show
Series Add DT bindings and device tree for Compulab SB-UCM-iMX8MPLUS | expand

Message

Laurent Pinchart March 17, 2024, 4:48 p.m. UTC 
Hello,

This small patch series is a drive-by addition of the Compulab
SB-UCM-iMX8MPLUS to the Linux kernel device tree sources. While porting
the device tree from the Compulab BSP kernel to mainline, I thought I
could as well mainline it, along with related conversion of text DT
bindings to YAML.

The SB-UCM-iMX8MPLUS is a carrier board designed as a reference to
evaluate the Compulab UCM-iMX8MPLUS SoM. The SoM integrates the bare
minimal peripherals (DRAM, eMMC, ethernet PHY, EEPROM and RTC), while
the carrier board includes a much wider range of peripherals. I have
only enabled support for the ones I am interested in, or, as a strech
goal, the ones I could easily test.

The first patch in the series adds compatible strings for the SoM and
the board to the ARM FSL bindings. The next two patches then add DT
sources for the SoM and the carrier board.

I have split HDMI support out to patch 4/5, as it depends on patches
that have not hit linux-next yet (see [1]). Depending on which series
gets merged first, patch 4/5 can be left out for now.

Finally, patch 5/5 adds an overlay for the display panel shipped with
the Compulab evaluation kit.

The series is based on a branch that contains a backport of the HDMI
support series, as well miscellaneous patches I have submitted
separately to convert text DT bindings to YAML. You can find the series
applied on top of the base branch at [2]. With that base, the only DT
validation warnings are due to preexisting issues in imx8mp.dtsi.

[1] https://lore.kernel.org/all/20240227220444.77566-1-aford173@gmail.com/#t
[2] https://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux.git/log/?h=nxp/v6.8/compulab

Laurent Pinchart (5):
  dt-bindings: arm: fsl: Add Compulab SB-UCM-iMX8MPLUS carrier board
  arm64: dts: freescale: Add device tree for Compulab UCM-iMX8M-Plus
  arm64: dts: freescale: Add device tree for Compulab SB-UCM-iMX8MPLUS
  arm64: dts: freescale: imx8mp-sb-ucm: Add HDMI output support
  arm64: dts: freescale: imx8mp-sb-ucm: Add DSI panel overlay

 .../devicetree/bindings/arm/fsl.yaml          |   6 +
 arch/arm64/boot/dts/freescale/Makefile        |   5 +
 .../imx8mp-sb-ucm-panel-kd050hdfia020.dtso    |  81 +++++
 .../boot/dts/freescale/imx8mp-sb-ucm.dts      | 337 ++++++++++++++++++
 arch/arm64/boot/dts/freescale/imx8mp-ucm.dtsi | 309 ++++++++++++++++
 5 files changed, 738 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-sb-ucm.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-ucm.dtsi


base-commit: 64d8ca69f2f1e659c60ba509a2e91d2c8c0a3a4c

Comments

Laurent Pinchart March 17, 2024, 4:56 p.m. UTC | #1 
On Sun, Mar 17, 2024 at 06:48:50PM +0200, Laurent Pinchart wrote:
> The SB-UCM-iMX8MPLUS kit is shipped with an external DSI panel. Add a
> corresponding DT overlay.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>  arch/arm64/boot/dts/freescale/Makefile        |  4 +
>  .../imx8mp-sb-ucm-panel-kd050hdfia020.dtso    | 81 +++++++++++++++++++
>  2 files changed, 85 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtso
> 
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 02efa97fc464..d7432ce6a7bb 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -165,6 +165,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-icore-mx8mp-edimm2.2.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-msc-sm2s-ep1.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-sb-ucm.dtb
> +
> +imx8mp-sb-ucm-panel-kd050hdfia020-dtbs := imx8mp-sb-ucm.dtb imx8mp-sb-ucm-panel-kd050hdfia020-dtbo
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-sb-ucm-panel-kd050hdfia020-dtb

On a side note, is there a way to selectively compile this dtb ? Running

$ make dtbs

will compile them all, but

$ make freescale/imx8mp-sb-ucm-panel-kd050hdfia020-dtb

complains with

make[4]: *** No rule to make target 'arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtb'.  Stop.
make[3]: *** [/home/laurent/src/iob/toradex/linux/scripts/Makefile.build:481: arch/arm64/boot/dts/freescale] Error 2
make[2]: *** [/home/laurent/src/iob/toradex/linux/Makefile:1389: freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtb] Error 2

I would like to compile it selectively, as running

$ make dtbs CHECK_DTBS=1

makes it much more time consuming to run the dtb checks.

> +
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-mi1010ait-1cp1.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtso b/arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtso
> new file mode 100644
> index 000000000000..fdad943c1554
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtso
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2021 CompuLab
> + *
> + * Device tree overlay for KD050HDFIA020-C020A panel connector to Compulab
> + * SB-UCM-iMX8PLUS.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +&dsi_backlight {
> +	status = "okay";
> +};
> +
> +&i2c5 {
> +	status = "okay";
> +
> +	touch@5d {
> +		compatible = "goodix,gt911";
> +		reg = <0x5d>;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_dsi_touch>;
> +
> +		interrupt-parent = <&gpio4>;
> +		interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
> +
> +                irq-gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>;
> +		reset-gpios = <&pca9555 5 GPIO_ACTIVE_HIGH>;
> +        };
> +};
> +
> +&lcdif1 {
> +	status = "okay";
> +};
> +
> +&mipi_dsi {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	samsung,esc-clock-frequency = <20000000>;
> +	status = "okay";
> +
> +	panel@0 {
> +		compatible = "startek,kd050hdfia020", "ilitek,ili9881c";
> +		reg = <0>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_dsi_panel>;
> +
> +		reset-gpio = <&pca9555 4 GPIO_ACTIVE_LOW>;
> +		power-supply = <&reg_3v3_per>;
> +
> +		backlight = <&dsi_backlight>;
> +
> +		port {
> +			panel_in: endpoint {
> +				remote-endpoint = <&mipi_dsi_out>;
> +				data-lanes = <1 2 3 4>;
> +			};
> +		};
> +	};
> +
> +	ports {
> +		port@1 {
> +			reg = <1>;
> +
> +			mipi_dsi_out: endpoint {
> +				remote-endpoint = <&panel_in>;
> +				data-lanes = <1 2 3 4>;
> +				lane-polarities = <0 0 0 0 0>;
> +			};
> +		};
> +	};
> +};
> +
> +&pwm1 {
> +	status = "okay";
> +};
Andrew Lunn March 17, 2024, 5:17 p.m. UTC | #2 
> +&eqos {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_eqos>;
> +	phy-mode = "rgmii-id";
> +	phy-handle = <&ethphy0>;
> +
> +	mdio {
> +		compatible = "snps,dwmac-mdio";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		/* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */
> +		ethphy0: ethernet-phy@0 {
> +			compatible = "ethernet-phy-ieee802.3-c22";
> +			reg = <0>;
> +			eee-broken-1000t;
> +		};

Hi Laurent

Do you happen to know what is broken with respect to EEE? It seems
like a lot of IMX boards have this, so i suspect it is the MAC. Maybe
we should be keying off the MAC compatible and disabling this in the
ethernet driver rather than have every .dts file needing it?
Laurent Pinchart March 17, 2024, 6:57 p.m. UTC | #3 
On Sun, Mar 17, 2024 at 06:17:17PM +0100, Andrew Lunn wrote:
> > +&eqos {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_eqos>;
> > +	phy-mode = "rgmii-id";
> > +	phy-handle = <&ethphy0>;
> > +
> > +	mdio {
> > +		compatible = "snps,dwmac-mdio";
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		/* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */
> > +		ethphy0: ethernet-phy@0 {
> > +			compatible = "ethernet-phy-ieee802.3-c22";
> > +			reg = <0>;
> > +			eee-broken-1000t;
> > +		};
> 
> Hi Laurent
> 
> Do you happen to know what is broken with respect to EEE? It seems
> like a lot of IMX boards have this, so i suspect it is the MAC. Maybe
> we should be keying off the MAC compatible and disabling this in the
> ethernet driver rather than have every .dts file needing it?

I wonder if this could be cargo-cult. To be honest, I've copied it from
the BSP and haven't investigated it. I've tried dropping that and
haven't noticed any difference, but I'm not sure how I should test it
properly.
Andrew Lunn March 17, 2024, 9:55 p.m. UTC | #4 
On Sun, Mar 17, 2024 at 08:57:22PM +0200, Laurent Pinchart wrote:
> On Sun, Mar 17, 2024 at 06:17:17PM +0100, Andrew Lunn wrote:
> > > +&eqos {
> > > +	pinctrl-names = "default";
> > > +	pinctrl-0 = <&pinctrl_eqos>;
> > > +	phy-mode = "rgmii-id";
> > > +	phy-handle = <&ethphy0>;
> > > +
> > > +	mdio {
> > > +		compatible = "snps,dwmac-mdio";
> > > +		#address-cells = <1>;
> > > +		#size-cells = <0>;
> > > +
> > > +		/* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */
> > > +		ethphy0: ethernet-phy@0 {
> > > +			compatible = "ethernet-phy-ieee802.3-c22";
> > > +			reg = <0>;
> > > +			eee-broken-1000t;
> > > +		};
> > 
> > Hi Laurent
> > 
> > Do you happen to know what is broken with respect to EEE? It seems
> > like a lot of IMX boards have this, so i suspect it is the MAC. Maybe
> > we should be keying off the MAC compatible and disabling this in the
> > ethernet driver rather than have every .dts file needing it?
> 
> I wonder if this could be cargo-cult. To be honest, I've copied it from
> the BSP and haven't investigated it. I've tried dropping that and
> haven't noticed any difference, but I'm not sure how I should test it
> properly.

Maybe a better approach is to find the errata. It could be some older
version of the eqos was broken, and it got fixed along the way? If
that is so, moving it into the driver would be better, assuming there
is some sort of hardware version register in the eqos.

	Andrew
Laurent Pinchart March 17, 2024, 11:50 p.m. UTC | #5 
(CC'ing Johannes)

On Sun, Mar 17, 2024 at 10:55:16PM +0100, Andrew Lunn wrote:
> On Sun, Mar 17, 2024 at 08:57:22PM +0200, Laurent Pinchart wrote:
> > On Sun, Mar 17, 2024 at 06:17:17PM +0100, Andrew Lunn wrote:
> > > > +&eqos {
> > > > +	pinctrl-names = "default";
> > > > +	pinctrl-0 = <&pinctrl_eqos>;
> > > > +	phy-mode = "rgmii-id";
> > > > +	phy-handle = <&ethphy0>;
> > > > +
> > > > +	mdio {
> > > > +		compatible = "snps,dwmac-mdio";
> > > > +		#address-cells = <1>;
> > > > +		#size-cells = <0>;
> > > > +
> > > > +		/* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */
> > > > +		ethphy0: ethernet-phy@0 {
> > > > +			compatible = "ethernet-phy-ieee802.3-c22";
> > > > +			reg = <0>;
> > > > +			eee-broken-1000t;
> > > > +		};
> > > 
> > > Hi Laurent
> > > 
> > > Do you happen to know what is broken with respect to EEE? It seems
> > > like a lot of IMX boards have this, so i suspect it is the MAC. Maybe
> > > we should be keying off the MAC compatible and disabling this in the
> > > ethernet driver rather than have every .dts file needing it?
> > 
> > I wonder if this could be cargo-cult. To be honest, I've copied it from
> > the BSP and haven't investigated it. I've tried dropping that and
> > haven't noticed any difference, but I'm not sure how I should test it
> > properly.
> 
> Maybe a better approach is to find the errata. It could be some older
> version of the eqos was broken, and it got fixed along the way? If
> that is so, moving it into the driver would be better, assuming there
> is some sort of hardware version register in the eqos.

I don't know if there are public errata about this issue. It is beyong
my areas of expertise. I've found a relatively recent e-mail on the
netdev mailing list that seems related ([1]), but there was no reply.

[1] https://lore.kernel.org/netdev/9c1c9408-88ac-4ade-b8ec-2ae5d8922cac@pengutronix.de/
Laurent Pinchart March 18, 2024, 12:05 a.m. UTC | #6 
On Sun, Mar 17, 2024 at 06:56:47PM +0200, Laurent Pinchart wrote:
> On Sun, Mar 17, 2024 at 06:48:50PM +0200, Laurent Pinchart wrote:
> > The SB-UCM-iMX8MPLUS kit is shipped with an external DSI panel. Add a
> > corresponding DT overlay.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> >  arch/arm64/boot/dts/freescale/Makefile        |  4 +
> >  .../imx8mp-sb-ucm-panel-kd050hdfia020.dtso    | 81 +++++++++++++++++++
> >  2 files changed, 85 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtso
> > 
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> > index 02efa97fc464..d7432ce6a7bb 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -165,6 +165,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-icore-mx8mp-edimm2.2.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mp-msc-sm2s-ep1.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mp-sb-ucm.dtb
> > +
> > +imx8mp-sb-ucm-panel-kd050hdfia020-dtbs := imx8mp-sb-ucm.dtb imx8mp-sb-ucm-panel-kd050hdfia020-dtbo
> > +dtb-$(CONFIG_ARCH_MXC) += imx8mp-sb-ucm-panel-kd050hdfia020-dtb

Replying to myself, fixing the typo here with s/-dtb$/.dtb/ helps :-)
I'll send a v3 after waiting some time for review comments.

> On a side note, is there a way to selectively compile this dtb ? Running
> 
> $ make dtbs
> 
> will compile them all, but
> 
> $ make freescale/imx8mp-sb-ucm-panel-kd050hdfia020-dtb
> 
> complains with
> 
> make[4]: *** No rule to make target 'arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtb'.  Stop.
> make[3]: *** [/home/laurent/src/iob/toradex/linux/scripts/Makefile.build:481: arch/arm64/boot/dts/freescale] Error 2
> make[2]: *** [/home/laurent/src/iob/toradex/linux/Makefile:1389: freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtb] Error 2
> 
> I would like to compile it selectively, as running
> 
> $ make dtbs CHECK_DTBS=1
> 
> makes it much more time consuming to run the dtb checks.
> 
> > +
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-mi1010ait-1cp1.dtb
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtso b/arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtso
> > new file mode 100644
> > index 000000000000..fdad943c1554
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-sb-ucm-panel-kd050hdfia020.dtso
> > @@ -0,0 +1,81 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2021 CompuLab
> > + *
> > + * Device tree overlay for KD050HDFIA020-C020A panel connector to Compulab
> > + * SB-UCM-iMX8PLUS.
> > + */
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +
> > +&dsi_backlight {
> > +	status = "okay";
> > +};
> > +
> > +&i2c5 {
> > +	status = "okay";
> > +
> > +	touch@5d {
> > +		compatible = "goodix,gt911";
> > +		reg = <0x5d>;
> > +
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_dsi_touch>;
> > +
> > +		interrupt-parent = <&gpio4>;
> > +		interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > +                irq-gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>;
> > +		reset-gpios = <&pca9555 5 GPIO_ACTIVE_HIGH>;
> > +        };
> > +};
> > +
> > +&lcdif1 {
> > +	status = "okay";
> > +};
> > +
> > +&mipi_dsi {
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +	samsung,esc-clock-frequency = <20000000>;
> > +	status = "okay";
> > +
> > +	panel@0 {
> > +		compatible = "startek,kd050hdfia020", "ilitek,ili9881c";
> > +		reg = <0>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_dsi_panel>;
> > +
> > +		reset-gpio = <&pca9555 4 GPIO_ACTIVE_LOW>;
> > +		power-supply = <&reg_3v3_per>;
> > +
> > +		backlight = <&dsi_backlight>;
> > +
> > +		port {
> > +			panel_in: endpoint {
> > +				remote-endpoint = <&mipi_dsi_out>;
> > +				data-lanes = <1 2 3 4>;
> > +			};
> > +		};
> > +	};
> > +
> > +	ports {
> > +		port@1 {
> > +			reg = <1>;
> > +
> > +			mipi_dsi_out: endpoint {
> > +				remote-endpoint = <&panel_in>;
> > +				data-lanes = <1 2 3 4>;
> > +				lane-polarities = <0 0 0 0 0>;
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +&pwm1 {
> > +	status = "okay";
> > +};
Andrew Lunn March 18, 2024, 12:58 p.m. UTC | #7 
> I don't know if there are public errata about this issue. It is beyong
> my areas of expertise. I've found a relatively recent e-mail on the
> netdev mailing list that seems related ([1]), but there was no reply.
> 
> [1] https://lore.kernel.org/netdev/9c1c9408-88ac-4ade-b8ec-2ae5d8922cac@pengutronix.de/

Thanks for the link.

Has anybody tried setting STMMAC_FLAG_RX_CLK_RUNS_IN_LPI.

https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c#L816

The problem description makes it sound like the hardware does not like
the clock being turned off. Setting this flag might fix that.

	Andrew