| Message ID | 20240819080412.15115-1-raag.jadav@intel.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [v1] pwm: lpss: wait_for_update() before configuring pwm | expand |
On Mon, Aug 19, 2024 at 01:34:12PM +0530, Raag Jadav wrote: > Wait for SW_UPDATE bit to clear before configuring pwm channel instead of PWM > failing right away, which will reduce failure rates on early access. So, what is the problem this patch solves (or is trying to solve)? Second, there are two important behavioural changes: - error code change (it's visible to user space); - an additional, quite a long by the way, timeout. Second one does worry me a lot as it might add these 0.5s to the boot time or so per PWM in question.
On Mon, Aug 19, 2024 at 11:21:51AM +0300, Andy Shevchenko wrote: > On Mon, Aug 19, 2024 at 01:34:12PM +0530, Raag Jadav wrote: > > Wait for SW_UPDATE bit to clear before configuring pwm channel instead of > > PWM > > > failing right away, which will reduce failure rates on early access. > > So, what is the problem this patch solves (or is trying to solve)? Less failures with less code, so just a minor improvement. > Second, there are two important behavioural changes: > - error code change (it's visible to user space); This function is already used in this path just a few lines below. > - an additional, quite a long by the way, timeout. > > Second one does worry me a lot as it might add these 0.5s to the boot time > or so per PWM in question. On the contrary, having a working set of PWMs would be a relatively rewarding experience IMHO. Raag
On Tue, Aug 20, 2024 at 08:50:20AM +0300, Raag Jadav wrote: > On Mon, Aug 19, 2024 at 11:21:51AM +0300, Andy Shevchenko wrote: > > On Mon, Aug 19, 2024 at 01:34:12PM +0530, Raag Jadav wrote: > > > Wait for SW_UPDATE bit to clear before configuring pwm channel instead of > > > > PWM > > > > > failing right away, which will reduce failure rates on early access. > > > > So, what is the problem this patch solves (or is trying to solve)? > > Less failures with less code, so just a minor improvement. It's not an equivalent code as I mentioned below. So, if it's just a "cleanup", I do not think we want it as code works now and have no penalties. > > Second, there are two important behavioural changes: > > - error code change (it's visible to user space); > > This function is already used in this path just a few lines below. Yes, I know, but it is used in a slightly different context. > > - an additional, quite a long by the way, timeout. > > > > Second one does worry me a lot as it might add these 0.5s to the boot time > > or so per PWM in question. > > On the contrary, having a working set of PWMs would be a relatively > rewarding experience IMHO. I'm not sure what this patch tries to fix. Was something not working before? Was something become different on real hardware that makes this patch worth to apply? None of these questions has been answered in the commit message. So, as long as this is considered a pure cleanup, here is formal NAK from me as this IP block is not stateless and may lead to freezes. Hence the rule of thumb "do not touch the working things". Otherwise, please make the commit message crystal clear about the improvements besides the code lines and answer the questions, e.g., why waiting for half a second is not an issue.
On Tue, Aug 20, 2024 at 12:56:04PM +0300, Andy Shevchenko wrote: > On Tue, Aug 20, 2024 at 08:50:20AM +0300, Raag Jadav wrote: > > On Mon, Aug 19, 2024 at 11:21:51AM +0300, Andy Shevchenko wrote: > > > On Mon, Aug 19, 2024 at 01:34:12PM +0530, Raag Jadav wrote: > > > > Wait for SW_UPDATE bit to clear before configuring pwm channel instead of > > > > > > PWM > > > > > > > failing right away, which will reduce failure rates on early access. > > > > > > So, what is the problem this patch solves (or is trying to solve)? > > > > Less failures with less code, so just a minor improvement. > > It's not an equivalent code as I mentioned below. > So, if it's just a "cleanup", I do not think we want it as code works now and > have no penalties. > > > > Second, there are two important behavioural changes: > > > - error code change (it's visible to user space); > > > > This function is already used in this path just a few lines below. > > Yes, I know, but it is used in a slightly different context. > > > > - an additional, quite a long by the way, timeout. > > > > > > Second one does worry me a lot as it might add these 0.5s to the boot time > > > or so per PWM in question. > > > > On the contrary, having a working set of PWMs would be a relatively > > rewarding experience IMHO. > > I'm not sure what this patch tries to fix. Was something not working before? > Was something become different on real hardware that makes this patch worth to > apply? None of these questions has been answered in the commit message. > > So, as long as this is considered a pure cleanup, here is formal NAK from me as > this IP block is not stateless and may lead to freezes. Hence the rule of thumb > "do not touch the working things". Fair enough. However, I was able to test it on Merrifield, Bay Trail and Broxton (both PCI and platform counterparts) without such problems, if it is helpful in any way. Raag
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c index 867e2bc8c601..4a634a43b133 100644 --- a/drivers/pwm/pwm-lpss.c +++ b/drivers/pwm/pwm-lpss.c @@ -111,16 +111,6 @@ static int pwm_lpss_wait_for_update(struct pwm_device *pwm) return err; } -static inline int pwm_lpss_is_updating(struct pwm_device *pwm) -{ - if (pwm_lpss_read(pwm) & PWM_SW_UPDATE) { - dev_err(pwmchip_parent(pwm->chip), "PWM_SW_UPDATE is still set, skipping update\n"); - return -EBUSY; - } - - return 0; -} - static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm, int duty_ns, int period_ns) { @@ -168,7 +158,7 @@ static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm, { int ret; - ret = pwm_lpss_is_updating(pwm); + ret = pwm_lpss_wait_for_update(pwm); if (ret) return ret;
Wait for SW_UPDATE bit to clear before configuring pwm channel instead of failing right away, which will reduce failure rates on early access. Signed-off-by: Raag Jadav <raag.jadav@intel.com> --- drivers/pwm/pwm-lpss.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-)