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

[Alexander Stein <alexander.stein@ew.tq-group.com>]

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/



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