pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state
Before this commit pwm_lpss_apply() was 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, these 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 not 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. Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-7-hdegoede@redhat.com
Showing
Please register or sign in to comment