[PATCH 1/2] clk: rockchip: rk3399: add 85.5 MHz rate to PLL rate table

[Vasily Khoruzhick]

On Fri, Sep 4, 2026 at 2:36 AM Alexey Charkov <alchark at flipper.net> 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