On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
Before this commit a suspend + resume of the LPSS PWM controller would result in the controller being reset to its defaults of output-freq = clock/256, duty-cycle=100%, until someone changes to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consumer (the i915 driver) was always making duty-cycle changes on resume. With the conversion of the i915 driver to the atomic PWM API the driver now only disables/enables the PWM on suspend/resume leaving the output-freq and duty as is, triggering this problem.
The LPSS PWM controller has a mechanism where the ctrl register value and the actual base-unit and on-time-div values used are latched. When software sets the SW_UPDATE bit then at the end of the current PWM cycle, the new values from the ctrl-register will be latched into the actual registers, and the SW_UPDATE bit will be cleared.
The problem is that before this commit our suspend/resume handling consisted of simply saving the PWM ctrl register on suspend and restoring it on resume, without setting the PWM_SW_UPDATE bit. When the controller has lost its state over a suspend/resume and thus has been reset to the defaults, just restoring the register is not enough. We must also set the SW_UPDATE bit to tell the controller to latch the restored values into the actual registers.
Fixing this problem is not as simple as just or-ing in the value which is being restored with SW_UPDATE. If the PWM was enabled before we must write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE. We must also wait for PWM_SW_UPDATE to become 0 again and depending on the model we must do this either before or after the setting of PWM_ENABLE.
All the necessary logic for doing this is already present inside pwm_lpss_apply(), so instead of duplicating this inside the resume handler, this commit makes the resume handler use pwm_lpss_apply() to restore the settings when necessary. This fixes the output-freq and duty-cycle being reset to their defaults on resume.
...
-static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)+static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state, bool from_resume){ struct pwm_lpss_chip *lpwm = to_lpwm(chip); int ret = 0;
if (state->enabled) { if (!pwm_is_enabled(pwm)) {
pm_runtime_get_sync(chip->dev);
if (!from_resume)pm_runtime_get_sync(chip->dev);ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
if (ret)
if (ret && !from_resume) pm_runtime_put(chip->dev);
pm_runtime_put(chip->dev);
if (!from_resume)pm_runtime_put(chip->dev);}
return ret;
}
Maybe I'm too picky, but I would go even further and split apply to two versions
static int pwm_lpss_apply_on_resume(struct pwm_chip *chip, struct pwm_device *pwm, const struct pwm_state *state)
{ struct pwm_lpss_chip *lpwm = to_lpwm(chip);
if (state->enabled) return pwm_lpss_prepare_enable(lpwm, pwm, state, !pwm_is_enabled(pwm)); if (pwm_is_enabled(pwm)) { pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE); return 0; }
and another one for !from_resume.
+static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)+{
- return __pwm_lpss_apply(chip, pwm, state, false);
+}
...
ret = __pwm_lpss_apply(&lpwm->chip, pwm, &saved_state, true);if (ret)dev_err(dev, "Error restoring state on resume\n");
I'm wondering if it's a real error why we do not bail out? Otherwise dev_warn() ?