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 <[email protected]>
---
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
<[email protected]> 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
> <[email protected]> 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