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

[Konrad Dybcio]

On 6/29/26 5:49 PM, Stephan Gerhold wrote:
> 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.

sgtm

Konrad