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

[Alexey Charkov]

On Sun, Sep 6, 2026 at 10:09 AM Vasily Khoruzhick <anarsoul at gmail.com> wrote:
>
> 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

Which matches the pixel clock (dclk) range for HDMI 2.0, so nothing is
disproven yet

> > 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.

Hope you have a serial console or ssh connection to the board. If it
doesn't work you'll know soon enough.

What I'm pointing out is that the clock setup implied by the current
dtsi doesn't make much sense: VOP's dclk is driven off VPLL via a mux
and divisor. If the encoder's pixel clock is truly driven directly off
VPLL then Rockchip designed the muxes and dividers for nothing, as
they will always be no-ops. This doesn't square, so something must be
wrong, and I believe it's the dtsi.

I'll be happy to be proven wrong here.

Best regards,
Alexey