[PATCH 0/2] Switch hfpll & krait clock drivers to .determine_rate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



While trying to get cpufreq working on msm8974 I've found an issue with
clock rates above 2.11GHz (e.g. 2.15GHz). When a rate above this
threshold gets requested the lowest possible frequency will be selected.

This is caused by an overflow of the "long" return type of .round_rate
which has a maximum value of 2147483647 (2.14GHz) on 32-bit systems,
which msm8974 is.

We can switch the drivers to determine_rate so we can use the full
"unsigned long" type which lets us go up to 4294967295 (4.29GHz) before
an overflow happens which is significantly below the maximum frequency
of any msm8974 which is around 2.45GHz.

Note, that while setting the main hfpll now works correctly, the code
setting the div2 is still sort of broken, since it's requesting
"req->rate * 2" which will still overflow the unsigned long maximum
value, but it seems this doesn't actually break anything since the div2
doesn't use the calculated value. That's my understanding at least.

Signed-off-by: Luca Weiss <luca@xxxxxxxxx>
---
Luca Weiss (2):
      clk: qcom: clk-krait: switch to .determine_rate
      clk: qcom: clk-hfpll: switch to .determine_rate

 drivers/clk/qcom/clk-hfpll.c | 14 +++++++-------
 drivers/clk/qcom/clk-krait.c | 10 +++++-----
 2 files changed, 12 insertions(+), 12 deletions(-)
---
base-commit: 6ba8a227fd19d19779005fb66ad7562608e1df83
change-id: 20230212-clk-qcom-determine_rate-c90c9ad0b337

Best regards,
-- 
Luca Weiss <luca@xxxxxxxxx>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux