Hello Baruch, On Tue, Jan 25, 2022 at 06:22:45PM +0200, Baruch Siach wrote: > On Tue, Jan 25 2022, Uwe Kleine-König wrote: > > On Tue, Jan 25, 2022 at 03:03:08PM +0200, Baruch Siach wrote: > >> On Wed, Jan 19 2022, Uwe Kleine-König wrote: > >> > The task here is to calculate the biggest pwm_div for a given pre_div > >> > such that > >> > > >> > > >> > (pre_div + 1) * (pwm_div + 1) * NSEC_PER_SEC > >> > -------------------------------------------- <= period_ns > >> > rate > >> > > >> > right? > >> > > >> > This is equivalent to: > >> > > >> > period_ns * rate > >> > pre_div <= ---------------------------- - 1 > >> > (pre_div + 1) * NSEC_PER_SEC > >> > > >> > As pre_div is integer, rounding down should be fine?! > >> > >> I can't follow. With round down (as in v8) the result is always: > >> > >> NSEC_PER_SEC * (pre_div + 1) * (pwm_div + 1) <= period_rate > > > > Yes, that's the condition that a valid configuration should fulfill > > because then the configured period is never bigger than the requested > > period. > > > >> As a result, 'diff' calculation below will always produce diff <= 0. When > >> there is no diff == 0 result (bingo) we get IPQ_PWM_MAX_DIV in both best_ > >> values at the end of the loop. > > > > Looking again, your check is wrong. I think you need: > > > > diff = period_rate - NSEC_PER_SEC * (pre_div + 1) * (pwm_div + 1) > > > > . Given the calculations for pre_div and pwm_div this should never be > > negative and you should pick values that minimize diff. > > So, if I understand correctly, you suggest to leave round up as in v10, > and invert the diff calculation. Is that correct? If you agree that this results in the intended setting and keeps dmesg clean even with PWM_DEBUG enabled: yes. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
