Hello Uwe, Thanks for the explain, now i can understand it better.So, if redefining period and duty as u64 in gb_pwm_config_request is an acceptable solution, i will send patch v2.
BR Song 在 2022/2/11 15:16, Uwe Kleine-König 写道:
Hello , On Fri, Feb 11, 2022 at 11:06:33AM +0800, Song Chen wrote:在 2022/2/10 18:03, Uwe Kleine-König 写道:On Thu, Feb 10, 2022 at 05:05:02PM +0800, Song Chen wrote:Introduce apply in pwm_ops to replace legacy operations, like enable, disable, config and set_polarity. Signed-off-by: Song Chen <chensong_2000@xxxxxx> --- drivers/staging/greybus/pwm.c | 46 +++++++++++++++-------------------- 1 file changed, 19 insertions(+), 27 deletions(-) diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c index 891a6a672378..e1889cf979b2 100644 --- a/drivers/staging/greybus/pwm.c +++ b/drivers/staging/greybus/pwm.c @@ -204,43 +204,35 @@ static void gb_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm) gb_pwm_deactivate_operation(pwmc, pwm->hwpwm); } -static int gb_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, - int duty_ns, int period_ns) -{ - struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip); - - return gb_pwm_config_operation(pwmc, pwm->hwpwm, duty_ns, period_ns); -}; - -static int gb_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm, - enum pwm_polarity polarity) +static int gb_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, + const struct pwm_state *state) { + int ret; struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip); - return gb_pwm_set_polarity_operation(pwmc, pwm->hwpwm, polarity); -}; - -static int gb_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm) -{ - struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip); + /* set period and duty cycle*/ + ret = gb_pwm_config_operation(pwmc, pwm->hwpwm, state->duty_cycle, state->period);gb_pwm_config_operation's 3rd parameter is an u32, so you're loosing bits here as state->duty_cycle is a u64. Ditto for period.originally, pwm_apply_state --> pwm_apply_legacy --> gb_pwm_config --> gb_pwm_config_operation is also loosing bits, does it mean greybus can live with that?This is true, I tried to address that, but Thierry had concerns. (https://lore.kernel.org/all/20210312212119.1342666-1-u.kleine-koenig@xxxxxxxxxxxxxx/ was the patch I suggested.)Or redefine gb_pwm_config_request, switch duty and period to __le64?Don't use __le64, this is only for representing (little endian) register values. u64 would be the right one.Also it would be nice if you go from .duty_cycle = A, .period = B, .enabled = 1 to .duty_cycle = C, .period = D, .enabled = 0 that C/D wasn't visible on the output pin. So please disable earlier (but keep enable at the end).sorry, i don't quite understand this part,To reexplain: If your hardware is configured for .duty_cycle = A, .period = B, .enabled = 1 and pwm_apply is called with .duty_cycle = C, .period = D, .enabled = 0 you configured the registers for .duty_cycle and .period first and only then disable the PWM. This usually results in glitches because the hardware shortly runs with .duty_cycle = C, .period = D, .enabled = 1 . So the idea is, to disable before configuring duty and period if the eventual goal is a disabled state.
understood, thanks.
but is below code looking good to you? static int gb_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, const struct pwm_state *state) { int err; bool enabled = pwm->state.enabled; struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip); /* set polarity */ if (state->polarity != pwm->state.polarity) { if (enabled) { gb_pwm_disable_operation(pwmc, pwm->hwpwm); enabled = false; } err = gb_pwm_set_polarity_operation(pwmc, pwm->hwpwm, state->polarity); if (err) return err; } if (!state->enabled) { if (enabled) gb_pwm_disable_operation(pwmc, pwm->hwpwm); return 0; } /* set period and duty cycle*/ err = gb_pwm_config_operation(pwmc, pwm->hwpwm, state->duty_cycle, state->period); if (err) return err; /* enable/disable */ if (!enabled) return gb_pwm_enable_operation(pwmc, pwm->hwpwm); return 0; }This looks good. Best regards Uwe
_______________________________________________ greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx
|