From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Ben Dooks <ben.dooks@codethink.co.uk>
Cc: linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Greentime Hu <greentime.hu@sifive.com>,
jarkko.nikula@linux.intel.com
Subject: Re: [PATCH v9 4/6] pwm: dwc: use clock rate in hz to avoid rounding issues
Date: Thu, 7 Sep 2023 23:34:19 +0200 [thread overview]
Message-ID: <20230907213419.aqzwoppznj5tx7w6@pengutronix.de> (raw)
In-Reply-To: <20230907161242.67190-5-ben.dooks@codethink.co.uk>
[-- Attachment #1: Type: text/plain, Size: 4989 bytes --]
Hello,
[Dropped William Salmon and Jude Onyenegecha from the list of recipents,
their email addresses don't seem to work any more.]
On Thu, Sep 07, 2023 at 05:12:40PM +0100, Ben Dooks wrote:
> As noted, the clock-rate when not a nice multiple of ns is probably
> going to end up with inacurate calculations, as well as on a non pci
> system the rate may change (although we've not put a clock rate
> change notifier in this code yet) so we also add some quick checks
> of the rate when we do any calculations with it.
>
> Signed-off-by; Ben Dooks <ben.dooks@codethink.co.uk>
> Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> v9:
> - fixed commit spelling
> - changed to use codethink email instead of sifive
> v8:
> - fixup post rename
> - move to earlier in series
> ---
> drivers/pwm/pwm-dwc-core.c | 24 +++++++++++++++---------
> drivers/pwm/pwm-dwc.h | 2 +-
> 2 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pwm/pwm-dwc-core.c b/drivers/pwm/pwm-dwc-core.c
> index 3fc281a78c9a..3b856685029d 100644
> --- a/drivers/pwm/pwm-dwc-core.c
> +++ b/drivers/pwm/pwm-dwc-core.c
> @@ -49,13 +49,14 @@ static int __dwc_pwm_configure_timer(struct dwc_pwm *dwc,
> * periods and check are the result within HW limits between 1 and
> * 2^32 periods.
> */
> - tmp = DIV_ROUND_CLOSEST_ULL(state->duty_cycle, dwc->clk_ns);
> + tmp = state->duty_cycle * dwc->clk_rate;
This might overflow. You can prevent this by asserting that clk_rate is
<= NSEC_PER_SEC and using mul_u64_u64_div_u64.
> + tmp = DIV_ROUND_CLOSEST_ULL(tmp, NSEC_PER_SEC);
> if (tmp < 1 || tmp > (1ULL << 32))
> return -ERANGE;
> low = tmp - 1;
>
> - tmp = DIV_ROUND_CLOSEST_ULL(state->period - state->duty_cycle,
> - dwc->clk_ns);
> + tmp = (state->period - state->duty_cycle) * dwc->clk_rate;
> + tmp = DIV_ROUND_CLOSEST_ULL(tmp, NSEC_PER_SEC);
> if (tmp < 1 || tmp > (1ULL << 32))
> return -ERANGE;
> high = tmp - 1;
> @@ -121,11 +122,14 @@ static int dwc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> struct pwm_state *state)
> {
> struct dwc_pwm *dwc = to_dwc_pwm(chip);
> + unsigned long clk_rate;
> u64 duty, period;
> u32 ctrl, ld, ld2;
>
> pm_runtime_get_sync(chip->dev);
>
> + clk_rate = dwc->clk_rate;
> +
> ctrl = dwc_pwm_readl(dwc, DWC_TIM_CTRL(pwm->hwpwm));
> ld = dwc_pwm_readl(dwc, DWC_TIM_LD_CNT(pwm->hwpwm));
> ld2 = dwc_pwm_readl(dwc, DWC_TIM_LD_CNT2(pwm->hwpwm));
> @@ -137,17 +141,19 @@ static int dwc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> * based on the timer load-count only.
> */
> if (ctrl & DWC_TIM_CTRL_PWM) {
> - duty = (ld + 1) * dwc->clk_ns;
> - period = (ld2 + 1) * dwc->clk_ns;
> + duty = ld + 1;
> + period = ld2 + 1;
> period += duty;
> } else {
> - duty = (ld + 1) * dwc->clk_ns;
> + duty = ld + 1;
> period = duty * 2;
> }
>
> + duty *= NSEC_PER_SEC;
> + period *= NSEC_PER_SEC;
A comment that/why this cannot overflow would be nice. (I didn't check,
maybe it can?)
> + state->period = DIV_ROUND_CLOSEST_ULL(period, clk_rate);
> + state->duty_cycle = DIV_ROUND_CLOSEST_ULL(duty, clk_rate);
Without having thought deeply about this, I think you need to round up
here. Hmm, but given that .apply() uses round-closest, too, this needs
to be addressed separately.
(The ugly thing about round-closest is that .apply(mypwm,
.get_state(mypwm)) isn't idempotent in general. Consider a PWM that can
implement period = 41.7ns and period = 42.4 ns. If it's configured with
42.4, .get_state will return period = 42. Reapplying this will configure
for 41.7ns. This won't happen with the PCI clkrate, but it might in the
of case. Another reason to use rounding-down in .apply is that
mul_u64_u64_div_u64 doesn't have a round-nearest variant.)
> state->polarity = PWM_POLARITY_INVERSED;
> - state->period = period;
> - state->duty_cycle = duty;
>
> pm_runtime_put_sync(chip->dev);
>
> @@ -168,7 +174,7 @@ struct dwc_pwm *dwc_pwm_alloc(struct device *dev)
> if (!dwc)
> return NULL;
>
> - dwc->clk_ns = 10;
> + dwc->clk_rate = NSEC_PER_SEC / 10;
> dwc->chip.dev = dev;
> dwc->chip.ops = &dwc_pwm_ops;
> dwc->chip.npwm = DWC_TIMERS_TOTAL;
> diff --git a/drivers/pwm/pwm-dwc.h b/drivers/pwm/pwm-dwc.h
> index 64795247c54c..e0a940fd6e87 100644
> --- a/drivers/pwm/pwm-dwc.h
> +++ b/drivers/pwm/pwm-dwc.h
> @@ -42,7 +42,7 @@ struct dwc_pwm_ctx {
> struct dwc_pwm {
> struct pwm_chip chip;
> void __iomem *base;
> - unsigned int clk_ns;
> + unsigned long clk_rate;
Given that clk_ns was only introduced in patch #2 I think it would be
cleaner to squash these two patches together.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-09-07 21:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 16:12 [PATCH v9 0/6] designware pwm driver updates Ben Dooks
2023-09-07 16:12 ` [PATCH v9 1/6] pwm: dwc: split pci out of core driver Ben Dooks
2023-09-07 21:15 ` Uwe Kleine-König
2023-09-07 16:12 ` [PATCH v9 2/6] pwm: dwc: make timer clock configurable Ben Dooks
2023-09-07 16:12 ` [PATCH v9 3/6] pwm: dwc: add PWM bit unset in get_state call Ben Dooks
2023-09-22 17:35 ` Uwe Kleine-König
2023-09-25 7:02 ` Ben Dooks
2023-09-07 16:12 ` [PATCH v9 4/6] pwm: dwc: use clock rate in hz to avoid rounding issues Ben Dooks
2023-09-07 21:34 ` Uwe Kleine-König [this message]
2023-09-11 7:33 ` Ben Dooks
2023-09-11 19:47 ` Uwe Kleine-König
2023-09-07 16:12 ` [PATCH v9 5/6] pwm: dwc: round rate divisions up Ben Dooks
2023-09-07 21:36 ` Uwe Kleine-König
2023-09-07 16:12 ` [PATCH v9 6/6] pwm: dwc: add of/platform support Ben Dooks
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=20230907213419.aqzwoppznj5tx7w6@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=ben.dooks@codethink.co.uk \
--cc=devicetree@vger.kernel.org \
--cc=greentime.hu@sifive.com \
--cc=jarkko.nikula@linux.intel.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=thierry.reding@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).