Re: [PATCH v11 04/10] pwm: max7360: Add MAX7360 PWM support

["Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com>]

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@bootlin.com>
>> + * Author: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
>> + *
>
> 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