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.
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
Changes in v6:
- Add a pwm_lpss_restore_state() helper for re-applying the PWM state on resume
Changes in v5:
- The changes to pwm_lpss_apply() are much cleaner now thanks to the new
pwm_lpss_prepare_enable() helper.
Changes in v3:
- This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM"
patch from previous versions of this patch-set, which really was a hack
working around the resume issue which this patch fixes properly.
---
drivers/pwm/pwm-lpss.c | 49 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 8a136ba2a583..d77869be053c 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -166,6 +166,24 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
return ret;
}
+/*
+ * This is a mirror of pwm_lpss_apply() without pm_runtime reference handling
+ * for restoring the PWM state on resume.
+ */
+static int pwm_lpss_restore_state(struct pwm_lpss_chip *lpwm,
+ struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ int ret = 0;
+
+ if (state->enabled)
+ ret = pwm_lpss_prepare_enable(lpwm, pwm, state,
!pwm_is_enabled(pwm));
+ else if (pwm_is_enabled(pwm))
+ pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
+
+ return ret;
+}
+
static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state)
{
@@ -278,10 +296,35 @@ EXPORT_SYMBOL_GPL(pwm_lpss_suspend);
int pwm_lpss_resume(struct device *dev)
{
struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
- int i;
+ struct pwm_state saved_state;
+ struct pwm_device *pwm;
+ int i, ret;
+ u32 ctrl;
- for (i = 0; i < lpwm->info->npwm; i++)
- writel(lpwm->saved_ctrl[i], lpwm->regs + i * PWM_SIZE + PWM);
+ for (i = 0; i < lpwm->info->npwm; i++) {
+ pwm = &lpwm->chip.pwms[i];
+
+ ctrl = pwm_lpss_read(pwm);
+ /* If we did not reach S0i3/S3 the controller keeps its state */
+ if (ctrl == lpwm->saved_ctrl[i])
+ continue;
+
+ /*
+ * We cannot just blindly restore the old value here. Since we
+ * are changing the settings we must set SW_UPDATE and 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.
+ */
+ saved_state = pwm->state;
+ /* Update enabled to its actual setting after resume */
+ pwm->state.enabled = !!(ctrl & PWM_ENABLE);
+ ret = pwm_lpss_restore_state(lpwm, pwm, &saved_state);
+ if (ret)
+ dev_err(dev, "Error restoring state on resume\n");
+ }
return 0;
}
--
2.28.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
