+Saravana, On 05-06-20, 08:37, Marek Szyprowski wrote: > 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;
This is exactly what Saravana tried to solve earlier AFAIR, lets see what he has to say here. -- viresh
