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@xxxxxxx> > >>> > >>> 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/
