Devicetree
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <ukleinek@kernel.org>
To: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>, Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	 Chris Packham <chris.packham@alliedtelesis.co.nz>,
	Andrew Morton <akpm@linux-foundation.org>,
	 "Darrick J. Wong" <djwong@us.ibm.com>,
	linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
	 linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org
Subject: Re: [hwmon-next PATCH v4 3/4] hwmon: (adt7470) Expose fan control via PWM framework
Date: Wed, 29 Jul 2026 23:34:37 +0200	[thread overview]
Message-ID: <ampxIhULPHehuh-W@monoceros> (raw)
In-Reply-To: <CAJq09z5diKf9HpJ0B_7tyo2-2wPfojyG4pRY1qhRQ3fzx0Gr4A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

Hello Luiz,

On Wed, Jul 29, 2026 at 04:05:56PM -0300, Luiz Angelo Daros de Luca wrote:
> > Here the right thing is (untested):
> >
> >         if (!wf->period_length_ns) {
> >                 wfhw->val = 0;
> >                 return 0;
> >         }
> >
> >         actual_period = NSEC_PER_SEC / data->pwm_freq;
> >
> >         if (wf->duty_length_ns >= actual_period)
> >                 val = ADT7470_PWM_MAX;
> >         else
> >                 val = mul_u64_u64_div_u64(wf->duty_length_ns, ADT7470_PWM_MAX, actual_period);
> >
> >         return (actual_period < wf->period_length_ns) ? 0 : 1;
> 
> Uwe, thank you for the waveform callbacks snippet. It was much
> cleaner. I only had to make one small mathematical adjustment to the
> actual_period calculation in tohw() to satisfy CONFIG_PWM_DEBUG.
> 
> When using a truncating division (NSEC_PER_SEC / data->pwm_freq), it
> triggered a "Wrong rounding" error during testing:
> 
> pwm pwmchip0: Wrong rounding: requested 714285/714286 [+0], result
> 714286/714286 [+0]
> 
> For example, at 1400 Hz, the truncating division gives an
> actual_period of 714285 ns. If the framework requests a duty cycle of
> 714285 ns and a period of 714286 ns, the evaluation (714285 * 255) /
> 714285 yields a register value of 255. When read back in fromhw()
> (which correctly rounds the period up to 714286 ns), the resulting
> duty cycle becomes 714286 ns. Since 714286 > 714285, CONFIG_PWM_DEBUG
> rightfully complains about the duty cycle inflation.
> 
> To ensure the calculated register value is strictly rounded down, I
> changed the actual_period denominator in tohw() to use
> DIV_ROUND_UP_ULL(NSEC_PER_SEC, data->pwm_freq). Maximizing the
> denominator guarantees the resulting duty cycle fraction never
> inflates, effectively passing all strict debug checks.

right, for the calculation of actual_period an uprounding division must
be used.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2026-07-29 21:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29  4:46 [hwmon-next PATCH v4 0/4] hwmon: (adt7470) Add PWM provider and thermal sensor support Luiz Angelo Daros de Luca
2026-07-29  4:46 ` [hwmon-next PATCH v4 1/4] dt-bindings: hwmon: add adi,adt7470 Luiz Angelo Daros de Luca
2026-07-29  4:49   ` sashiko-bot
2026-07-29  4:46 ` [hwmon-next PATCH v4 2/4] hwmon: (adt7470) Add ADT7470_PWM_MAX macro Luiz Angelo Daros de Luca
2026-07-29  4:51   ` sashiko-bot
2026-07-29  4:46 ` [hwmon-next PATCH v4 3/4] hwmon: (adt7470) Expose fan control via PWM framework Luiz Angelo Daros de Luca
2026-07-29  5:00   ` sashiko-bot
2026-07-29  5:56   ` Guenter Roeck
2026-07-29 11:49     ` Uwe Kleine-König
2026-07-29 14:22       ` Guenter Roeck
2026-07-29 19:05         ` Luiz Angelo Daros de Luca
2026-07-29 20:23           ` Guenter Roeck
2026-07-29 21:34           ` Uwe Kleine-König [this message]
2026-07-29 11:47   ` Uwe Kleine-König
2026-07-29  4:46 ` [hwmon-next PATCH v4 4/4] hwmon: (adt7470) Add thermal zone sensor support Luiz Angelo Daros de Luca
2026-07-29  5:03   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ampxIhULPHehuh-W@monoceros \
    --to=ukleinek@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=djwong@us.ibm.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=luizluca@gmail.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox