Re: [PATCH] regulator: do not balance 'boot-on' coupled regulators without constraints

[Viresh Kumar]

+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 <digetx@xxxxxxxxx>
> Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> ---
> 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.szyprowski@xxxxxxxxxxx/
> https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.kumar@xxxxxxxxxx/
> https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprowski@xxxxxxxxxxx/
> https://lore.kernel.org/linux-samsung-soc/57cf3a15-5d9b-7636-4c69-60742e8cfae6@xxxxxxxxxxx/
> 
> 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