[PATCH v1] pwm: lpss: wait_for_update() before configuring pwm

[PATCH v1] pwm: lpss: wait_for_update() before configuring pwm

[Raag Jadav]

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(-)

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;
 
-- 
2.35.3

Re: [PATCH v1] pwm: lpss: wait_for_update() before configuring pwm

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1] pwm: lpss: wait_for_update() before configuring pwm

[Raag Jadav]

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

Re: [PATCH v1] pwm: lpss: wait_for_update() before configuring pwm

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1] pwm: lpss: wait_for_update() before configuring pwm

[Raag Jadav]

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