[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