Hi Angelo & Esteban, On Wed, Jul 15, 2026 at 03:52:05PM +0200, Esben Haabendal wrote: > "AngeloGioacchino Del Regno" <[email protected]> > writes: > > > On 7/15/26 15:36, Gary Bisson wrote: > >> Hi, > >> > >> On Wed, Jul 15, 2026 at 03:25:11PM +0200, AngeloGioacchino Del Regno wrote: > >>> On 7/15/26 14:53, Esben Haabendal wrote: > >>>> Gary Bisson <[email protected]> writes: > >>>> > >>>>> Some bridges, such as the TI SN65DSI83, require the HS clock to be > >>>>> running in order to lock its PLL during its own pre-enable function. > >>>>> > >>>>> Without this change, the bridge gives the following error: > >>>>> sn65dsi83 14-002c: failed to lock PLL, ret=-110 > >>>>> sn65dsi83 14-002c: Unexpected link status 0x01 > >>>>> sn65dsi83 14-002c: reset the pipe > >>>>> > >>>>> Move the necessary functions from enable to pre-enable. > >>>>> > >>>>> Signed-off-by: Gary Bisson <[email protected]> > >>>> > >>>> Hi > >>>> > >>>> I have run into the same problem, but in combination with another > >>>> pipeline. I am seeing same problem with an i.MX8 using the nwl-dsi > >>>> bridge and the dcss driver. > >>>> > >>>> I have submitted a fix that adresses the problem in the ti-sn65dsi83 > >>>> driver instead. With a bit of luck, it can replace the fix proposed in > >>>> this thread. > >>>> > >>>> See > >>>> https://lore.kernel.org/all/[email protected]/ > >> > >> Thanks, just tried it on 7.2-rc3 with my patch reverted and confirm that > >> it works too. My assumption was that the SN65DSI83 was locking the PLL > >> earlier for some specific reason and therefore was reluctant to change > >> it. > >> > >>>> /Esben > >>> > >>> That clarifies a lot of things. > >>> > >>> The patch on mtk_dsi shall be reverted then. > >> > >> Angelo, do you want me to offer the revert patch? Should I wait to see > >> how the other thread goes? > >> > > > > Gary, yes please, send a revert and make sure to explain the reason why > > we're reverting this in the commit description :-) > > Maybe test if my fix actually solves the problem with the mtk_dsi driver > also ;)
As mentioned in the other thread, your patch works but it might break the init sequence recommended by the bridge datasheet. Moreover, the drm_bridge.c doc [1] does mention that the clock lane should be initialized during pre_enable. If we agree on this assumption I believe my patch should not be reverted. Maybe Adam's bridge driver must be patched instead, just like the nwl-dsi driver should be updated to follow the drm recommendation. Let me know your thoughts. Regards, Gary [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_bridge.c#n169
