Re: [PATCH 0/3] Add support to reconfigure PLL

[Johan Hovold <johan@kernel.org>]

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@linaro.org/
> > 
> > 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