Re: [PATCH RESEND] pwm: th1520: Remove requirement for mul_u64_u64_div_u64_roundup

[Michal Wilczynski]

On 5/30/26 12:41, Maurice Hieronymus wrote:
>>
>> Apologies, I have to correct my statement from before after
>> discussing
> No worries!
>> with Uwe. The reason the macro was used in the mentioned driver is
>> NOT
>> that PWM controllers have 64-bit registers - Uwe isn't aware of that
>> being a real pattern either, and I was inferring it from the code
>> rather
>> than from hardware reality. The actual reason the macros get used
>> isn't
>> unified across drivers and we should pin that down separately rather
>> than block your patch on it.
>>
>> So please hold off on the Rust helper for now - your initial patch
>> might
>> be the right direction.
>>
> Is there any further conclusion which direction is right? Can we merge
> my patch, does it need some change or are we going down the road with
> the Rust helpers?

I think this patch is fine to move forward.

We were wondering if there would be any noticeable difference in
execution speed between the 64-bit computations and the mixed
32-bit/64-bit computations. I ran a profile on the platform, and the
performance with and without the patch is identical:

Here's the test I ran

WITH PATCH
# hyperfine --warmup 2 --runs 40 './pwmtestperf'                                                                                                                    
  Time (mean ± σ):      3.370 s ±  0.069 s    [User: 0.069 s, System: 3.313 s]
  Range (min … max):    3.271 s …  3.547 s    40 runs
 
WITHOUT PATCH
# hyperfine --warmup 2 --runs 40 './pwmtestperf
  Time (mean ± σ):      3.368 s ±  0.051 s    [User: 0.058 s, System: 3.326 s]
  Range (min … max):    3.278 s …  3.516 s    40 runs

The delta is completely within the margin of error, confirming that
64-bit math is just as fast as 32-bit math on this architecture under
standard loads. It is worth mentioning that to get a more meaningful
performance measurement, pwmtestperf would probably need to be modified
to stress this specific code path much more heavily.

That said, fitting it into 32-bit where appropriate makes perfect sense
from a code quality perspective.

Reviewed-by: Michal Wilczynski <m.wilczynski@xxxxxxxxxxx>

> 
> Thanks!
> 
> Maurice
>>>
>>> Maurice
>>>
>>
>> Best regards,
>