| Message ID | 20200903105114.9969-7-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API | expand |
On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote: > Before this commit pwm_lpss_apply() was making 2 assuming > 2 pre-conditions were met by the existing hardware state: I think that "making 2" is too much. > > 1. That the base-unit and on-time-div read back from the > control register are those actually in use, so that it > can skip setting the update bit if the read-back value > matches the desired values. > > 2. That the controller is enabled when the cached > pwm_state.enabled says that the controller is enabled. > > As the long history of fixes for subtle (often suspend/resume) > lpss-pwm issues shows, this assumptions are not necessary > always true. > > 1. Specifically is not true on some (*) Cherry Trail devices > with a nasty GFX0._PS3 method which: a. saves the ctrl reg value. > b. sets the base-unit to 0 and writes the update bit to apply/commit > c. restores the original ctrl value without setting the update bit, > so that the 0 base-unit value is still in use. > > 2. Assumption 2. currently is true, but only because of the code which > saves/restores the state on suspend/resume. By convention restoring the > PWM state should be done by the PWM consumer and the presence of this > code in the pmw-lpss driver is a bug. Therefor the save/restore code will > be dropped in the next patch in this series, after which this assumption > also is no longer true. > > This commit changes the pwm_lpss_apply() to make any assumptions about the Did you mean to say "... to _not_ make any assumptions ..."? > state the hardware is in. Instead it makes pwm_lpss_apply() always fully > program the PWM controller, making it much less fragile. > > *) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models > and various Medion models. > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > drivers/pwm/pwm-lpss.c | 21 +++++++++------------ > 1 file changed, 9 insertions(+), 12 deletions(-) Other than the two small nits, this looks much more idiomatic and true to the atomic API, so: Acked-by: Thierry Reding <thierry.reding@gmail.com>
Hi, On 9/3/20 12:59 PM, Thierry Reding wrote: > On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote: >> Before this commit pwm_lpss_apply() was making 2 assuming >> 2 pre-conditions were met by the existing hardware state: > > I think that "making 2" is too much. You're right at first the sentence had something about making 2 assumptions, then I added pre-conditions in there for it to better describe the problem... >> 1. That the base-unit and on-time-div read back from the >> control register are those actually in use, so that it >> can skip setting the update bit if the read-back value >> matches the desired values. >> >> 2. That the controller is enabled when the cached >> pwm_state.enabled says that the controller is enabled. >> >> As the long history of fixes for subtle (often suspend/resume) >> lpss-pwm issues shows, this assumptions are not necessary >> always true. >> >> 1. Specifically is not true on some (*) Cherry Trail devices >> with a nasty GFX0._PS3 method which: a. saves the ctrl reg value. >> b. sets the base-unit to 0 and writes the update bit to apply/commit >> c. restores the original ctrl value without setting the update bit, >> so that the 0 base-unit value is still in use. >> >> 2. Assumption 2. currently is true, but only because of the code which >> saves/restores the state on suspend/resume. By convention restoring the >> PWM state should be done by the PWM consumer and the presence of this >> code in the pmw-lpss driver is a bug. Therefor the save/restore code will >> be dropped in the next patch in this series, after which this assumption >> also is no longer true. >> >> This commit changes the pwm_lpss_apply() to make any assumptions about the > > Did you mean to say "... to _not_ make any assumptions ..."? Yes, oops. That is a small but important difference. I'll do a v10 with your 2 Acked-by's added and both commit msg issues fixed. Hopefully that will be the last version. >> state the hardware is in. Instead it makes pwm_lpss_apply() always fully >> program the PWM controller, making it much less fragile. >> >> *) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models >> and various Medion models. >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> drivers/pwm/pwm-lpss.c | 21 +++++++++------------ >> 1 file changed, 9 insertions(+), 12 deletions(-) > > Other than the two small nits, this looks much more idiomatic and true > to the atomic API, so: > > Acked-by: Thierry Reding <thierry.reding@gmail.com> Thank you. Regards, Hans
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c index 8a136ba2a583..9c5c7217c9b6 100644 --- a/drivers/pwm/pwm-lpss.c +++ b/drivers/pwm/pwm-lpss.c @@ -85,7 +85,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm, unsigned long long on_time_div; unsigned long c = lpwm->info->clk_rate, base_unit_range; unsigned long long base_unit, freq = NSEC_PER_SEC; - u32 orig_ctrl, ctrl; + u32 ctrl; do_div(freq, period_ns); @@ -104,16 +104,14 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm, do_div(on_time_div, period_ns); on_time_div = 255ULL - on_time_div; - orig_ctrl = ctrl = pwm_lpss_read(pwm); + ctrl = pwm_lpss_read(pwm); ctrl &= ~PWM_ON_TIME_DIV_MASK; ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT); ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT; ctrl |= on_time_div; - if (orig_ctrl != ctrl) { - pwm_lpss_write(pwm, ctrl); - pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE); - } + pwm_lpss_write(pwm, ctrl); + pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE); } static inline void pwm_lpss_cond_enable(struct pwm_device *pwm, bool cond) @@ -124,8 +122,7 @@ static inline void pwm_lpss_cond_enable(struct pwm_device *pwm, bool cond) static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm, - const struct pwm_state *state, - bool enable) + const struct pwm_state *state) { int ret; @@ -134,12 +131,12 @@ static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm, return ret; pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period); - pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false); + pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false); ret = pwm_lpss_wait_for_update(pwm); if (ret) return ret; - pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true); + pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true); return 0; } @@ -152,11 +149,11 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm, if (state->enabled) { if (!pwm_is_enabled(pwm)) { pm_runtime_get_sync(chip->dev); - ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true); + ret = pwm_lpss_prepare_enable(lpwm, pwm, state); if (ret) pm_runtime_put(chip->dev); } else { - ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false); + ret = pwm_lpss_prepare_enable(lpwm, pwm, state); } } else if (pwm_is_enabled(pwm)) { pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
Before this commit pwm_lpss_apply() was making 2 assuming 2 pre-conditions were met by the existing hardware state: 1. That the base-unit and on-time-div read back from the control register are those actually in use, so that it can skip setting the update bit if the read-back value matches the desired values. 2. That the controller is enabled when the cached pwm_state.enabled says that the controller is enabled. As the long history of fixes for subtle (often suspend/resume) lpss-pwm issues shows, this assumptions are not necessary always true. 1. Specifically is not true on some (*) Cherry Trail devices with a nasty GFX0._PS3 method which: a. saves the ctrl reg value. b. sets the base-unit to 0 and writes the update bit to apply/commit c. restores the original ctrl value without setting the update bit, so that the 0 base-unit value is still in use. 2. Assumption 2. currently is true, but only because of the code which saves/restores the state on suspend/resume. By convention restoring the PWM state should be done by the PWM consumer and the presence of this code in the pmw-lpss driver is a bug. Therefor the save/restore code will be dropped in the next patch in this series, after which this assumption also is no longer true. This commit changes the pwm_lpss_apply() to make any assumptions about the state the hardware is in. Instead it makes pwm_lpss_apply() always fully program the PWM controller, making it much less fragile. *) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models and various Medion models. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/pwm/pwm-lpss.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-)