[LEDE-DEV] ipq40xx cpu frequency
Christian Lamparter
chunkeey at gmail.com
Sat May 5 11:39:10 PDT 2018
Hello,
On Friday, May 4, 2018 4:12:16 PM CEST Roman Yeryomin wrote:
> I'm seeing this
>
> [ 1.275858] cpufreq: cpufreq_online: CPU0: Running at unlisted freq:
> 632000 KHz
> [ 1.276620] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency
> changed to: 716000 KHz
Sorry, but I'm having this "déjà vu"? I do remember *trying* to talk with
you about this in this thread "ipq806x: add ap.dk01.1 board support" already.
<https://patchwork.ozlabs.org/patch/826312/>
Back then you initially went with 710 MHz and I warned:
|There's a reason to stick with the 666MHz rate though. You should check
|if the device produces messages like:
|[ 1.399981] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 666000 KHz
|[ 1.400256] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 710000 KHz
|(From what I know, the SBL actually sets it to 666MHz)
|
|But there's more. If you look at qualcomm's page, it's says that the
|CPU Clock Speed is 717 MHz: <https://www.qualcomm.com/products/ipq4028>
|
|Since you are working for a OEM/ODM. You could please ask what is the
|right MHz table for these devices? Unfortunately, Qualcomm never got
|around to fix this upstream and without an official statement from them
|it's very difficult to push stuff like this upstream.
Have we come full circle now?
> on ap-dk01 board (I suspect others may be affected too, I don't
> have hw to test).
Yes that is true some boards print the same warning (with different
unlisted frequencies). The patch was sent upstream to linux-clk along
with a request on how this should be handled. Sadly no maintainer
has replied, even though the some of the IPQ40XX boards are crashing
without it.
> Looks like related to your commit
> a44d435c1d ipq40xx: fix apss cpu overclocking spam
>
> While it fixes the original problem described, it would be nice not to
> misconfigure the clock anyway.
Hmm? I think this is a misunderstanding, or are you jumping to conclusions?
The patch does not misconfigure the clock. The 900-clk-fix.patch
message explains in detail what the patch does and why:
|This patch attempts to fix the issue by modifying
|clk_cpu_div_round_rate(), clk_cpu_div_set_rate(), clk_cpu_div_recalc_rate()
|to use a new qcom_find_freq_close() function, which returns the closest
|matching frequency, instead of the next higher. This way, the SoC in
|the FB4040 (with its max clock speed of 710.4 MHz) will no longer
|try to overclock to 761 MHz.
> Also, since the official highest frequency is 716.8MHz, wouldn't it be
> more logical to fix it in appropriate board dts (if needed) and not in
> the common dtsi?
The gcc-ipq4019.c clk driver has a fixed frequency table defining all
the valid frequencies. The reason why this "worked" in the past (i.e 4.9)
was a bug in the gcc-ipq4019.c driver that got fixed with:
"clk: qcom: ipq4019: Add the apss cpu pll divider clock node"
From what I can tell, back then the clk driver didn't really program
the P_DDRPLLAPSS clock so the device was left running at the
max frequency that u-boot or SBL1 programmed it.
Anyway, I took a peek into the patches that I sent to Mathias and John.
From what I can tell the 716.8 MHz to 716 MHz didn't happen there. But I
think I know where it comes from: You see "Sricharan R" posted this patch
to linux-msm-arm: <https://patchwork.kernel.org/patch/10303787/>. But please
check with Mathias too (CCd).
Thank you and best regards,
Christian
More information about the Lede-dev
mailing list