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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
