On Fri Jul 11, 2025 at 4:50 PM CEST, Uwe Kleine-König wrote: > Hello Mathieu, > > On Fri, Jul 11, 2025 at 11:29:44AM +0200, Mathieu Dubois-Briand wrote: >> diff --git a/drivers/pwm/pwm-max7360.c b/drivers/pwm/pwm-max7360.c >> new file mode 100644 >> index 000000000000..0eb83135f658 >> --- /dev/null >> +++ b/drivers/pwm/pwm-max7360.c >> @@ -0,0 +1,193 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Copyright 2025 Bootlin >> + * >> + * Author: Kamel BOUHARA <kamel.bouhara@xxxxxxxxxxx> >> + * Author: Mathieu Dubois-Briand <mathieu.dubois-briand@xxxxxxxxxxx> >> + * > > A link to the data sheet here would be awesome. I found it at > > https://www.analog.com/media/en/technical-documentation/data-sheets/MAX7360.pdf > Sure, I will add the link. >> [...] >> +static int max7360_pwm_round_waveform_tohw(struct pwm_chip *chip, >> + struct pwm_device *pwm, >> + const struct pwm_waveform *wf, >> + void *_wfhw) >> +{ >> + struct max7360_pwm_waveform *wfhw = _wfhw; >> + u64 duty_steps; >> + >> + /* >> + * Ignore user provided values for period_length_ns and duty_offset_ns: >> + * we only support fixed period of MAX7360_PWM_PERIOD_NS and offset of 0. >> + */ >> + if (wf->duty_length_ns >= MAX7360_PWM_PERIOD_NS) >> + duty_steps = MAX7360_PWM_MAX_RES; >> + else >> + duty_steps = (u32)wf->duty_length_ns * MAX7360_PWM_MAX_RES / MAX7360_PWM_PERIOD_NS; > > I read through the data sheet and I think the right formula for > duty_steps is: > > if (wf->duty_length_ns >= MAX7360_PWM_PERIOD_NS) { > duty_steps = 255; > } else { > duty_steps = (u32)wf->duty_length_ns * 256 / MAX7360_PWM_PERIOD_NS; > if (duty_steps == 255) > duty_steps = 254; > } > > (Using magic constants here, but in the end these should be cpp symbols > of course.) > >> + wfhw->duty_steps = min(MAX7360_PWM_MAX_RES, duty_steps); >> + wfhw->enabled = !!wf->period_length_ns; >> + >> + return 0; >> +} >> + >> +static int max7360_pwm_round_waveform_fromhw(struct pwm_chip *chip, struct pwm_device *pwm, >> + const void *_wfhw, struct pwm_waveform *wf) >> +{ >> + const struct max7360_pwm_waveform *wfhw = _wfhw; >> + >> + wf->period_length_ns = wfhw->enabled ? MAX7360_PWM_PERIOD_NS : 0; >> + wf->duty_offset_ns = 0; >> + >> + if (wfhw->enabled) >> + wf->duty_length_ns = DIV_ROUND_UP(wfhw->duty_steps * MAX7360_PWM_PERIOD_NS, >> + MAX7360_PWM_MAX_RES); >> + else >> + wf->duty_length_ns = 0; > > The matching code here is: > > if (wfhw->duty_steps == 255) > wf->duty_length_ns = MAX7360_PWM_PERIOD_NS; > else > wf->duty_length_ns = DIV_ROUND_UP(wfhw->duty_steps * MAX7360_PWM_PERIOD_NS, 256) > > This is arguably a strange design, but f_OSC = 128 kHz and the fixed > period being 2 ms is a strong indication that the divider is 256 and not > 255. If you don't agree to the manual (e.g. because you measured the > output and saw your formula to be true), please add a code comment about > that. > Yes, I did a few measurements, and you are right. I'm fixing the code as you described. > When you have measureing equipment at hand it would be great if you > could verify that the right fromhw implementation isn't: > > wf->duty_length_ns = DIV_ROUND_UP(wfhw->duty_steps * MAX7360_PWM_PERIOD_NS, 256) > > even for wfhw->duty_steps == 255. (Which would mean that the PWM cannot > provide a 100% duty cycle.) > No, I confirm, values from 0 to 254 provide a duty cycle from 0 to 254/256. A value of 255 provides a 100% duty cycle. >> +static int max7360_pwm_probe(struct platform_device *pdev) >> +{ >> + struct device *dev = &pdev->dev; >> + struct pwm_chip *chip; >> + struct regmap *regmap; >> + int ret; >> + >> + regmap = dev_get_regmap(dev->parent, NULL); >> + if (!regmap) >> + return dev_err_probe(dev, -ENODEV, "could not get parent regmap\n"); >> ... >> + >> + ret = devm_pwmchip_add(dev, chip); >> + if (ret) >> + return dev_err_probe(dev, ret, "failed to add PWM chip\n"); > > Please start error messages with a capital letter. > Fixed, thanks. > Best regards > Uwe Thanks for your review, Mathieu -- Mathieu Dubois-Briand, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
