Re: [PATCH 04/12] clk: qcom: gcc-mdm9607: Fix BIMC PLL definition

[Stephan Gerhold]

On Tue, Jun 16, 2026 at 12:52:48PM +0200, Konrad Dybcio wrote:
> On 6/10/26 7:58 PM, Stephan Gerhold wrote:
> > On Wed, Jun 10, 2026 at 10:43:12PM +0530, Taniya Das wrote:
> >> On 6/9/2026 7:44 PM, Stephan Gerhold wrote:
> >>> The gcc-mdm9607 driver was originally based on gcc-msm8916, but a closer
> >>> match nowadays is gcc-msm8909. Looking at the differences between
> >>> gcc-mdm9607 and gcc-msm8909, there is quite some confusion around the
> >>> definitions for the BIMC PLL.
> >>>
> >>> It turns out the BIMC PLL on MDM9607 is actually an Alpha PLL just like on
> >>> MSM8909. We can vote for it using BIT(2), which explains why BIT(3) was
> >>> used for GPLL2.
> >>
> >> BIMC PLL is never controlled from High Level OS (APSS). These are
> >> controlled by other subsystems and voting should be via the ICC for BW
> >> requirements.
> >>
> > 
> > The driver doesn't really control the BIMC PLL here, the PLL is defined
> > with fixed/shared/read-only ops so it mostly just exists to model the
> > clock tree properly and have the clock rate readable for the PLL itself
> > and any downstream consumers.
> > 
> > There are multiple drivers that do it like this (e.g. gcc-msm8916,
> > gcc-msm8939), is there a reason why we should drop this?
> 
> My fear is that the kernel may have stale data at any point.. perhaps
> unless we set CLK_GET_RATE_NOCACHE?
> 

Looking into it a bit more, it looks like this "read-only" feature with
firmware managing the clocks is unfortunately a lost cause...

CLK_GET_RATE_NOCACHE does help for the clock *rate*, but the clock
*parent* is still cached in the clock framework (and only read once when
registering the clock). So if you have clocks switching e.g. between the
BIMC PLL and XO or a GPLL you won't ever see this properly in debugfs.

In addition, when enabling a child clock branch we make a vote for the
registration time parent (e.g. the BIMC PLL). But if the parent changes
later our vote is never updated and will keep clocks alive even if the
firmware already dropped its votes ... :/

I will drop the BIMC PLL and other firmware-managed clocks in v2 like
you suggested. It doesn't seem worth the hassle, and that's what all
newer SoCs do as well.

Thanks,
Stephan