Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp57280ybm; Tue, 26 May 2020 10:38:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5uy1s+t3cFlseqg2SLX8SkHGVIcfXG38MIdt8MzhB9QcGaPN24VjtDffXBMVcnkJqWaAa X-Received: by 2002:a50:f0ce:: with SMTP id a14mr21255499edm.131.1590514687197; Tue, 26 May 2020 10:38:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590514687; cv=none; d=google.com; s=arc-20160816; b=OqnbBgp7JTvTOBKVCH1uUer6MlBvVAznUBH2ck3pceyTrgR06qRMKnmZweF3rX6FS6 NAhQf6f9sJ2QKjrVTyOdYUBSqc/3avHnpOoRAm8C3DmFVCUsID2/NdXU3gSvx8SZxa9x r91/0i/OPG7Ms3e3sE+sF01Hu180fxjR9MIGQtquQx5Z8akXKLA43K2rA3FPEQtXhdT3 LFOMkPmA3kdypvLqe+YkIoKO953aNqbZyl4JgZzWn/6Vp11bnVz/8RJN2+yhIh5Gxbqo XLb507y3ksNpaFGA6zMcaIWq8RzZhB7WO65ZBXgfWUbOb1PIIaeBXfdAlPVaZQl8loXd nQ4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from; bh=uh+h1HZweOta1ow1Fwqz5ngcKlfSIev643fjHsrfgsc=; b=iprIOZmf6th9tWOD7jvjC6UDY9ra9T01EJcWix1N85d0NxD7u66RJy+h7IKIFO22Oe 3GA7/FYUy3/DYRhmNf3FGclVDaSJ2EqgUF+626EHsUgBdgG6qsbJGoVyoeD5DEwVgyrB hpJ83FC+Cd2HMZYDyVNvln9AiaqQq9Tx3ZfI6GQkZMzyruMSv1CwgfP2Ncaqj22/Wy5p 3zBwAAZlxrJP2Nk6axjJA+NOYS6ImJ+bcb4uhO4EXqbF59Hbf9TpPFTnwT51/3xSQ9/P AbChIf+TiYJ5fSvzRNdOPp/RlbSOc6gpuTbO00b1t3QEtPHLto81Iw7i7Xh3AI0g/1U9 6g+g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ch20si303412ejb.31.2020.05.26.10.37.43; Tue, 26 May 2020 10:38:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389208AbgEZRfl (ORCPT + 99 others); Tue, 26 May 2020 13:35:41 -0400 Received: from alexa-out-sd-01.qualcomm.com ([199.106.114.38]:65094 "EHLO alexa-out-sd-01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388784AbgEZRfP (ORCPT ); Tue, 26 May 2020 13:35:15 -0400 Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-01.qualcomm.com with ESMTP; 26 May 2020 10:35:14 -0700 Received: from gurus-linux.qualcomm.com ([10.46.162.81]) by ironmsg01-sd.qualcomm.com with ESMTP; 26 May 2020 10:35:13 -0700 Received: by gurus-linux.qualcomm.com (Postfix, from userid 383780) id 7DE394C9C; Tue, 26 May 2020 10:35:13 -0700 (PDT) From: Guru Das Srinagesh To: linux-pwm@vger.kernel.org, Thierry Reding , =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Cc: Subbaraman Narayanamurthy , David Collins , linux-kernel@vger.kernel.org, Joe Perches , Stephen Boyd , Lee Jones , Arnd Bergmann , Geert Uytterhoeven , Guenter Roeck , Daniel Thompson , Dan Carpenter , linux-arm-kernel@lists.infradead.org, Guru Das Srinagesh , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team Subject: [PATCH v15 06/11] pwm: imx27: Use 64-bit division macro and function Date: Tue, 26 May 2020 10:35:06 -0700 Message-Id: <848494725fd1240ed877d0a1471dd11ccea01ff5.1590514331.git.gurus@codeaurora.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend, and div64_u64 to handle a 64-bit divisor. Also handle a possible overflow in the calculation of period_cycles when both clk_rate and period are large numbers. This logic was unit-tested out by calculating period_cycles using both the existing logic and the proposed one, and the results are as below. ---------------------------------------------------------------------------- clk_rate period existing proposed ---------------------------------------------------------------------------- 1000000000 18446744073709551615 18446744072 18446744073000000000 (U64_MAX) ---------------------------------------------------------------------------- 1000000000 4294967291 4294967291 4294967291 ---------------------------------------------------------------------------- Overflow occurs in the first case with the existing logic, whereas the proposed logic handles it better, sacrificing some precision in a best-effort attempt to handle overflow. As for the second case where there are more typical values of period, the proposed logic handles that correctly too. Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Signed-off-by: Guru Das Srinagesh --- drivers/pwm/pwm-imx27.c | 53 +++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 45 insertions(+), 8 deletions(-) diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c index a6e40d4..164cb65 100644 --- a/drivers/pwm/pwm-imx27.c +++ b/drivers/pwm/pwm-imx27.c @@ -203,7 +203,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip, sr = readl(imx->mmio_base + MX3_PWMSR); fifoav = FIELD_GET(MX3_PWMSR_FIFOAV, sr); if (fifoav == MX3_PWMSR_FIFOAV_4WORDS) { - period_ms = DIV_ROUND_UP(pwm_get_period(pwm), + period_ms = DIV_ROUND_UP_ULL(pwm_get_period(pwm), NSEC_PER_MSEC); msleep(period_ms); @@ -213,6 +213,45 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip, } } +static int pwm_imx27_calc_period_cycles(const struct pwm_state *state, + unsigned long clk_rate, + unsigned long *period_cycles) +{ + u64 c = 0, c1, c2; + + c1 = clk_rate; + c2 = state->period; + if (c2 > c1) { + c2 = c1; + c1 = state->period; + } + + if (!c1 || !c2) { + pr_err("clk rate and period should be nonzero\n"); + return -EINVAL; + } + + if (c2 <= div64_u64(U64_MAX, c1)) { + c = c1 * c2; + do_div(c, 1000000000); + } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000))) { + do_div(c1, 1000); + c = c1 * c2; + do_div(c, 1000000); + } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000))) { + do_div(c1, 1000000); + c = c1 * c2; + do_div(c, 1000); + } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000000))) { + do_div(c1, 1000000000); + c = c1 * c2; + } + + *period_cycles = c; + + return 0; +} + static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, const struct pwm_state *state) { @@ -225,18 +264,16 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, pwm_get_state(pwm, &cstate); - c = clk_get_rate(imx->clk_per); - c *= state->period; - - do_div(c, 1000000000); - period_cycles = c; + ret = pwm_imx27_calc_period_cycles(state, clk_get_rate(imx->clk_per), + &period_cycles); + if (ret) + return ret; prescale = period_cycles / 0x10000 + 1; period_cycles /= prescale; c = (unsigned long long)period_cycles * state->duty_cycle; - do_div(c, state->period); - duty_cycles = c; + duty_cycles = div64_u64(c, state->period); /* * according to imx pwm RM, the real period value should be PERIOD -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project