On Fri, Sep 4, 2026 at 1:59 AM Vasily Khoruzhick <[email protected]> wrote: > > On Wed, Sep 2, 2026 at 1:43 AM Alexey Charkov <[email protected]> wrote: > > > > Hi Vasily, > > Hey Alexey, > > > > diff --git a/drivers/clk/rockchip/clk-rk3399.c > > > b/drivers/clk/rockchip/clk-rk3399.c > > > index c2b243d7a5e2..db241d2df625 100644 > > > --- a/drivers/clk/rockchip/clk-rk3399.c > > > +++ b/drivers/clk/rockchip/clk-rk3399.c > > > @@ -98,6 +98,7 @@ static struct rockchip_pll_rate_table > > > rk3399_pll_rates[] = { > > > RK3036_PLL_RATE( 148500000, 1, 99, 4, 4, 1, 0), > > > RK3036_PLL_RATE( 106500000, 1, 71, 4, 4, 1, 0), > > > RK3036_PLL_RATE( 96000000, 1, 64, 4, 4, 1, 0), > > > + RK3036_PLL_RATE( 85500000, 1, 57, 4, 4, 1, 0), > > > > There is already an entry for 1368000000, which is 16x your rate, and > > the 16x divisor should fit comfortably into the downstream clock's > > 8-bit divisor field. Do you really need a separate PLL rate? Have you > > checked what the hardware arrives at with the unmodified PLL table - > > e.g. via /sys/kernel/debug/clk/clk_summary? > > 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. 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. Best regards, Alexey
