Generally it's not known how a disabled PWM behaves. However if the
bootloader hands over a disabled PWM that drives a regulator and it's
claimed the regulator is enabled, then the most likely assumption is
that the PWM emits the inactive level. This is represented by duty_cycle
= 0 even for .polarity == PWM_POLARITY_INVERSED.

Put that assumption in a dedicated function, document that it relies on
an assumption and use that in both functions pwm_regulator_init_state()
and pwm_regulator_get_voltage().

With that pwm_regulator_init_boot_on() can be dropped, as it's only
purpose is to make pwm_get_state() return a configuration that results
in emitting constantly the inactive level if the PWM is off.

Fixes: 6a7d11efd691 ("regulator: pwm-regulator: Calculate the output voltage for disabled PWMs")
Fixes: b3cbdcc19181 ("regulator: pwm-regulator: Manage boot-on with disabled PWM channels")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
Hello,

this is my suggestion to fix the concerns I expressed in
https://lore.kernel.org/all/hf24mrplr76xtziztkqiscowkh2f3vmceuarecqcwnr6udggs6@uiof2rvvqq5v/
.

It's only compile tested as I don't have a machine with a pwm-regulator.
So getting test feedback before applying it would be great.

Best regards
Uwe

 drivers/regulator/pwm-regulator.c | 68 +++++++++++--------------------
 1 file changed, 23 insertions(+), 45 deletions(-)

diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
index 7434b6b22d32..648a53b67a2f 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -48,18 +48,37 @@ struct pwm_voltages {
 	unsigned int dutycycle;
 };
 
+static unsigned int pwm_regulator_get_relative_dutycyle(struct regulator_dev *rdev,
+							unsigned int scale)
+{
+	struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
+	struct pwm_state pwm_state;
+
+	pwm_get_state(drvdata->pwm, &pwm_state);
+
+	if (!pwm_state.enabled) {
+		/*
+		 * In general it's unknown what the output of a disabled PWM is.
+		 * The only sane assumption here is it emits the inactive level
+		 * which corresponds to duty_cycle = 0 (independent of the
+		 * polarity).
+		 */
+		return 0;
+	}
+
+	return pwm_get_relative_duty_cycle(&pwm_state, scale);
+}
+
 /*
  * Voltage table call-backs
  */
 static void pwm_regulator_init_state(struct regulator_dev *rdev)
 {
 	struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
-	struct pwm_state pwm_state;
 	unsigned int dutycycle;
 	int i;
 
-	pwm_get_state(drvdata->pwm, &pwm_state);
-	dutycycle = pwm_get_relative_duty_cycle(&pwm_state, 100);
+	dutycycle = pwm_regulator_get_relative_dutycyle(rdev, 100);
 
 	for (i = 0; i < rdev->desc->n_voltages; i++) {
 		if (dutycycle == drvdata->duty_cycle_table[i].dutycycle) {
@@ -151,20 +170,10 @@ static int pwm_regulator_get_voltage(struct regulator_dev *rdev)
 	int min_uV = rdev->constraints->min_uV;
 	int max_uV = rdev->constraints->max_uV;
 	int diff_uV = max_uV - min_uV;
-	struct pwm_state pstate;
 	unsigned int diff_duty;
 	unsigned int voltage;
 
-	pwm_get_state(drvdata->pwm, &pstate);
-
-	if (!pstate.enabled) {
-		if (pstate.polarity == PWM_POLARITY_INVERSED)
-			pstate.duty_cycle = pstate.period;
-		else
-			pstate.duty_cycle = 0;
-	}
-
-	voltage = pwm_get_relative_duty_cycle(&pstate, duty_unit);
+	voltage = pwm_regulator_get_relative_dutycyle(rdev, duty_unit);
 	if (voltage < min(max_uV_duty, min_uV_duty) ||
 	    voltage > max(max_uV_duty, min_uV_duty))
 		return -ENOTRECOVERABLE;
@@ -321,32 +330,6 @@ static int pwm_regulator_init_continuous(struct platform_device *pdev,
 	return 0;
 }
 
-static int pwm_regulator_init_boot_on(struct platform_device *pdev,
-				      struct pwm_regulator_data *drvdata,
-				      const struct regulator_init_data *init_data)
-{
-	struct pwm_state pstate;
-
-	if (!init_data->constraints.boot_on || drvdata->enb_gpio)
-		return 0;
-
-	pwm_get_state(drvdata->pwm, &pstate);
-	if (pstate.enabled)
-		return 0;
-
-	/*
-	 * Update the duty cycle so the output does not change
-	 * when the regulator core enables the regulator (and
-	 * thus the PWM channel).
-	 */
-	if (pstate.polarity == PWM_POLARITY_INVERSED)
-		pstate.duty_cycle = pstate.period;
-	else
-		pstate.duty_cycle = 0;
-
-	return pwm_apply_might_sleep(drvdata->pwm, &pstate);
-}
-
 static int pwm_regulator_probe(struct platform_device *pdev)
 {
 	const struct regulator_init_data *init_data;
@@ -404,11 +387,6 @@ static int pwm_regulator_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	ret = pwm_regulator_init_boot_on(pdev, drvdata, init_data);
-	if (ret)
-		return dev_err_probe(&pdev->dev, ret,
-				     "Failed to apply boot_on settings\n");
-
 	regulator = devm_regulator_register(&pdev->dev,
 					    &drvdata->desc, &config);
 	if (IS_ERR(regulator)) {

base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
-- 
2.43.0

Hello Uwe,

On Mon, Jun 10, 2024 at 12:46 PM Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
[...]
> this is my suggestion to fix the concerns I expressed in
> https://lore.kernel.org/all/hf24mrplr76xtziztkqiscowkh2f3vmceuarecqcwnr6udggs6@uiof2rvvqq5v/
> .
>
> It's only compile tested as I don't have a machine with a pwm-regulator.
> So getting test feedback before applying it would be great.
Unfortunately this approach breaks my Odroid-C1 board again with the
same symptoms as before the mentioned commits: random memory
corruption, preventing the board from booting to userspace.

The cause also seems to be the same as before my commits:
- period (3666ns) and duty cycle (3333ns) in the hardware registers
the PWM controller when Linux boots, but the PWM output is disabled
- with a duty cycle of 0 or PWM output being disabled the output of
the voltage regulator is 1140mV, which is the only allowed voltage for
that rail (even though the regulator can achieve other voltages)
- pwm_regulator_enable() calls pwm_enable() which simply takes the
period and and duty cycle that was read back from the hardware and
enables the output, resulting in undervolting of a main voltage rail
of the SoC

I hope that this (especially the last item) also clarifies the
question you had in the linked mail on whether updating
pwm_regulator_init_state() would help/work.

Regarding your alternative and preferred approach from the other mail:
> Alternatively (and IMHO nicer) just keep the pwm_state around and don't
> use the (mis) feature of the PWM core that pwm_get_state only returns
> the last set state.
I tried this to see if it would work also for my Odroid-C1 board and
I'm happy to report it does - see the attached diff.
In case you are happy with this approach I can submit it as a proper patch.


Best regards,
Martin

Hello Martin,

On Sun, Jun 16, 2024 at 01:10:32AM +0200, Martin Blumenstingl wrote:
> On Mon, Jun 10, 2024 at 12:46 PM Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> [...]
> > this is my suggestion to fix the concerns I expressed in
> > https://lore.kernel.org/all/hf24mrplr76xtziztkqiscowkh2f3vmceuarecqcwnr6udggs6@uiof2rvvqq5v/
> > .
> >
> > It's only compile tested as I don't have a machine with a pwm-regulator.
> > So getting test feedback before applying it would be great.
> Unfortunately this approach breaks my Odroid-C1 board again with the
> same symptoms as before the mentioned commits: random memory
> corruption, preventing the board from booting to userspace.
> 
> The cause also seems to be the same as before my commits:
> - period (3666ns) and duty cycle (3333ns) in the hardware registers
> the PWM controller when Linux boots, but the PWM output is disabled
> - with a duty cycle of 0 or PWM output being disabled the output of
> the voltage regulator is 1140mV, which is the only allowed voltage for
> that rail (even though the regulator can achieve other voltages)
> - pwm_regulator_enable() calls pwm_enable() which simply takes the
> period and and duty cycle that was read back from the hardware and
> enables the output, resulting in undervolting of a main voltage rail
> of the SoC

Ah, indeed. pwm_enable() looks so innocent, but in fact the details are
difficult. One more reason to drop that caching of parameters in the pwm
core.

> I hope that this (especially the last item) also clarifies the
> question you had in the linked mail on whether updating
> pwm_regulator_init_state() would help/work.
> 
> Regarding your alternative and preferred approach from the other mail:
> > Alternatively (and IMHO nicer) just keep the pwm_state around and don't
> > use the (mis) feature of the PWM core that pwm_get_state only returns
> > the last set state.
> I tried this to see if it would work also for my Odroid-C1 board and
> I'm happy to report it does - see the attached diff.
> In case you are happy with this approach I can submit it as a proper patch.

Yes, I like it. From a quick glance, I only wonder about the dropped
error message in pwm_regulator_set_voltage(). Probably it's right that
this function is silent, but then this is orthogonal to the patch
we're discussing and should go in a separate patch.

Thanks for your valuable cooperation.

Best regards
Uwe