> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen <tomi.valkeinen@xxxxxx>: > > On 10/11/2020 18:49, H. Nikolaus Schaller wrote: > > I guess you have the same issue. It goes to dsi_bridge_mode_valid, then __dsi_calc_config, and stays > there finding good clocks. Yes, I could trace it down to exactly this point. So the culprit is somehow the panel driver. Because it asks for clocks that the PLL driver does not want to provide... Or is it the victim? Here is what dmesg reports with even more printk(): [ 276.970635] drm_helper_probe_single_connector_modes 12 count=1 [ 277.003509] drm_mode_validate_pipeline 2 ret=0 status=0 [ 277.038678] drm_bridge_chain_mode_valid: func=dsi_bridge_mode_valid+0x0/0xa0 [omapdrm] [ 277.047199] dsi_bridge_mode_valid [ 277.050786] __dsi_calc_config [ 277.057270] dsi_vm_calc [ 277.073251] dss_pll_calc_a clkin=19200000 pll_min=1555386656 pll_max=1555410656 func=dsi_vm_calc_pll_cb+0x0/0x48 [omapdrm] [ 277.084975] dss_pll_calc_a pll_hw_max=1800000000 fint_hw_min=150000 fint_hw_max=52000000 [ 277.093637] dss_pll_calc_a n_start=1 n_inc=1 n_stop=128 pll_max'=1555410656 [ 277.101062] dss_pll_calc_a n=1 clkin=19200000 fint=19200000 [ 277.107152] dss_pll_calc_a m_start=41 m_inc=1 m_stop=40 Ok, we have to wait quite a while until the for(m;;) loop ends, because m_stop < m_start and m_inc is positive. So something in the formulae in dss_pll_calc_a() does not fit or has unintended rounding effects. Or the values reported by w677l_get_modes() do not fit anything. I think these findings and ideas should help to find a fix. BR and thanks, Nikolaus _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
