Hi Sascha,
Am Mittwoch, 8. Dezember 2021, 16:12:30 CET schrieb Sascha Hauer:
On the rk3568 we have this (simplified) situation:
.--------. .-----. .---------. -| hpll |--.--| /n |----|dclk_vop0|- `--------´ | `-----´ `---------´ | .-----. .---------. `--| /m |----|dclk_vop1|- | `-----´ `---------´ | .---------. `-------------|hdmi_ref |- `---------´
hpll is the PLL that drives the HDMI reference clock and the pixel clocks for the different CRTCs (dclk_vop0/1). Between the pixel clocks and the hpll there are programmable dividers whereas the HDMI reference clock is directly connected to the hpll.
For the HDMI output to work the pixel clock must be the same as the HDMI reference clock, hence the dividers must be programmed to 1. Normally a rate change on dclk_vop0/1 propagates through to the hpll and the clock framework picks a suitable combination of hpll and divider settings. by accident it picks a divider setting of 1 for the standard 1080p case, but other divider settings for most other resolutions leaving the HDMI port non working.
This patch is not a solution, it merely puts the finger in the wound. We leave out the divider for the composite clock for dclk_vop0 which then leaves the divider at the bootloader default setting of 1. I assume the divider is disturbing only for the HDMI case, but needed for other outputs. Any thoughts how this can be handled?
I'm not even sure if/how the common clock framework keeps track of diverging wishes to parent-rates :-) .
But I do see two direct issues in the _existing_ code.
dclk_vop0/1 uses CLK_SET_RATE_PARENT so is allowed to change the rates of its parent clock(s).
Its parent clocks are not only hpll but can also be vpll, gpll and cpll. So this can cause even more mayhem, if the ccf for example decides to select the gpll and then change its rate,which may result in a lot of peripherals getting their rates changed under them ;-) .
On the other hand I see in the clock driver that hdmi-ref is not allowed to change its parent rate, so can only select between hpll and hpll_ph0 (1/2 the rate?).
So I guess, one way could be: - add CLK_SET_RATE_PARENT to the hdmi-ref clock - drop CLK_SET_RATE_PARENT from the dclks - make sure hdmi-clock is set before the dclk
Heiko
Signed-off-by: Sascha Hauer s.hauer@pengutronix.de
drivers/clk/rockchip/clk-rk3568.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c index 69a9e8069a486..2d04d8253ca22 100644 --- a/drivers/clk/rockchip/clk-rk3568.c +++ b/drivers/clk/rockchip/clk-rk3568.c @@ -1038,8 +1038,8 @@ static struct rockchip_clk_branch rk3568_clk_branches[] __initdata = { RK3568_CLKGATE_CON(20), 8, GFLAGS), GATE(HCLK_VOP, "hclk_vop", "hclk_vo", 0, RK3568_CLKGATE_CON(20), 9, GFLAGS),
- COMPOSITE(DCLK_VOP0, "dclk_vop0", hpll_vpll_gpll_cpll_p, CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
RK3568_CLKSEL_CON(39), 10, 2, MFLAGS, 0, 8, DFLAGS,
- COMPOSITE_NODIV(DCLK_VOP0, "dclk_vop0", hpll_vpll_gpll_cpll_p, CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
RK3568_CLKSEL_CON(39), 10, 2, MFLAGS, RK3568_CLKGATE_CON(20), 10, GFLAGS),