Re: [PATCH v5 2/2] Add PWM fan controller driver for LGM SoC

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]

On Mon, Jul 27, 2020 at 02:04:56PM +0800, Tanwar, Rahul wrote:
> 
> Hi Uwe,
> 
> On 24/7/2020 12:15 am, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Thu, Jul 23, 2020 at 03:44:18PM +0800, Rahul Tanwar wrote:
> >> +static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> >> +			 const struct pwm_state *state)
> >> +{
> >> +	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
> >> +	u32 duty_cycle, val;
> >> +	int ret;
> >> +
> >> +	if (!state->enabled) {
> >> +		ret = lgm_pwm_enable(chip, 0);
> >> +		return ret;
> >> +	}
> >> +
> >> +	/*
> >> +	 * HW only supports NORMAL polarity
> >> +	 * HW supports fixed period which can not be changed/configured by user
> >> +	 */
> >> +	if (state->polarity != PWM_POLARITY_NORMAL ||
> >> +	    state->period != pc->period)
> >> +		return -EINVAL;
> > At least for state->polarity you have to check before state->enabled, as
> > the expectation on
> >
> >         .enabled = false
> >         .polarity = PWM_POLARITY_INVERSED
> >
> > is that the output becomes constant high. Also as confirmed at the end
> > of v4, state->period < pc->period was the right check to do.
> 
> For below case:
> 
> .enabled = false
> .polarity = PWM_POLARITY_INVERSED
> 
> Since our HW does not support inversed polarity, the output for above case
> is expected to be constant low. And if we disable PWM before checking for
> polarity, the output becomes constant low. The code just does that. Sorry,
> i could not understand what is wrong with the code. It looks correct to me.

As your hardware can only support normal polarity, the code must have:

	if (state->polarity != PWM_POLARITY_NORMAL)
		return -EINVAL;

	if (!state->enabled) {
		ret = lgm_pwm_enable(chip, 0);
		return ret;
	}

That's what I meant writing: "At least for state->polarity you have to
check before state->enabled".

> Given the fact that we support fixed period, if we allow
> state->period < pc->period case then the duty cycle will be evaluated as
> higher than the requested one because the state->period is lesser than
> the actual fixed period supported by the HW. Can you please elaborate
> on why you think we should allow state->period < pc->period case?

You should not allow it. In v4 you had:

	if (state->polarity != PWM_POLARITY_NORMAL ||
	    state->period < pc->period)
		return -EINVAL;

That's the right thing to do (even though I was unsettled at one point
and wrote it was wrong). The check in v5 with state->period !=
pc->period is wrong.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]