Re: [PATCH v2 2/7] pwm: Add Rust driver for T-HEAD TH1520 SoC

[Uwe Kleine-König]

Hello Michael,

On Thu, Jun 12, 2025 at 10:14:13AM +0200, Michal Wilczynski wrote:
> On 6/11/25 08:58, Uwe Kleine-König wrote:
> > Huh, if you do the newstyle stuff, .get_state() is wrong. It's either
> > .round_waveform_tohw() + .round_waveform_fromhw() + .read_waveform() +
> > .write_waveform() or .apply() + .get_state(), but don't mix these.
> 
> In the process of implementing the full "newstyle" waveform API as you
> suggested, I discovered a hardware limitation. After writing new values
> to the period and duty cycle registers, reading them back does not
> return the programmed values, which makes it impossible to reliably
> report the current hardware state.
> 
> This appears to be a known quirk of the hardware, as the reference C
> driver from T-HEAD [1] also omits the .get_state callback, likely for
> the same reason.

Do you read complete non-sense or e.g. the old configuration until
the current period ends?

I guess would be that .get_state wasn't implemented because this is an
oldoldstyle driver and it works also without that function.

> Given this, would it be acceptable to provide a write-only driver? My
> proposed solution would be to omit the .read_waveform() and
> .round_waveform_fromhw() implementations from my PwmOps trait. This

Please don't skip .round_waveform_fromhw(), that one is needed for
pwm_round_waveform_might_sleep().

I don't like it, but given that the hardware doesn't play along there is
no alternative.

> would mean the driver can correctly set the PWM state, but attempting to
> read it back via sysfs would fail (e.g., with -EOPNOTSUPP), reflecting
> the hardware's capability.

I think there might be another patch opportunity then to make PWM_DEBUG
work with that.

Best regards
Uwe

Attachment: signature.asc
Description: PGP signature