On Fri, Sep 4, 2026 at 2:36 AM Alexey Charkov <[email protected]> wrote:
> > See arch/arm64/boot/dts/rockchip/rk3399-base.dtsi, hdmi ref clock is > > wired directly to VPLL, and dw_hdmi-rockchip calls clk_set_rate() with > > pixel clock for ref clock, see > > dw_hdmi_rockchip_encoder_atomic_mode_set(). So at least in the rk3399 > > case VPLL is supposed to support the required pixel clock. Without the > > first patch 1366x768 mode with 85.5MHz pixel clock is just rejected. > > I strongly suspect that the dtsi doesn't describe the real clock usage > here. The TRM for RK3399 doesn't show any "ref" clock for HDMI, and no > TRM-documented VPLL users look like anything that could connect > directly to the HDMI controller. See "1.1.11 HDMI Interface", it explicitly mentions 13.5–600MHz input reference clock > I believe something is hardcoding the divisor (or leaving it at the > power-on default) in the actual DCLK of a VOP which the HDMI > controller uses, instead of modelling it properly as a mux (frac/div) > feeding off VPLL via another mux - both perfectly representable in the > clock framework and already envisaged in the clock driver, making the > PLL table patching unnecessary. > > Can you please try re-pointing the "ref" clock at DCLK_VOP0 (or 1, > depending on which one your HDMI controller uses)? Your clock summary > already shows that something is assigning its parent to DCLK_VOPx_DIV > and the latter's parent to PLL_VPLL, so rate changes the current > driver code does on VPLL propagate to the muxed and divided downstream > consumer as a side-effect rather than as an actual rate request. I don't think it is a reasonable ask. Wrong clock for the HDMI encoder would just result in non-working HDMI output and no feasible way for me to debug what is wrong. Regards, Vasily
