Re: [PATCH 07/12] clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src
From: Konrad Dybcio
Date: Mon Jun 15 2026 - 10:49:34 EST
On 6/10/26 4:09 PM, Stephan Gerhold wrote:
> On Wed, Jun 10, 2026 at 03:50:11PM +0200, Konrad Dybcio wrote:
>> On 6/9/26 4:14 PM, Stephan Gerhold wrote:
>>> From: Stephan Gerhold <stephan@xxxxxxxxxxx>
>>>
>>> This clock does not seem to exist on MDM9607. Reading/writing the registers
>>> always results in 0 or crashes. The math in the frequency table is also
>>> broken. GPLL2 on MDM9607 runs at 480 MHz, so:
>>>
>>> - F(155000000, P_GPLL2, 6, 0, 0), // 480 MHz/6 = 80 MHz, not 155 MHz
>>> - F(310000000, P_GPLL2, 3, 0, 0), // 480 MHz/3 = 160 MHz, not 310 MHz
>>>
>>> Presumably, this definition was mistakenly copied as-is from gcc-msm8916
>>> (which uses 930 MHz for GPLL2). There are no branch consumers of this root
>>> clock inside gcc-mdm9607 (notably, gcc_apss_tcu_clk has bimc_ddr_clk_src as
>>> parent instead of this clock), so we can just drop it.
>>>
>>> Cc: stable@xxxxxxxxxxxxxxx
>>> Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver")
>>> Signed-off-by: Stephan Gerhold <stephan@xxxxxxxxxxx>
>>> ---
>>
>> It does, CMD_RCGR @ 0x37000
>>
>> Interestingly, there's also an SMMU instance.. although downstream doesn't
>> seem bothered with it
>>
>
> Thanks for checking, but that still doesn't give us enough to work with
> it. In particular:
>
> - What are the frequency tables? Which parents exist with which IDs?
> - What is the hid_width?
> - Where do we hook it up to some children?
>
> The way it is right now it's definitely wrong. I don't think we'll need
> it so removing it like this patch is probably the easiest thing to do...
>
> Thanks,
> Stephan
>
> PS: This platform has the weird TZ-managed SMMU (like MSM8916), so there
> isn't much you can do with it from Linux. Unless you are running TF-A,
> then you can describe it as "arm,mmu-500" and use it for everything
> pretty much exactly like you would normally expect. But you still don't
> need to do anything with this clock.
Alright then, let's just get rid of it
Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
Konrad