Re: [PATCH v6 4/6] pwm: tiehrpwm: implement .get_state callback

["Rafael V. Volkmer" <rafael.v.volkmer@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

Hi Uwe,

On Mon, 24 Nov 2025 17:51:47 +0100, Uwe Kleine-König wrote:
> Note this is wrong as pwm_get_state() only yields the last request but
> not the actual hardware setting.

You’re right about the misleading wording in the commit log:
pwm_get_state() returns the last requested state, not a live snapshot of
the hardware. In the next revision I’ll rephrase the description so it’s
clear that ehrpwm_get_state() is only used to initialize pwm->state from
the current eHRPWM registers when the PWM is first requested.

I’ll also address the other points you mentioned in this series.

> A superior improvement over implementing .get_state() is implementing the
> new callbacks round_waveform_tohw, round_waveform_fromhw, read_waveform
> and write_waveform. And bonus points if you also implement offset
> support.

I like this suggestion and would be interested in doing it for tiehrpwm,
but for now I’d prefer to keep this series limited to the smaller
cleanups, the get_state() implementation and the probe changes, so the
scope stays manageable. My current plan would be to first send a new
revision with those pieces, and then follow up with a separate series
that converts tiehrpwm to round_waveform_tohw / round_waveform_fromhw
plus read_waveform / write_waveform and adds offset support.

From my reading of the PWM core, it seems acceptable for a driver to
provide both the legacy apply/get_state callbacks and the waveform
callbacks, with the logic factored so that they share
the same hardware decoding. If you’d strongly prefer that tiehrpwm is
converted directly to waveform without an intermediate get_state()
series, I can rework the patches in that direction instead.

Best regards,
Rafael V. Volkmer