Hello Bartosz,
I've run into a regression on v4.20-rc1, where cpufreq on dragonboard 820c
fails to register.
I've bisected the issue to:
e888d445ac33 ("nvmem: resolve cells from DT at registration time")
If I revert that patch, cpufreq starts working on dragonboard 820c again.
Before your patch:
[ 5.052985] qcom_cpufreq_kryo_probe:110 speedbin_nvmem: ffff8000d4d51e00
[ 5.053133] qcom_cpufreq_kryo_probe:120 speedbin: ffff8000d4d51d00
[ 5.058895] qcom_cpufreq_kryo_probe:121 *speedbin: 0
After your patch:
[ 4.791664] qcom_cpufreq_kryo_probe:110 speedbin_nvmem: ffff8000d472ed00
[ 4.791815] qcom_cpufreq_kryo_probe:120 speedbin: ffff8000d451b300
[ 4.797575] qcom_cpufreq_kryo_probe:121 *speedbin: 12
The prints are debug prints that I've added locally:
--- a/drivers/cpufreq/qcom-cpufreq-kryo.c
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -107,6 +107,7 @@ static int qcom_cpufreq_kryo_probe(struct platform_device
*pdev)
}
speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ pr_err("%s:%d speedbin_nvmem: %lx\n", __func__, __LINE__,
speedbin_nvmem);
of_node_put(np);
if (IS_ERR(speedbin_nvmem)) {
if (PTR_ERR(speedbin_nvmem) != -EPROBE_DEFER)
@@ -116,6 +117,8 @@ static int qcom_cpufreq_kryo_probe(struct platform_device
*pdev)
}
speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ pr_err("%s:%d speedbin: %lx\n", __func__, __LINE__, speedbin);
+ pr_err("%s:%d *speedbin: %u\n", __func__, __LINE__, (unsigned
int)(*speedbin));
nvmem_cell_put(speedbin_nvmem);
if (IS_ERR(speedbin))
return PTR_ERR(speedbin);
So it appears that the read from nvmem_cell_read()
gets another value after your commit.
This value is then given to dev_pm_opp_set_supported_hw(),
however, since this new value (12) from nvmem_cell_read()
doesn't have any matching opp-supported-hw in device tree,
cpufreq fails to register.
This error only happens when we read this new incorrect value
(12 instead of 0).
Any idea why nvmem_cell_read() returns a new value for the
same efuse?
Kind regards,
Niklas
