On Tue, Feb 04, 2025 at 11:13:08PM +0530, Taniya Das wrote: > On 2/4/2025 3:38 PM, Johan Hovold wrote: > > On Mon, Jan 13, 2025 at 10:57:03PM +0530, Taniya Das wrote: > >> During boot-up, there is a possibility that the PLL configuration might > >> be missed even after invoking pll_configure() from the clock controller > >> probe. This is often due to the PLL being connected to rail or rails > >> that are in an OFF state and current clock controller also cannot vote > >> on multiple rails. As a result, the PLL may be enabled with suboptimal > >> settings, leading to functional issues. > >> > >> The PLL configuration, now part of clk_alpha_pll, can be reused to > >> reconfigure the PLL to a known good state before scaling for frequency. > >> The 'clk_alpha_pll_reconfigure()' can be updated to support more PLLs > >> in future. > > > > This sounds like a hack. You already describe the underlying problem (and > > indirectly its solution) in the first paragraph above, namely that the > > video clock controller has not enabled the power domain needed to > > configure the PLL. > > This is not a hack, but another alternative way to ensure the PLL is > configured to the right configuration before being used. I say it's a hack since it sounds like since you're relying on some other entity to have enabled resources that this clock controller depends on. > > I believe support for clock controllers that need to enable multiple > > power domains is on its way into 6.15: > > > > https://lore.kernel.org/lkml/20250117-b4-linux-next-24-11-18-clock-multiple-power-domains-v10-0-13f2bb656dad@xxxxxxxxxx/ > > > > Perhaps that's what you need to fix this properly. > > Yes, this is just to add a dependency on clock controller to put the > rail vote, but this series does not fully solve the clock controller's > PLL requirement problems. Why not? What else is needed beyond enabling the video (?) power domain before configuring the PLL? Johan
