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.
Please see clk_summary attached for 1280x800 (no patches applied),
broken 1366x768 (just the first patch applied), and working 1366x768
(both patches applied)
Regards,
Vasily
clk_summary_1280x800.gz
Description: application/gzip
clk_summary_1366x768_broken.gz
Description: application/gzip
clk_summary_1366x768_working.gz
Description: application/gzip
