diff mbox series

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

Message ID 20230515162424.67597-1-marex@denx.de
State Accepted
Commit 20d0b83e712b92163ddcfb313288272720272733
Headers show
Series arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM | expand

Commit Message

Marek Vasut May 15, 2023, 4:24 p.m. UTC
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(+)

Comments

Alexander Stein May 24, 2023, 10:24 a.m. UTC | #1
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
Marek Vasut May 24, 2023, 10:37 a.m. UTC | #2
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
Shawn Guo May 27, 2023, 8:35 a.m. UTC | #3
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
>
Marek Vasut May 27, 2023, 10:19 a.m. UTC | #4
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
Shawn Guo May 27, 2023, 10:47 a.m. UTC | #5
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!
diff mbox series

Patch

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