[PATCH] regulator: rpi-panel-v2: Convert to new PWM waveform ops

Uwe Kleine-König ukleinek at kernel.org
Tue Jun 17 07:13:23 PDT 2025


Hello Marek,

On Tue, Jun 17, 2025 at 11:38:50AM +0200, Marek Vasut wrote:
> On 6/17/25 10:14 AM, Uwe Kleine-König wrote:
> 
> Hi,
> 
> [...]
> 
> > /* The actual value isn't known, so this is made up. */
> > #define RPI_PANEL_V2_FIXED_PERIOD_NS 100000
> > 
> > 
> > static int rpi_panel_v2_pwm_round_waveform_tohw(...)
> > {
> > 	...
> > 
> > 	if (wf->duty_length_ns > RPI_PANEL_V2_FIXED_PERIOD_NS)
> > 		*wfhw = 100;
> > 	else
> > 		*wfhw = mul_u64_u64_div_u64(wf->duty_length_ns * 100, RPI_PANEL_V2_FIXED_PERIOD_NS);
> > 
> > 	return 0;
> > }
> 
> This fixed period specified in driver has one problem -- what if the period
> is also specified in DT by the consumer, e.g. pwm-backlight pwms property,
> and it does not match RPI_PANEL_V2_FIXED_PERIOD_NS ?

If it's off by only a little amount you will hardly notice. If it's
further off that's less optimal. I don't think this is a problem. If the
device tree is wrong, the machine doesn't work optimally. That's quite
expected.

> This is easy to solve for this tohw function, but what about the fromhw
> which assigns period_ns ?

If you only write waveforms to the hardware (probably using
pwm_apply_might_sleep()), the fromhw callback isn't involved (apart from
debugging). And all fromhw callbacks are supposed to assign
period_length_ns. I suspect we don't have the same understanding of the
PWM abstraction.

> > > +static int rpi_panel_v2_pwm_write_waveform(struct pwm_chip *chip,
> > > +					   struct pwm_device *pwm,
> > > +					   const void *_wfhw)
> > > +{
> > > +	struct regmap *regmap = pwmchip_get_drvdata(chip);
> > > +	const u8 *wfhw = _wfhw;
> > > -	duty = pwm_get_relative_duty_cycle(state, PWM_BL_MASK);
> > > -	return regmap_write(regmap, REG_PWM, duty | PWM_BL_ENABLE);
> > > +	return regmap_write(regmap, REG_PWM, *wfhw | (*wfhw ? PWM_BL_ENABLE : 0));
> > 
> > How does the PWM behave without PWM_BL_ENABLE set?
> The display stays dark.

So you cannot distinguish writing `0` (or any other value) and
`PWM_BL_ENABLE | 0` I guess?

I ask because for some hardware's it makes a difference, the output
might e.g go High-Z on disable.

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250617/5583e1c6/attachment.sig>


More information about the linux-arm-kernel mailing list