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

[Alexey Charkov]

On Fri, Sep 4, 2026 at 1:59 AM Vasily Khoruzhick <anarsoul at gmail.com> wrote:
>
> On Wed, Sep 2, 2026 at 1:43 AM Alexey Charkov <alchark at flipper.net> 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