Balancing of the 'boot-on' coupled regulators must wait until the clients set their constraints, otherwise the balancing code might change the voltage of the not-yet-constrained regulator to the value below the bootloader-configured operation point, what might cause a system crash. This is achieved by assuming that, the minimal voltage allowed for the given 'boot-on' regulator is equal to it's current voltage until consumers apply their constraints.
Suggested-by: Dmitry Osipenko <dig...@gmail.com> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com> --- This is yet another approach to fix the regulator coupling on Exynos5800/5422 SoCs in the regulator core. I agree with Dmitry that this issue is generic and if possible it should be handled in the core. This patchset is another attempt to fix the regulator coupling on Exynos5800/5422 SoCs. Here are links to the previous attempts and discussions: https://lore.kernel.org/linux-samsung-soc/20191008101709.qVNy8eijBi0LynOteWFMnTg4GUwKG599n6OyYoX1Abs@z/ https://lore.kernel.org/lkml/20191017102758.8104-1-m.szyprow...@samsung.com/ https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.ku...@linaro.org/ https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprow...@samsung.com/ https://lore.kernel.org/linux-samsung-soc/57cf3a15-5d9b-7636-4c69-60742e8cf...@samsung.com/ The problem is with "vdd_int" regulator coupled with "vdd_arm" on Odroid XU3/XU4 boards family. "vdd_arm" is handled by CPUfreq. "vdd_int" is handled by devfreq. CPUfreq initialized quite early during boot and it starts changing OPPs and "vdd_arm" value. Sometimes CPU activity during boot goes down and some low-frequency OPPs are selected, what in turn causes lowering "vdd_arm". This happens before devfreq applies its requirements on "vdd_int". Regulator balancing code reduces "vdd_arm" voltage value, what in turn causes lowering "vdd_int" value to the lowest possible value. This is much below the operation point of the wcore bus, which still runs at the highest frequency. The issue was hard to notice because in the most cases the board managed to boot properly, even when the regulator was set to lowest value allowed by the regulator constraints. However, it caused some random issues, which can be observed as "Unhandled prefetch abort" or low USB stability. Best regards Marek Szyprowski --- drivers/regulator/core.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 03154f5b939f..7e9af7ea4bdf 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -3553,6 +3553,17 @@ static int regulator_get_optimal_voltage(struct regulator_dev *rdev, if (ret < 0) return ret; + /* + * If no constraints set yet and regulator has boot-on flag, + * keep its voltage unchanged + */ + if (tmp_min == 0 && c_rdevs[i]->constraints->boot_on) { + ret = regulator_get_voltage_rdev(c_rdevs[i]); + if (ret < 0) + return ret; + tmp_min = ret; + } + ret = regulator_check_voltage(c_rdevs[i], &tmp_min, &tmp_max); if (ret < 0) return ret; -- 2.17.1
