[PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Marek Vasut]

Add TC9595 DSI-to-DPI and DSI-to-(e)DP bridge to
DH electronics i.MX8M Plus DHCOM SoM . The bridge
is populated on the SoM, but disabled by default
unless used for display output.

Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 .../boot/dts/freescale/imx8mp-dhcom-som.dtsi  | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
index 98a11c31d7d45..9c0cb75386e36 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
@@ -240,6 +240,36 @@ &i2c3 {
 	sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
 	status = "okay";
 
+	tc_bridge: bridge@f {
+		compatible = "toshiba,tc9595", "toshiba,tc358767";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_tc9595>;
+		reg = <0xf>;
+		clock-names = "ref";
+		clocks = <&clk IMX8MP_CLK_CLKOUT2>;
+		assigned-clocks = <&clk IMX8MP_CLK_CLKOUT2_SEL>,
+				  <&clk IMX8MP_CLK_CLKOUT2>,
+				  <&clk IMX8MP_AUDIO_PLL2_OUT>;
+		assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL2_OUT>;
+		assigned-clock-rates = <13000000>, <13000000>, <156000000>;
+		reset-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				tc_bridge_in: endpoint {
+					data-lanes = <1 2 3 4>;
+					remote-endpoint = <&dsi_out>;
+				};
+			};
+		};
+	};
+
 	pmic: pmic@25 {
 		compatible = "nxp,pca9450c";
 		reg = <0x25>;
@@ -406,6 +436,22 @@ &i2c5 {	/* HDMI EDID bus */
 	status = "okay";
 };
 
+&mipi_dsi {
+	samsung,burst-clock-frequency = <160000000>;
+	samsung,esc-clock-frequency = <10000000>;
+
+	ports {
+		port@1 {
+			reg = <1>;
+
+			dsi_out: endpoint {
+				data-lanes = <1 2 3 4>;
+				remote-endpoint = <&tc_bridge_in>;
+			};
+		};
+	};
+};
+
 &pwm1 {
 	pinctrl-0 = <&pinctrl_pwm1>;
 	pinctrl-names = "default";
@@ -880,6 +926,15 @@ MX8MP_IOMUXC_SAI3_TXD__AUDIOMIX_SAI3_TX_DATA00	0xd6
 		>;
 	};
 
+	pinctrl_tc9595: dhcom-tc9595-grp {
+		fsl,pins = <
+			/* RESET_DSIBRIDGE */
+			MX8MP_IOMUXC_SAI1_RXC__GPIO4_IO01		0x40000146
+			/* DSI-CONV_INT Interrupt */
+			MX8MP_IOMUXC_SAI5_RXD0__GPIO3_IO21		0x141
+		>;
+	};
+
 	pinctrl_touch: dhcom-touch-grp {
 		fsl,pins = <
 			/* #TOUCH_INT */
-- 
2.39.2

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Alexander Stein]

Hello Marek,

Am Montag, 15. Mai 2023, 18:24:24 CEST schrieb Marek Vasut:
> Add TC9595 DSI-to-DPI and DSI-to-(e)DP bridge to
> DH electronics i.MX8M Plus DHCOM SoM . The bridge
> is populated on the SoM, but disabled by default
> unless used for display output.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>

Were you actually able to access the display? E.g. reading DPCD via AUX 
channel?

Best regards,
Alexander

> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
>  .../boot/dts/freescale/imx8mp-dhcom-som.dtsi  | 55 +++++++++++++++++++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi index
> 98a11c31d7d45..9c0cb75386e36 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
> @@ -240,6 +240,36 @@ &i2c3 {
>  	sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
>  	status = "okay";
> 
> +	tc_bridge: bridge@f {
> +		compatible = "toshiba,tc9595", "toshiba,tc358767";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_tc9595>;
> +		reg = <0xf>;
> +		clock-names = "ref";
> +		clocks = <&clk IMX8MP_CLK_CLKOUT2>;
> +		assigned-clocks = <&clk IMX8MP_CLK_CLKOUT2_SEL>,
> +				  <&clk IMX8MP_CLK_CLKOUT2>,
> +				  <&clk IMX8MP_AUDIO_PLL2_OUT>;
> +		assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL2_OUT>;
> +		assigned-clock-rates = <13000000>, <13000000>, 
<156000000>;
> +		reset-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +		status = "disabled";
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port@0 {
> +				reg = <0>;
> +
> +				tc_bridge_in: endpoint {
> +					data-lanes = <1 2 3 4>;
> +					remote-endpoint = 
<&dsi_out>;
> +				};
> +			};
> +		};
> +	};
> +
>  	pmic: pmic@25 {
>  		compatible = "nxp,pca9450c";
>  		reg = <0x25>;
> @@ -406,6 +436,22 @@ &i2c5 {	/* HDMI EDID bus */
>  	status = "okay";
>  };
> 
> +&mipi_dsi {
> +	samsung,burst-clock-frequency = <160000000>;
> +	samsung,esc-clock-frequency = <10000000>;
> +
> +	ports {
> +		port@1 {
> +			reg = <1>;
> +
> +			dsi_out: endpoint {
> +				data-lanes = <1 2 3 4>;
> +				remote-endpoint = <&tc_bridge_in>;
> +			};
> +		};
> +	};
> +};
> +
>  &pwm1 {
>  	pinctrl-0 = <&pinctrl_pwm1>;
>  	pinctrl-names = "default";
> @@ -880,6 +926,15 @@ MX8MP_IOMUXC_SAI3_TXD__AUDIOMIX_SAI3_TX_DATA00	0xd6
> 
>  		>;
> 
>  	};
> 
> +	pinctrl_tc9595: dhcom-tc9595-grp {
> +		fsl,pins = <
> +			/* RESET_DSIBRIDGE */
> +			MX8MP_IOMUXC_SAI1_RXC__GPIO4_IO01		
0x40000146
> +			/* DSI-CONV_INT Interrupt */
> +			MX8MP_IOMUXC_SAI5_RXD0__GPIO3_IO21		
0x141
> +		>;
> +	};
> +
>  	pinctrl_touch: dhcom-touch-grp {
>  		fsl,pins = <
>  			/* #TOUCH_INT */


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Marek Vasut]

On 5/23/23 13:17, Alexander Stein wrote:
> Hello Marek,

Hi,

> Am Montag, 15. Mai 2023, 18:24:24 CEST schrieb Marek Vasut:
>> Add TC9595 DSI-to-DPI and DSI-to-(e)DP bridge to
>> DH electronics i.MX8M Plus DHCOM SoM . The bridge
>> is populated on the SoM, but disabled by default
>> unless used for display output.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
> 
> Were you actually able to access the display? E.g. reading DPCD via AUX
> channel?

I only tried the full display port (the one with large plug) on the TC 
evaluation kit, there I could use the aux channel. Are you testing this 
bridge and running into issues ? Details please ?

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Alexander Stein]

Hi Marek,

Am Dienstag, 23. Mai 2023, 15:10:05 CEST schrieb Marek Vasut:
> On 5/23/23 13:17, Alexander Stein wrote:
> > Hello Marek,
> 
> Hi,
> 
> > Am Montag, 15. Mai 2023, 18:24:24 CEST schrieb Marek Vasut:
> >> Add TC9595 DSI-to-DPI and DSI-to-(e)DP bridge to
> >> DH electronics i.MX8M Plus DHCOM SoM . The bridge
> >> is populated on the SoM, but disabled by default
> >> unless used for display output.
> >> 
> >> Signed-off-by: Marek Vasut <marex@denx.de>
> > 
> > Were you actually able to access the display? E.g. reading DPCD via AUX
> > channel?
> 
> I only tried the full display port (the one with large plug) on the TC
> evaluation kit, there I could use the aux channel. Are you testing this
> bridge and running into issues ? Details please ?

Which SoC is this evaluation kit based on?
Yes, I'm trying to test this bridge on imx8mp based board. 

AFAICS I run into a timeout during drm connector .get_modes call, see kernel 
log below.

> samsung-dsim 32e60000.dsi: [drm:samsung_dsim_host_attach [samsung_dsim]] 
Attached tc358767 device
> tc358767 1-000f: failed to read DPCD: -110
> tc358767 1-000f: failed to read display props: -110

Looking at the AUX_CH+/- signals, I can see the native aux request and the 
(presumable) correct answer (DP_DPCD_REV register) from the display. But for 
some reason the bridge runs into a aux timeout.
I can see in the DP0_AUXSTATUS register the bus gets busy (0x1) after starting 
transfer. But after the tc_aux_wait_busy() call DP0_AUXSTATUS his indicating a 
timeout and sync error (0x310002).
When changing the "Aux Bit Period Calculator Threshold" to 5 (register 
AUXCFG1), the sync error is gone, but the timeout still happens.

The frequency used from the display is ~1MHz, which should be okay. So on the 
electrical side all seems okay, but the native aux transfer don't work.

Any ideas?

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Marek Vasut]

On 5/24/23 08:49, Alexander Stein wrote:
> Hi Marek,

Hi,

> Am Dienstag, 23. Mai 2023, 15:10:05 CEST schrieb Marek Vasut:
>> On 5/23/23 13:17, Alexander Stein wrote:
>>> Hello Marek,
>>
>> Hi,
>>
>>> Am Montag, 15. Mai 2023, 18:24:24 CEST schrieb Marek Vasut:
>>>> Add TC9595 DSI-to-DPI and DSI-to-(e)DP bridge to
>>>> DH electronics i.MX8M Plus DHCOM SoM . The bridge
>>>> is populated on the SoM, but disabled by default
>>>> unless used for display output.
>>>>
>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>
>>> Were you actually able to access the display? E.g. reading DPCD via AUX
>>> channel?
>>
>> I only tried the full display port (the one with large plug) on the TC
>> evaluation kit, there I could use the aux channel. Are you testing this
>> bridge and running into issues ? Details please ?
> 
> Which SoC is this evaluation kit based on?

There is no SoC attached to it, it's just a breakout board for the 
bridge chip. You can attach it via DSI to whichever SoC you want. So far 
I tried STM32MP15xx and i.MX8MP.

> Yes, I'm trying to test this bridge on imx8mp based board.
> 
> AFAICS I run into a timeout during drm connector .get_modes call, see kernel
> log below.
> 
>> samsung-dsim 32e60000.dsi: [drm:samsung_dsim_host_attach [samsung_dsim]]
> Attached tc358767 device
>> tc358767 1-000f: failed to read DPCD: -110
>> tc358767 1-000f: failed to read display props: -110

How are you supplying clock to the TC358767 (or newer) ?
Do you supply clock from DSI or from Xtal ?
If DSI and if possible, switch to Xtal and see whether that helps.
Also check the Xtal frequency and make sure you define that correctly in DT.

> Looking at the AUX_CH+/- signals, I can see the native aux request and the
> (presumable) correct answer (DP_DPCD_REV register) from the display. But for
> some reason the bridge runs into a aux timeout.
> I can see in the DP0_AUXSTATUS register the bus gets busy (0x1) after starting
> transfer. But after the tc_aux_wait_busy() call DP0_AUXSTATUS his indicating a
> timeout and sync error (0x310002).
> When changing the "Aux Bit Period Calculator Threshold" to 5 (register
> AUXCFG1), the sync error is gone, but the timeout still happens.
> 
> The frequency used from the display is ~1MHz, which should be okay. So on the
> electrical side all seems okay, but the native aux transfer don't work.

I recall DPCD read timeouts, but those were usually triggered by either 
bad clock or wiring problems (the devkit wiring I used was horrible at 
the beginning) from what I can recall.

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Alexander Stein]

Hi Marek,

Am Mittwoch, 24. Mai 2023, 11:28:32 CEST schrieb Marek Vasut:
> On 5/24/23 08:49, Alexander Stein wrote:
> > Hi Marek,
> 
> Hi,
> 
> > Am Dienstag, 23. Mai 2023, 15:10:05 CEST schrieb Marek Vasut:
> >> On 5/23/23 13:17, Alexander Stein wrote:
> >>> Hello Marek,
> >> 
> >> Hi,
> >> 
> >>> Am Montag, 15. Mai 2023, 18:24:24 CEST schrieb Marek Vasut:
> >>>> Add TC9595 DSI-to-DPI and DSI-to-(e)DP bridge to
> >>>> DH electronics i.MX8M Plus DHCOM SoM . The bridge
> >>>> is populated on the SoM, but disabled by default
> >>>> unless used for display output.
> >>>> 
> >>>> Signed-off-by: Marek Vasut <marex@denx.de>
> >>> 
> >>> Were you actually able to access the display? E.g. reading DPCD via AUX
> >>> channel?
> >> 
> >> I only tried the full display port (the one with large plug) on the TC
> >> evaluation kit, there I could use the aux channel. Are you testing this
> >> bridge and running into issues ? Details please ?
> > 
> > Which SoC is this evaluation kit based on?
> 
> There is no SoC attached to it, it's just a breakout board for the
> bridge chip. You can attach it via DSI to whichever SoC you want. So far
> I tried STM32MP15xx and i.MX8MP.

I assume you were able to successfully use the bridge on both boards, no?

> > Yes, I'm trying to test this bridge on imx8mp based board.
> > 
> > AFAICS I run into a timeout during drm connector .get_modes call, see
> > kernel log below.
> > 
> >> samsung-dsim 32e60000.dsi: [drm:samsung_dsim_host_attach [samsung_dsim]]
> > 
> > Attached tc358767 device
> > 
> >> tc358767 1-000f: failed to read DPCD: -110
> >> tc358767 1-000f: failed to read display props: -110
> 
> How are you supplying clock to the TC358767 (or newer) ?
> Do you supply clock from DSI or from Xtal ?
> If DSI and if possible, switch to Xtal and see whether that helps.
> Also check the Xtal frequency and make sure you define that correctly in DT.

It's already connected to an Xtal, according to schematic it's 26MHz. This is 
also what I configured in DT. So far I think this looks correct.

> > Looking at the AUX_CH+/- signals, I can see the native aux request and the
> > (presumable) correct answer (DP_DPCD_REV register) from the display. But
> > for some reason the bridge runs into a aux timeout.
> > I can see in the DP0_AUXSTATUS register the bus gets busy (0x1) after
> > starting transfer. But after the tc_aux_wait_busy() call DP0_AUXSTATUS
> > his indicating a timeout and sync error (0x310002).
> > When changing the "Aux Bit Period Calculator Threshold" to 5 (register
> > AUXCFG1), the sync error is gone, but the timeout still happens.
> > 
> > The frequency used from the display is ~1MHz, which should be okay. So on
> > the electrical side all seems okay, but the native aux transfer don't
> > work.
> I recall DPCD read timeouts, but those were usually triggered by either
> bad clock or wiring problems (the devkit wiring I used was horrible at
> the beginning) from what I can recall.

bad clock in the sense of badly configured or bad xtal hardware? As the bridge 
and the xtal is on the same mainboard, for now, I ignore wirings.

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Marek Vasut]

On 5/24/23 12:24, Alexander Stein wrote:

Hi,

>>> Looking at the AUX_CH+/- signals, I can see the native aux request and the
>>> (presumable) correct answer (DP_DPCD_REV register) from the display. But
>>> for some reason the bridge runs into a aux timeout.
>>> I can see in the DP0_AUXSTATUS register the bus gets busy (0x1) after
>>> starting transfer. But after the tc_aux_wait_busy() call DP0_AUXSTATUS
>>> his indicating a timeout and sync error (0x310002).
>>> When changing the "Aux Bit Period Calculator Threshold" to 5 (register
>>> AUXCFG1), the sync error is gone, but the timeout still happens.
>>>
>>> The frequency used from the display is ~1MHz, which should be okay. So on
>>> the electrical side all seems okay, but the native aux transfer don't
>>> work.
>> I recall DPCD read timeouts, but those were usually triggered by either
>> bad clock or wiring problems (the devkit wiring I used was horrible at
>> the beginning) from what I can recall.
> 
> bad clock in the sense of badly configured or bad xtal hardware?

As in, the xtal clock drives the internal PLLs and if those are 
misconfigured for whatever reason, the chip can misbehave. You might 
want to double-check the clock routing chapter in the toshiba bridge 
datasheet and matching registers.

Have you tried forcing the chip into 1.62G (instead of 2.7G) operation 
and into 1-lane DP instead of 2-lane DP mode ? Does that make any 
difference ?

> As the bridge
> and the xtal is on the same mainboard, for now, I ignore wirings.

OK

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Alexander Stein]

Hi Marek,

Am Mittwoch, 24. Mai 2023, 12:37:50 CEST schrieb Marek Vasut:
> On 5/24/23 12:24, Alexander Stein wrote:
> 
> Hi,
> 
> >>> Looking at the AUX_CH+/- signals, I can see the native aux request and
> >>> the
> >>> (presumable) correct answer (DP_DPCD_REV register) from the display. But
> >>> for some reason the bridge runs into a aux timeout.
> >>> I can see in the DP0_AUXSTATUS register the bus gets busy (0x1) after
> >>> starting transfer. But after the tc_aux_wait_busy() call DP0_AUXSTATUS
> >>> his indicating a timeout and sync error (0x310002).
> >>> When changing the "Aux Bit Period Calculator Threshold" to 5 (register
> >>> AUXCFG1), the sync error is gone, but the timeout still happens.
> >>> 
> >>> The frequency used from the display is ~1MHz, which should be okay. So
> >>> on
> >>> the electrical side all seems okay, but the native aux transfer don't
> >>> work.
> >> 
> >> I recall DPCD read timeouts, but those were usually triggered by either
> >> bad clock or wiring problems (the devkit wiring I used was horrible at
> >> the beginning) from what I can recall.
> > 
> > bad clock in the sense of badly configured or bad xtal hardware?
> 
> As in, the xtal clock drives the internal PLLs and if those are
> misconfigured for whatever reason, the chip can misbehave. You might
> want to double-check the clock routing chapter in the toshiba bridge
> datasheet and matching registers.
> 
> Have you tried forcing the chip into 1.62G (instead of 2.7G) operation
> and into 1-lane DP instead of 2-lane DP mode ? Does that make any
> difference ?

The initial AUX problem is unrelated to DP link. I had problems way before 
2.7G or 2-lane DP comes into play. The problem in aux channel was caused by 
bad clock input :( and the DSI host not putting all DSI lines into LP-11.
For some reason apparently nobody had to do these kind of changes on 
samsung_dsim. I had to enable all DSI lines (incl. clock) on dsim for the 
bridge to properly use the AUX channel.

With that fixed, DPCD read is successfull and DP link training seems okay, as 
I can enable the test pattern on the bridge.

But displaying regular DSI stream is not working. I see the DSI error counter 
continuously increasing in the DSIERRCNT register (0x300).
Forcing 1-lane DP or 1.62G operation reduces the possible resolution but 
displaying does still not work.

Best regards
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Shawn Guo]

On Mon, May 15, 2023 at 06:24:24PM +0200, Marek Vasut wrote:
> Add TC9595 DSI-to-DPI and DSI-to-(e)DP bridge to
> DH electronics i.MX8M Plus DHCOM SoM . The bridge
> is populated on the SoM, but disabled by default
> unless used for display output.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
>  .../boot/dts/freescale/imx8mp-dhcom-som.dtsi  | 55 +++++++++++++++++++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
> index 98a11c31d7d45..9c0cb75386e36 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
> @@ -240,6 +240,36 @@ &i2c3 {
>  	sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
>  	status = "okay";
>  
> +	tc_bridge: bridge@f {
> +		compatible = "toshiba,tc9595", "toshiba,tc358767";

Is "toshiba,tc9595" documented?

Shawn

> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_tc9595>;
> +		reg = <0xf>;
> +		clock-names = "ref";
> +		clocks = <&clk IMX8MP_CLK_CLKOUT2>;
> +		assigned-clocks = <&clk IMX8MP_CLK_CLKOUT2_SEL>,
> +				  <&clk IMX8MP_CLK_CLKOUT2>,
> +				  <&clk IMX8MP_AUDIO_PLL2_OUT>;
> +		assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL2_OUT>;
> +		assigned-clock-rates = <13000000>, <13000000>, <156000000>;
> +		reset-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +		status = "disabled";
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port@0 {
> +				reg = <0>;
> +
> +				tc_bridge_in: endpoint {
> +					data-lanes = <1 2 3 4>;
> +					remote-endpoint = <&dsi_out>;
> +				};
> +			};
> +		};
> +	};
> +
>  	pmic: pmic@25 {
>  		compatible = "nxp,pca9450c";
>  		reg = <0x25>;
> @@ -406,6 +436,22 @@ &i2c5 {	/* HDMI EDID bus */
>  	status = "okay";
>  };
>  
> +&mipi_dsi {
> +	samsung,burst-clock-frequency = <160000000>;
> +	samsung,esc-clock-frequency = <10000000>;
> +
> +	ports {
> +		port@1 {
> +			reg = <1>;
> +
> +			dsi_out: endpoint {
> +				data-lanes = <1 2 3 4>;
> +				remote-endpoint = <&tc_bridge_in>;
> +			};
> +		};
> +	};
> +};
> +
>  &pwm1 {
>  	pinctrl-0 = <&pinctrl_pwm1>;
>  	pinctrl-names = "default";
> @@ -880,6 +926,15 @@ MX8MP_IOMUXC_SAI3_TXD__AUDIOMIX_SAI3_TX_DATA00	0xd6
>  		>;
>  	};
>  
> +	pinctrl_tc9595: dhcom-tc9595-grp {
> +		fsl,pins = <
> +			/* RESET_DSIBRIDGE */
> +			MX8MP_IOMUXC_SAI1_RXC__GPIO4_IO01		0x40000146
> +			/* DSI-CONV_INT Interrupt */
> +			MX8MP_IOMUXC_SAI5_RXD0__GPIO3_IO21		0x141
> +		>;
> +	};
> +
>  	pinctrl_touch: dhcom-touch-grp {
>  		fsl,pins = <
>  			/* #TOUCH_INT */
> -- 
> 2.39.2
> 

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Marek Vasut]

On 5/27/23 10:35, Shawn Guo wrote:
> On Mon, May 15, 2023 at 06:24:24PM +0200, Marek Vasut wrote:
>> Add TC9595 DSI-to-DPI and DSI-to-(e)DP bridge to
>> DH electronics i.MX8M Plus DHCOM SoM . The bridge
>> is populated on the SoM, but disabled by default
>> unless used for display output.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> ---
>> Cc: Conor Dooley <conor+dt@kernel.org>
>> Cc: Fabio Estevam <festevam@gmail.com>
>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
>> Cc: NXP Linux Team <linux-imx@nxp.com>
>> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> ---
>>   .../boot/dts/freescale/imx8mp-dhcom-som.dtsi  | 55 +++++++++++++++++++
>>   1 file changed, 55 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
>> index 98a11c31d7d45..9c0cb75386e36 100644
>> --- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
>> @@ -240,6 +240,36 @@ &i2c3 {
>>   	sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
>>   	status = "okay";
>>   
>> +	tc_bridge: bridge@f {
>> +		compatible = "toshiba,tc9595", "toshiba,tc358767";
> 
> Is "toshiba,tc9595" documented?

Yes, the patch is coming in via drm-misc , see:

https://cgit.freedesktop.org/drm/drm-misc/commit/?id=adbcfcc92b5aaffdee4c5e62c077919014c483d9

Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM

[Shawn Guo]

On Mon, May 15, 2023 at 06:24:24PM +0200, Marek Vasut wrote:
> Add TC9595 DSI-to-DPI and DSI-to-(e)DP bridge to
> DH electronics i.MX8M Plus DHCOM SoM . The bridge
> is populated on the SoM, but disabled by default
> unless used for display output.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>

Applied, thanks!