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

From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Marek Vasut <marex@denx.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Conor Dooley <conor+dt@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	NXP Linux Team <linux-imx@nxp.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Rob Herring <robh+dt@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM
Date: Fri, 26 May 2023 14:52:21 +0200	[thread overview]
Message-ID: <7530294.EvYhyI6sBW@steina-w> (raw)
In-Reply-To: <75c45018-fae3-aa9d-db5d-7d378f69b53c@denx.de>

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/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel