Hi Dominique, On 9/26/26 05:31, Dominique Belhachemi wrote: > On Tue, Sep 15, 2026 at 11:32 AM Michal Wilczynski > <[email protected]> wrote: >> >> +static int starfive_hdmi_phy_probe(struct platform_device *pdev) >> +{ >> + ret = clk_set_rate(inno->phyclk, 297000000); >> + if (ret) { >> + dev_err(dev, "Failed to set default rate: %d\n", ret); >> + goto err_del_clk_provider; >> + } > > Hi Michal, > > Can we drop these 5 lines? > When my 4K monitor comes up in mode (3840x2160@30, 297 MHz) the screen > stays blank. > > When the first real modeset requests a mode whose pixel clock is also 297 MHz, > clk_set_rate(hdmi_pclk, 297000000) then sees cur == want and does nothing. > So the pre-PLL is never actually programmed. > > Without these 5 lines inno->pixclock stays 0, > so the first modeset's clk_set_rate() always runs .set_rate() for real. > > Together with my forgotten fix from May we can have working 4K@30 on the VF2. > https://lore.kernel.org/all/[email protected]/
Yeah, these lines are a problem in another way too. Marek Szyprowski reported that v4 hangs when everything is built as modules, which is what made me look at them. The write lands in registers gated by the controller's system clock, inside PD_VOUT and the PHY holds neither - it cannot hold that clock without creating a probe cycle with voutcrg. His config is as follows: CONFIG_CLK_STARFIVE_JH7110_VOUT=y with the vout subsystem, hdmi subsystem, controller and phy all as modules so voutcrg is up long before the PHY arrives from userspace. If nothing is holding hdmi_tx_sys by then - clk_disable_unused() gates it at late_initcall_sync and the write wedges the bus. I could not reproduce his exact failure, but could reproduce this with fw_devlink=off hopefully this is fixing his issue as well. Anyway this code will be removed in v5. > > Best > -Dominique > Best regards, -- Michal Wilczynski <[email protected]>
