Convert PWM period and duty cycle to u64
Subsystems (16)
v11 cover Convert PWM period and duty cycle to u64
Because period and duty cycle are defined in the PWM framework structs as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Consequently, applications desiring to set greater time periods via the PWM framework are not be able to do so - like, for instance, causing an LED to blink at an interval of 5 seconds.
Redefining the period and duty cycle struct members in the core PWM framework structs as u64 values will enable larger time durations to be set and solve this problem. Such a change to the framework mandates that drivers using these struct members (and corresponding helper functions) also be modified correctly in order to prevent compilation errors.
This patch series introduces the changes to all the drivers first, followed by the framework change at the very end so that when the latter is applied, all the drivers are in good shape and there are no compilation errors.
Changes from v10:
- Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received so far that had gotten missed in v9. No other changes.
Changes from v9:
- Gathered the received "Reviewed-by: " tag
- Added back the clk-pwm.c patch because kbuild test robot complained [3] and addressed received review comments.
- clps711x: Addressed review comments.
Changes from v8:
- Gathered all received "Acked-by: " and "Reviewed-by: " tags
- Dropped patch to clk-pwm.c for reasons mentiond in [2]
- Expanded audience of unreviewed patches
Changes from v7:
- Changed commit messages of all patches to be brief and to the point.
- Added explanation of change in cover letter.
- Dropped change to pwm-sti.c as upon review it was unnecessary as struct pwm_capture is not being modified in the PWM core.
Changes from v6:
- Split out the driver changes out into separate patches, one patch per file for ease of reviewing.
Changes from v5:
- Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
in https://www.spinics.net/lists/linux-pwm/msg11541.html
Changes from v4:
- Split the patch into two: one for changes to the drivers, and the actual switch to u64 for ease of reverting should the need arise.
- Re-examined the patch and made the following corrections:
* intel_panel.c:
DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be 64-bit in this case).
* pwm-sti.c:
do_div -> div_u64 (do_div is optimized only for x86 architectures, and div_u64's comment block suggests to use this as much as possible).
Changes from v3:
- Rebased to current tip of for-next.
Changes from v2:
- Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
- Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c
Changes from v1:
- Fixed compilation errors seen when compiling for different archs.
v1:
- Reworked the change pushed upstream earlier [1] so as to not add an extension to an obsolete API. With this change, pwm_ops->apply() can be used to set pwm_state parameters as usual.
[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/[email protected]/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
Guru Das Srinagesh (12):
drm/i915: Use 64-bit division macro
hwmon: pwm-fan: Use 64-bit division macro
ir-rx51: Use 64-bit division macro
pwm: clps711x: Cast period to u32 before use as divisor
pwm: pwm-imx-tpm: Use 64-bit division macro
pwm: imx27: Use 64-bit division macro and function
pwm: sifive: Use 64-bit division macro
pwm: stm32-lp: Use %llu format specifier for period
pwm: sun4i: Use 64-bit division function
backlight: pwm_bl: Use 64-bit division function
clk: pwm: Assign u64 divisor to unsigned int before use
pwm: core: Convert period and duty cycle to u64
drivers/clk/clk-pwm.c | 4 +++- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- drivers/hwmon/pwm-fan.c | 2 +- drivers/media/rc/ir-rx51.c | 3 ++- drivers/pwm/core.c | 4 ++-- drivers/pwm/pwm-clps711x.c | 5 ++++- drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c | 5 ++--- drivers/pwm/pwm-sifive.c | 2 +- drivers/pwm/pwm-stm32-lp.c | 2 +- drivers/pwm/pwm-sun4i.c | 2 +- drivers/pwm/sysfs.c | 8 ++++---- drivers/video/backlight/pwm_bl.c | 3 ++- include/linux/pwm.h | 12 ++++++------ 14 files changed, 31 insertions(+), 25 deletions(-)
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v11 1/12 drm/i915: Use 64-bit division macro
Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend.
--- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/display/intel_panel.c +1 -1
@@ -1868,7 +1868,7 @@ static int pwm_setup_backlight(struct intel_connector *connector, panel->backlight.min =0 ;/* 0% */ panel->backlight.max =100 ;/* 100% */ - panel->backlight.level =DIV_ROUND_UP ( + panel->backlight.level =DIV_ROUND_UP_ULL (pwm_get_duty_cycle (panel->backlight.pwm) *100 ,CRC_PMIC_PWM_PERIOD_NS ); panel->backlight.enabled = panel->backlight.level !=0 ;
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v11 2/12 hwmon: pwm-fan: Use 64-bit division macro
In reply to Guru Das SrinageshSince the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend.
--- drivers/hwmon/pwm-fan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/pwm-fan.c +1 -1
@@ -437,7 +437,7 @@ static int pwm_fan_resume(struct device *dev)return 0 ;pwm_get_args (ctx->pwm, &pargs); - duty =DIV_ROUND_UP (ctx->pwm_value * (pargs.period -1 ),MAX_PWM ); + duty =DIV_ROUND_UP_ULL (ctx->pwm_value * (pargs.period -1 ),MAX_PWM ); ret =pwm_config (ctx->pwm, duty, pargs.period);if (ret)return ret;
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v11 3/12 ir-rx51: Use 64-bit division macro
In reply to Guru Das SrinageshSince the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using DIV_ROUND_CLOSEST_ULL to handle a 64-bit dividend.
--- drivers/media/rc/ir-rx51.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/media/rc/ir-rx51.c +2 -1
@@ -241,7 +241,8 @@ static int ir_rx51_probe(struct platform_device *dev) }/* Use default, in case userspace does not set the carrier */ - ir_rx51.freq =DIV_ROUND_CLOSEST (pwm_get_period (pwm),NSEC_PER_SEC ); + ir_rx51.freq =DIV_ROUND_CLOSEST_ULL (pwm_get_period (pwm), +NSEC_PER_SEC );pwm_put (pwm);hrtimer_init (&ir_rx51.timer,CLOCK_MONOTONIC ,HRTIMER_MODE_REL );
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v11 4/12 pwm: clps711x: Cast period to u32 before use as divisor
In reply to Guru Das SrinageshSince the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by typecasting it to u32.
Also, since the dividend is still a 32-bit number, any divisor greater than UINT_MAX will cause the quotient to be zero, so return 0 in that case to efficiently skip the division.
--- drivers/pwm/pwm-clps711x.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/pwm/pwm-clps711x.c +4 -1
@@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)static unsigned int clps711x_get_duty (struct pwm_device *pwm,unsigned int v) {/* Duty cycle 0..15 max */ -return DIV_ROUND_CLOSEST (v *0xf , pwm->args.period); +if (pwm->args.period >UINT_MAX ) +return 0 ; + +return DIV_ROUND_CLOSEST (v *0xf , (u32 )pwm->args.period); }static int clps711x_pwm_request (struct pwm_chip *chip,struct pwm_device *pwm)
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v11 04/12] pwm: clps711x: Cast period to u32 before use as divisor
Quoted 4 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by typecasting it to u32.
Quoted 8 lines
Also, since the dividend is still a 32-bit number, any divisor greater than
UINT_MAXwill cause the quotient to be zero, so return 0 in that case to efficiently skip the division.Cc Alexander Shiyan <[email protected]>Cc Arnd Bergmann <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>
Re: [PATCH v11 04/12] pwm: clps711x: Cast period to u32 before use as divisor
Quoted 9 lines · Arnd Bergmann
Quoted 8 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by typecasting it to u32.
Also, since the dividend is still a 32-bit number, any divisor greater than
UINT_MAXwill cause the quotient to be zero, so return 0 in that case to efficiently skip the division.
Quoted 6 lines
Quoted 4 lines
Cc Alexander Shiyan <[email protected]>Cc Arnd Bergmann <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>Reviewed-by Arnd Bergmann <[email protected]>
The stated aim of adding the if condition is to determine when the division operation may be skipped as the quotient would be zero anyway [1]. That said, I think the current if condition is incorrect. The quotient would be zero only when the denominator of the division exceeds (v * 0xf) and not UINT_MAX. In fact, UINT_MAX has no bearing on whether the quotient becomes zero or not.
Therefore, the correct if condition should be:
- return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
+ if ((u32)pwm->args.period > (v * 0xf))
+ return 0;
+
+ return DIV_ROUND_CLOSEST(v * 0xf, (u32)pwm->args.period);
What do you think?
[1] https://www.spinics.net/lists/linux-pwm/msg11908.html
Thank you.
Guru Das.
PATCH v11 5/12 pwm: pwm-imx-tpm: Use 64-bit division macro
In reply to Guru Das SrinageshSince the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to handle a 64-bit divisor.
--- drivers/pwm/pwm-imx-tpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pwm/pwm-imx-tpm.c +1 -1
@@ -126,7 +126,7 @@ static int pwm_imx_tpm_round_state(struct pwm_chip *chip, real_state->duty_cycle = state->duty_cycle; tmp = (u64 )p->mod * real_state->duty_cycle; - p->val =DIV_ROUND_CLOSEST_ULL (tmp, real_state->period); + p->val =DIV64_U64_ROUND_CLOSEST (tmp, real_state->period); real_state->polarity = state->polarity; real_state->enabled = state->enabled;
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v11 6/12 pwm: imx27: Use 64-bit division macro and function
In reply to Guru Das SrinageshSince 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.
--- drivers/pwm/pwm-imx27.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/pwm/pwm-imx27.c +2 -3
@@ -208,7 +208,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);
@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, 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
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
drivers/pwm/pwm-imx27.c static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 244
Quoted 8 lines · Guru Das Srinagesh
drivers/pwm/pwm-imx27.c +1
-2@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, 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);
This change looks fine, but I wonder if the code directly above it
c = clk_get_rate(imx->clk_per);
c *= state->period;
do_div(c, 1000000000);
period_cycles = c;might run into an overflow when both the clock rate and the period are large numbers.
Arnd
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
Quoted 13 lines · Arnd Bergmann
drivers/pwm/pwm-imx27.c static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 244
Quoted 8 lines · Guru Das Srinagesh
drivers/pwm/pwm-imx27.c +1
-2@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, 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);This change looks fine, but I wonder if the code directly above it
Quoted 7 lines
c = clk_get_rate(imx->clk_per); c *= state->period; do_div(c, 1000000000); period_cycles = c;might run into an overflow when both the clock rate and the period are large numbers.
Hmm. Seems to me like addressing this would be outside the scope of this patch series.
Thank you.
Guru Das.
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
Quoted 20 lines · Guru Das Srinagesh
Quoted 18 lines · Arnd Bergmann
drivers/pwm/pwm-imx27.c static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 244
Quoted 8 lines · Guru Das Srinagesh
drivers/pwm/pwm-imx27.c +1
-2@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, 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);This change looks fine, but I wonder if the code directly above it
c = clk_get_rate(imx->clk_per); c *= state->period; do_div(c, 1000000000); period_cycles = c;
Quoted 5 lines
Quoted 2 lines
might run into an overflow when both the clock rate and the period are large numbers.
Hmm. Seems to me like addressing this would be outside the scope of this patch series.
I think it should be part of the same series, addressing bugs that were introduced
by the change to 64-bit period. If it's not getting fixed along with the other regressions,
I fear nobody is going to go back and fix it later.
Arnd
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
Quoted 25 lines · Arnd Bergmann
Quoted 23 lines · Guru Das Srinagesh
Quoted 20 lines · Arnd Bergmann
drivers/pwm/pwm-imx27.c static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 244
Quoted 8 lines · Guru Das Srinagesh
drivers/pwm/pwm-imx27.c +1
-2@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, 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);This change looks fine, but I wonder if the code directly above it
c = clk_get_rate(imx->clk_per); c *= state->period; do_div(c, 1000000000); period_cycles = c;might run into an overflow when both the clock rate and the period are large numbers.
Quoted 8 lines
Quoted 2 lines
Hmm. Seems to me like addressing this would be outside the scope of this patch series.
I think it should be part of the same series, addressing bugs that were introduced
by the change to 64-bit period. If it's not getting fixed along with the other regressions,
I fear nobody is going to go back and fix it later.
Makes sense, I agree. Would this be an acceptable fix?
Instead of multiplying c and state->period first and then dividing by 10^9, first divide state->period by 10^9 and then multiply the quotient of that division with c and assign it to period_cycles. Like so:
c = clk_get_rate(imx->clk_per); c *= div_u64(state->period, 1000000000); period_cycles = c;
This should take care of overflow not happening because state->period is converted from nanoseconds to seconds early on and so becomes a small number.
Thank you.
Guru Das.
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
Quoted 41 lines · Guru Das Srinagesh
Quoted 25 lines · Arnd Bergmann
Quoted 23 lines · Guru Das Srinagesh
Quoted 20 lines · Arnd Bergmann
drivers/pwm/pwm-imx27.c static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 244
Quoted 8 lines · Guru Das Srinagesh
drivers/pwm/pwm-imx27.c +1
-2@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, 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);This change looks fine, but I wonder if the code directly above it
c = clk_get_rate(imx->clk_per); c *= state->period; do_div(c, 1000000000); period_cycles = c;might run into an overflow when both the clock rate and the period are large numbers.
Quoted 8 lines
Quoted 2 lines
Hmm. Seems to me like addressing this would be outside the scope of this patch series.
I think it should be part of the same series, addressing bugs that were introduced
by the change to 64-bit period. If it's not getting fixed along with the other regressions,
I fear nobody is going to go back and fix it later.Makes sense, I agree. Would this be an acceptable fix?
Instead of multiplying c and
state->periodfirst and then dividing by 10^9, first dividestate->periodby 10^9 and then multiply the quotient of that division with c and assign it toperiod_cycles. Like so:
Quoted 7 lines
c = clk_get_rate(imx->clk_per); c *= div_u64(state->period, 1000000000); period_cycles = c;This should take care of overflow not happening because
state->periodis converted from nanoseconds to seconds early on and so becomes a small number.
Doesn't that mean that anything below a 1 second period will be clamped to just 0?
Thierry
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
Quoted 46 lines · Thierry Reding
Quoted 45 lines · Guru Das Srinagesh
Quoted 25 lines · Arnd Bergmann
Quoted 23 lines · Guru Das Srinagesh
Quoted 20 lines · Arnd Bergmann
drivers/pwm/pwm-imx27.c static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 244
Quoted 8 lines · Guru Das Srinagesh
drivers/pwm/pwm-imx27.c +1
-2@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, 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);This change looks fine, but I wonder if the code directly above it
c = clk_get_rate(imx->clk_per); c *= state->period; do_div(c, 1000000000); period_cycles = c;might run into an overflow when both the clock rate and the period are large numbers.
Quoted 8 lines
Quoted 2 lines
Hmm. Seems to me like addressing this would be outside the scope of this patch series.
I think it should be part of the same series, addressing bugs that were introduced
by the change to 64-bit period. If it's not getting fixed along with the other regressions,
I fear nobody is going to go back and fix it later.Makes sense, I agree. Would this be an acceptable fix?
Instead of multiplying c and
state->periodfirst and then dividing by 10^9, first dividestate->periodby 10^9 and then multiply the quotient of that division with c and assign it toperiod_cycles. Like so:c = clk_get_rate(imx->clk_per); c *= div_u64(state->period, 1000000000); period_cycles = c;
Quoted 6 lines
Quoted 3 lines
This should take care of overflow not happening because
state->periodis converted from nanoseconds to seconds early on and so becomes a small number.Doesn't that mean that anything below a 1 second period will be clamped to just 0?
True. How about this then?
int pwm_imx27_calc_period_cycles(struct pwm_state state,
unsigned long clk_rate, unsigned long *period_cycles)
{
u64 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;
}...
ret = pwm_imx27_calc_period_cycles(state, clk_get_rate(imx->clk_per),
&period_cycles); if (ret) return ret;
I unit tested this logic 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 correctly. As for the second case where there are more typical values of period, the proposed logic handles that correctly too.
Thank you.
Guru Das.
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
Quoted 109 lines · Guru Das Srinagesh
Quoted 46 lines · Thierry Reding
Quoted 45 lines · Guru Das Srinagesh
Quoted 25 lines · Arnd Bergmann
Quoted 23 lines · Guru Das Srinagesh
Quoted 20 lines · Arnd Bergmann
Review static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 244
Quoted 8 lines · Guru Das Srinagesh
(quoted diff) +1
-2@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, 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);This change looks fine, but I wonder if the code directly above it
c = clk_get_rate(imx->clk_per); c *= state->period; do_div(c, 1000000000); period_cycles = c;might run into an overflow when both the clock rate and the period are large numbers.
Quoted 8 lines
Quoted 2 lines
Hmm. Seems to me like addressing this would be outside the scope of this patch series.
I think it should be part of the same series, addressing bugs that were introduced
by the change to 64-bit period. If it's not getting fixed along with the other regressions,
I fear nobody is going to go back and fix it later.Makes sense, I agree. Would this be an acceptable fix?
Instead of multiplying c and
state->periodfirst and then dividing by 10^9, first dividestate->periodby 10^9 and then multiply the quotient of that division with c and assign it toperiod_cycles. Like so:c = clk_get_rate(imx->clk_per); c *= div_u64(state->period, 1000000000); period_cycles = c;Quoted 6 lines
Quoted 3 lines
This should take care of overflow not happening because
state->periodis converted from nanoseconds to seconds early on and so becomes a small number.Doesn't that mean that anything below a 1 second period will be clamped to just 0?
True. How about this then?
int pwm_imx27_calc_period_cycles(struct
pwm_statestate,
unsigned longclk_rate, unsigned long*period_cycles){ u64 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; }...
ret = pwm_imx27_calc_period_cycles(state,
clk_get_rate(imx->clk_per),&period_cycles); if (ret) return ret;I unit tested this logic out by calculating
period_cyclesusing both the existing logic and the proposed one, and the results are as below.--------------------------------------------------------------------------------
clk_rateperiod existing proposed
--------------------------------------------------------------------------------
1000000000 18446744073709551615 18446744072 18446744073000000000
Quoted 7 lines
(U64_MAX)--------------------------------------------------------------------------------
1000000000 4294967291 4294967291 4294967291
--------------------------------------------------------------------------------Overflow occurs in the first case with the existing logic, whereas the proposed logic handles it correctly.
Well, not "correctly" exactly, but a best-effort attempt to handle the overflow with som loss of precision.
Thank you.
Guru Das.
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
In reply to Guru Das SrinageshQuoted 60 lines · Guru Das Srinagesh
Quoted 2 lines · Thierry Reding
Doesn't that mean that anything below a 1 second period will be clamped to just 0?
True. How about this then?
int pwm_imx27_calc_period_cycles(struct
pwm_statestate,
unsigned longclk_rate, unsigned long*period_cycles){ u64 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; }...
ret = pwm_imx27_calc_period_cycles(state,
clk_get_rate(imx->clk_per),&period_cycles); if (ret) return ret;I unit tested this logic out by calculating
period_cyclesusing both the existing logic and the proposed one, and the results are as below.--------------------------------------------------------------------------------
clk_rateperiod existing proposed
--------------------------------------------------------------------------------
1000000000 18446744073709551615 18446744072 18446744073000000000(U64_MAX)
Quoted 8 lines
--------------------------------------------------------------------------------
1000000000 4294967291 4294967291 4294967291
--------------------------------------------------------------------------------Overflow occurs in the first case with the existing logic, whereas the proposed logic handles it correctly. As for the second case where there are more typical values of period, the proposed logic handles that correctly too.
This looks correct, but very expensive, and you don't really have to go this far, given that c1 is guaranteed to be a 32-bit number, and you divide by a constant in the end.
Why not do something like
#define SHIFT 41 /* arbitrarily picked, not too big, not too small */ #define MUL 2199 /* 2^SHIFT / NSEC_PER_SEC */period_cycles = clk_get_rate(imx->clk_per) * ((state->period * MUL) >> SHIFT);
Arnd
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
Quoted 9 lines · Arnd Bergmann
This looks correct, but very expensive, and you don't really have to go this far, given that c1 is guaranteed to be a 32-bit number, and you divide by a constant in the end.
Why not do something like
#define SHIFT 41 /* arbitrarily picked, not too big, not too small */ #define MUL 2199 /* 2^SHIFT /
NSEC_PER_SEC*/period_cycles=clk_get_rate(imx->clk_per)* ((state->period* MUL) >> SHIFT);
I have two concerns with this:
1. This actually results in the division by 1000010575.5125057 instead of NSECS_PER_SEC whereas both the existing as well as the proposed logic divide exactly by NSECS_PER_SEC.
2. What method shall be used to pick the SHIFT value? How is this to be chosen?
Also, this seems sort of similar to my initial attempt at this problem, where period was being pre-divided prior to the multiplication, which was (rightly) NACKed.
c *= div_u64(state->period, 1000000000);
Thank you.
Guru Das.
Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function
Quoted 12 lines · Guru Das Srinagesh
Quoted 9 lines · Arnd Bergmann
This looks correct, but very expensive, and you don't really have to go this far, given that c1 is guaranteed to be a 32-bit number, and you divide by a constant in the end.
Why not do something like
#define SHIFT 41 /* arbitrarily picked, not too big, not too small */ #define MUL 2199 /* 2^SHIFT /
NSEC_PER_SEC*/period_cycles=clk_get_rate(imx->clk_per)* ((state->period* MUL) >> SHIFT);
Quoted 7 lines
I have two concerns with this:
1. This actually results in the division by 1000010575.5125057 instead of
NSECS_PER_SECwhereas both the existing as well as the proposed logic divide exactly byNSECS_PER_SEC.
2. What method shall be used to pick the SHIFT value? How is this to be chosen?
I picked one that would result in a fairly accurate rounding and did not seem too likely to overflow.
Quoted 5 lines
Also, this seems sort of similar to my initial attempt at this problem, where period was being pre-divided prior to the multiplication, which was (rightly) NACKed.
c *= div_u64(state->period, 1000000000);
Ah, right, I did make the same mistake here. What I actually indended was to do two separate shifts that add up to 41. I suppose there is also still the fundamental problem that without bounds checking the calculation can always overflow for large inputs.
Arnd
PATCH v11 7/12 pwm: sifive: Use 64-bit division macro
In reply to Guru Das SrinageshSince the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to handle a 64-bit divisor.
--- drivers/pwm/pwm-sifive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pwm/pwm-sifive.c +1 -1
@@ -181,7 +181,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,* consecutively */ num = (u64 )duty_cycle * (1U <<PWM_SIFIVE_CMPWIDTH ); - frac =DIV_ROUND_CLOSEST_ULL (num, state->period); + frac =DIV64_U64_ROUND_CLOSEST (num, state->period);/* The hardware cannot generate a 100% duty cycle */ frac =min (frac, (1U <<PWM_SIFIVE_CMPWIDTH ) -1 );
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v11 8/12 pwm: stm32-lp: Use %llu format specifier for period
In reply to Guru Das SrinageshSince the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using the right specifier for printing a 64-bit value.
--- drivers/pwm/pwm-stm32-lp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pwm/pwm-stm32-lp.c +1 -1
@@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,do_div (div,NSEC_PER_SEC );if (!div) {/* Clock is too slow to achieve requested period. */ -dev_dbg (priv->chip.dev,"Can't reach %u ns\n" , state->period); +dev_dbg (priv->chip.dev,"Can't reach %llu ns\n" , state->period);return -EINVAL ; }
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v11 08/12] pwm: stm32-lp: Use %llu format specifier for period
Quoted 3 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using the right specifier for printing a 64-bit value.
[]
drivers/pwm/pwm-stm32-lp.c
Quoted 1 line
drivers/pwm/pwm-stm32-lp.c +0
-0
[]
drivers/pwm/pwm-stm32-lp.c static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 66
Quoted 8 lines
drivers/pwm/pwm-stm32-lp.c +1
-1@@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,do_div (div,NSEC_PER_SEC );if (!div) {/* Clock is too slow to achieve requested period. */ -dev_dbg (priv->chip.dev,"Can't reach %u ns\n" , state->period); +dev_dbg (priv->chip.dev,"Can't reach %llu ns\n" , state->period);return -EINVAL ; }
Doesn't this introduce a warning now without the
actual change to the type of state->period?
Likely these patches should either not be separated or this should also use a cast to avoid introducing intermediate compilation warnings.
Re: [PATCH v11 08/12] pwm: stm32-lp: Use %llu format specifier for period
Quoted 7 lines · Joe Perches
Quoted 3 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using the right specifier for printing a 64-bit value.
[]
drivers/pwm/pwm-stm32-lp.c
Quoted 1 line
drivers/pwm/pwm-stm32-lp.c +0
-0[]
Quoted 11 lines
drivers/pwm/pwm-stm32-lp.c static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 66
Quoted 8 lines
drivers/pwm/pwm-stm32-lp.c +1
-1@@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,do_div (div,NSEC_PER_SEC );if (!div) {/* Clock is too slow to achieve requested period. */ -dev_dbg (priv->chip.dev,"Can't reach %u ns\n" , state->period); +dev_dbg (priv->chip.dev,"Can't reach %llu ns\n" , state->period);return -EINVAL ; }Doesn't this introduce a warning now without the
actual change to the type ofstate->period?
You're right, it does.
Quoted 3 lines
Likely these patches should either not be separated or this should also use a cast to avoid introducing intermediate compilation warnings.
Only this patch has this specific issue, so I'll squish it with the final patch in this series ("pwm: core: Convert period and duty cycle to u64") that modifies the framework structs. Thanks for pointing this out.
Thank you.
Guru Das.
PATCH v11 9/12 pwm: sun4i: Use 64-bit division function
In reply to Guru Das SrinageshSince the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using div_u64 to handle a 64-bit dividend instead of a straight division operation.
--- drivers/pwm/pwm-sun4i.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pwm/pwm-sun4i.c +1 -1
@@ -286,7 +286,7 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, val = (duty &PWM_DTY_MASK ) |PWM_PRD (period);sun4i_pwm_writel (sun4i_pwm, val,PWM_CH_PRD (pwm->hwpwm)); sun4i_pwm->next_period[pwm->hwpwm] = jiffies + -usecs_to_jiffies (cstate.period /1000 +1 ); +usecs_to_jiffies (div_u64 (cstate.period,1000 ) +1 ); sun4i_pwm->needs_delay[pwm->hwpwm] = true;if (state->polarity !=PWM_POLARITY_NORMAL )
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v11 09/12] pwm: sun4i: Use 64-bit division function
drivers/pwm/pwm-sun4i.c static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 290
Quoted 5 lines · Guru Das Srinagesh
sun4i_pwm->next_period[pwm->hwpwm] = jiffies +drivers/pwm/pwm-sun4i.c +1
-1-usecs_to_jiffies (cstate.period /1000 +1 ); +usecs_to_jiffies (div_u64 (cstate.period,1000 ) +1 ); sun4i_pwm->needs_delay[pwm->hwpwm] = true;
This one looks like it should use nsecs_to_jiffies(cstate.period) to avoid having two 64-bit divisions.
Arnd
PATCH v11 10/12 backlight: pwm_bl: Use 64-bit division function
In reply to Guru Das SrinageshSince the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using div_u64 to handle a 64-bit dividend instead of a straight division operation.
--- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/video/backlight/pwm_bl.c +2 -1
@@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->scale = data->max_brightness; } - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); + pb->lth_brightness = data->lth_brightness * (div_u64 (state.period, + pb->scale)); props.type =BACKLIGHT_RAW ; props.max_brightness = data->max_brightness;
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
Quoted 12 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using
div_u64to handle a 64-bit dividend instead of a straight division operation.Cc Lee Jones <[email protected]>Cc Daniel Thompson <[email protected]>Cc Jingoo Han <[email protected]>Cc Bartlomiej Zolnierkiewicz <[email protected]>
Quoted 5 lines
Signed-off-by Guru Das Srinagesh <[email protected]>Reviewed-by Daniel Thompson <[email protected]>--- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Can this patch be taken on its own?
Quoted 14 lines
drivers/video/backlight/pwm_bl.c +2
-1@@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->scale = data->max_brightness; } - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); + pb->lth_brightness = data->lth_brightness * (div_u64 (state.period, + pb->scale)); props.type =BACKLIGHT_RAW ; props.max_brightness = data->max_brightness;
Signature · 8 lines
Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
Quoted 14 lines · Lee Jones
Quoted 12 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using
div_u64to handle a 64-bit dividend instead of a straight division operation.Cc Lee Jones <[email protected]>Cc Daniel Thompson <[email protected]>Cc Jingoo Han <[email protected]>Cc Bartlomiej Zolnierkiewicz <[email protected]>
Quoted 7 lines
Quoted 5 lines
Signed-off-by Guru Das Srinagesh <[email protected]>Reviewed-by Daniel Thompson <[email protected]>--- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)Can this patch be taken on its own?
Hellooooo ...
Quoted 15 lines
Quoted 14 lines
drivers/video/backlight/pwm_bl.c +2
-1@@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->scale = data->max_brightness; } - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); + pb->lth_brightness = data->lth_brightness * (div_u64 (state.period, + pb->scale)); props.type =BACKLIGHT_RAW ; props.max_brightness = data->max_brightness;
Signature · 4 lines
Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
Hello Lee,
Quoted 22 lines · Lee Jones
Quoted 20 lines · Lee Jones
Quoted 17 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using
div_u64to handle a 64-bit dividend instead of a straight division operation.Cc Lee Jones <[email protected]>Cc Daniel Thompson <[email protected]>Cc Jingoo Han <[email protected]>Cc Bartlomiej Zolnierkiewicz <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>Reviewed-by Daniel Thompson <[email protected]>--- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Quoted 3 lines
Quoted 1 line
Can this patch be taken on its own?
Hellooooo ...
Conceptually it can. As the last patch depends on this one (and the others) some coordination might be beneficial. But that's up to Thierry to decide how (and if) he want this series to be applied.
Best regards
Uwe
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
Quoted 25 lines · Uwe Kleine-König
Hello Lee,
Quoted 22 lines · Lee Jones
Quoted 20 lines · Lee Jones
Quoted 17 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using
div_u64to handle a 64-bit dividend instead of a straight division operation.Cc Lee Jones <[email protected]>Cc Daniel Thompson <[email protected]>Cc Jingoo Han <[email protected]>Cc Bartlomiej Zolnierkiewicz <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>Reviewed-by Daniel Thompson <[email protected]>--- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Can this patch be taken on its own?
Hellooooo ...
Conceptually it can. As the last patch depends on this one (and the others) some coordination might be beneficial. But that's up to Thierry to decide how (and if) he want this series to be applied.
... and on the backlight side we definitely need to know about the "if" otherwise there's no point in taking it.
Daniel.
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
Quoted 28 lines · Daniel Thompson
Quoted 27 lines · Uwe Kleine-König
Hello Lee,
Quoted 24 lines · Lee Jones
Quoted 21 lines · Lee Jones
Quoted 12 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using
div_u64to handle a 64-bit dividend instead of a straight division operation.Cc Lee Jones <[email protected]>Cc Daniel Thompson <[email protected]>Cc Jingoo Han <[email protected]>Cc Bartlomiej Zolnierkiewicz <[email protected]>Quoted 5 lines
Signed-off-by Guru Das Srinagesh <[email protected]>Reviewed-by Daniel Thompson <[email protected]>--- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)Can this patch be taken on its own?
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Hellooooo ...
Conceptually it can. As the last patch depends on this one (and the others) some coordination might be beneficial. But that's up to Thierry to decide how (and if) he want this series to be applied.
... and on the backlight side we definitely need to know about the "if" otherwise there's no point in taking it.
Right.
I'm happy to wait for Thierry. Although this isn't the only set he's currently blocking. Is he okay? On holiday perhaps?
Signature · 4 lines
Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
Quoted 36 lines · Lee Jones
Quoted 34 lines · Daniel Thompson
Quoted 32 lines · Uwe Kleine-König
Hello Lee,
Quoted 22 lines · Lee Jones
Quoted 20 lines · Lee Jones
Quoted 17 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using
div_u64to handle a 64-bit dividend instead of a straight division operation.Cc Lee Jones <[email protected]>Cc Daniel Thompson <[email protected]>Cc Jingoo Han <[email protected]>Cc Bartlomiej Zolnierkiewicz <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>Reviewed-by Daniel Thompson <[email protected]>--- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)Quoted 3 lines
Quoted 1 line
Can this patch be taken on its own?
Hellooooo ...
Conceptually it can. As the last patch depends on this one (and the others) some coordination might be beneficial. But that's up to Thierry to decide how (and if) he want this series to be applied.
Quoted 7 lines
Quoted 2 lines
... and on the backlight side we definitely need to know about the "if" otherwise there's no point in taking it.
Right.
I'm happy to wait for Thierry. Although this isn't the only set he's currently blocking. Is he okay? On holiday perhaps?
The newest commit by him in next is from last week. My guess is he just didn't come around yet to care for the PWM duties.
Best regards
Uwe
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
Quoted 40 lines · Uwe Kleine-König
Quoted 39 lines · Lee Jones
Quoted 36 lines · Daniel Thompson
Quoted 25 lines · Uwe Kleine-König
Hello Lee,
Quoted 22 lines · Lee Jones
Quoted 20 lines · Lee Jones
Quoted 17 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using
div_u64to handle a 64-bit dividend instead of a straight division operation.Cc Lee Jones <[email protected]>Cc Daniel Thompson <[email protected]>Cc Jingoo Han <[email protected]>Cc Bartlomiej Zolnierkiewicz <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>Reviewed-by Daniel Thompson <[email protected]>--- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Can this patch be taken on its own?
Hellooooo ...
Conceptually it can. As the last patch depends on this one (and the others) some coordination might be beneficial. But that's up to Thierry to decide how (and if) he want this series to be applied.
... and on the backlight side we definitely need to know about the "if" otherwise there's no point in taking it.
Quoted 7 lines
Quoted 4 lines
Right.
I'm happy to wait for Thierry. Although this isn't the only set he's currently blocking. Is he okay? On holiday perhaps?
The newest commit by him in next is from last week. My guess is he just didn't come around yet to care for the PWM duties.
Looks like we missed the last release.
Let's hope we don't miss the next one also.
Signature · 4 lines
Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH v11 11/12 clk: pwm: Assign u64 divisor to unsigned int before use
In reply to Guru Das SrinageshSince the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by assigning the 64-bit divisor to an unsigned int variable to use as the divisor. This is being done because the divisor is a 32-bit constant and the quotient will be zero if the divisor exceeds 2^32.
--- drivers/clk/clk-pwm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/clk/clk-pwm.c +3 -1
@@ -72,6 +72,7 @@ static int clk_pwm_probe(struct platform_device *pdev)struct pwm_device *pwm;struct pwm_args pargs;const char *clk_name; +unsigned int period;int ret; clk_pwm =devm_kzalloc (&pdev->dev,sizeof (*clk_pwm),GFP_KERNEL );
@@ -88,8 +89,9 @@ static int clk_pwm_probe(struct platform_device *pdev)return -EINVAL ; } + period = pargs.period;if (of_property_read_u32 (node,"clock-frequency" , &clk_pwm->fixed_rate)) - clk_pwm->fixed_rate =NSEC_PER_SEC / pargs.period; + clk_pwm->fixed_rate =NSEC_PER_SEC / period;if (pargs.period !=NSEC_PER_SEC / clk_pwm->fixed_rate && pargs.period !=DIV_ROUND_UP (NSEC_PER_SEC , clk_pwm->fixed_rate)) {
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v11 11/12] clk: pwm: Assign u64 divisor to unsigned int before use
Quoted 31 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by assigning the 64-bit divisor to an unsigned int variable to use as the divisor. This is being done because the divisor is a 32-bit constant and the quotient will be zero if the divisor exceeds 2^32.
Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc David Laight <[email protected]>Reported-by kbuild test robot <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>--- drivers/clk/clk-pwm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)drivers/clk/clk-pwm.c +1
-0@@ -72,6 +72,7 @@ static int clk_pwm_probe(struct platform_device *pdev)struct pwm_device *pwm;struct pwm_args pargs;const char *clk_name; +unsigned int period;int ret; clk_pwm =devm_kzalloc (&pdev->dev,sizeof (*clk_pwm),GFP_KERNEL );
drivers/clk/clk-pwm.c static int clk_pwm_probe(struct platform_device *pdev) · line 97
Quoted 10 lines
drivers/clk/clk-pwm.c +2
-1@@ -88,8 +89,9 @@ static int clk_pwm_probe(struct platform_device *pdev)return -EINVAL ; } + period = pargs.period;if (of_property_read_u32 (node,"clock-frequency" , &clk_pwm->fixed_rate)) - clk_pwm->fixed_rate =NSEC_PER_SEC / pargs.period; + clk_pwm->fixed_rate =NSEC_PER_SEC / period;if (pargs.period !=NSEC_PER_SEC / clk_pwm->fixed_rate && pargs.period !=DIV_ROUND_UP (NSEC_PER_SEC , clk_pwm->fixed_rate)) {
Doesn't this one need a check for "pargs.period>UINT_MAX" or "pargs.period > NSEC_PER_SEC"?
It looks like truncating the 64-bit value to a 32-bit type can result in unexpected behavior.
Arnd
RE: [PATCH v11 11/12] clk: pwm: Assign u64 divisor to unsigned int before use
From: Arnd Bergmann
Quoted 41 lines
Sent: 20 March 2020 17:01
Quoted 39 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by assigning the 64-bit divisor to an unsigned int variable to use as the divisor. This is being done because the divisor is a 32-bit constant and the quotient will be zero if the divisor exceeds 2^32.
Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc David Laight <[email protected]>Reported-by kbuild test robot <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>--- drivers/clk/clk-pwm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)drivers/clk/clk-pwm.c +3
-1@@ -72,6 +72,7 @@ static int clk_pwm_probe(struct platform_device *pdev)struct pwm_device *pwm;struct pwm_args pargs;const char *clk_name; +unsigned int period;int ret; clk_pwm =devm_kzalloc (&pdev->dev,sizeof (*clk_pwm),GFP_KERNEL );@@ -88,8 +89,9 @@ static int clk_pwm_probe(struct platform_device *pdev)return -EINVAL ; } + period = pargs.period;if (of_property_read_u32 (node,"clock-frequency" , &clk_pwm->fixed_rate)) - clk_pwm->fixed_rate =NSEC_PER_SEC / pargs.period; + clk_pwm->fixed_rate =NSEC_PER_SEC / period;
Quoted 8 lines
drivers/clk/clk-pwm.c static int clk_pwm_probe(struct platform_device *pdev) · line 97
Quoted 2 lines
drivers/clk/clk-pwm.c +0
-0if (pargs.period !=NSEC_PER_SEC / clk_pwm->fixed_rate && pargs.period !=DIV_ROUND_UP (NSEC_PER_SEC , clk_pwm->fixed_rate)) {Doesn't this one need a check for "pargs.period>UINT_MAX" or "pargs.period >
NSEC_PER_SEC"?It looks like truncating the 64-bit value to a 32-bit type can result in unexpected behavior.
I also suspect the last two lines ought to use the 32bit copy. And there is a chance that the division will explode.
This whole series is failing to differentiate between the type of the variables and the domain on the valid values.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH v11 11/12] clk: pwm: Assign u64 divisor to unsigned int before use
Quoted 9 lines · David Laight
From: Arnd Bergmann
Quoted 8 lines
Sent: 20 March 2020 17:01
Quoted 6 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by assigning the 64-bit divisor to an unsigned int variable to use as the divisor. This is being done because the divisor is a 32-bit constant and the quotient will be zero if the divisor exceeds 2^32.
Correction: The quotient will be zero when the denominator exceeds the numerator, i.e. NSECS_PER_SEC, and not U32_MAX. For this to happen, the property "clock-frequency" must be specified to be more than NSEC_PER_SEC, i.e. 1 GHz. Just observed that currently in the device tree, all instances of this driver (compatible string "pwm-clock") are setting this property to values within that limit.
Quoted 33 lines
Quoted 33 lines
Quoted 33 lines
Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc David Laight <[email protected]>Reported-by kbuild test robot <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>--- drivers/clk/clk-pwm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)drivers/clk/clk-pwm.c +3
-1@@ -72,6 +72,7 @@ static int clk_pwm_probe(struct platform_device *pdev)struct pwm_device *pwm;struct pwm_args pargs;const char *clk_name; +unsigned int period;int ret; clk_pwm =devm_kzalloc (&pdev->dev,sizeof (*clk_pwm),GFP_KERNEL );@@ -88,8 +89,9 @@ static int clk_pwm_probe(struct platform_device *pdev)return -EINVAL ; } + period = pargs.period;if (of_property_read_u32 (node,"clock-frequency" , &clk_pwm->fixed_rate)) - clk_pwm->fixed_rate =NSEC_PER_SEC / pargs.period; + clk_pwm->fixed_rate =NSEC_PER_SEC / period;
Quoted 6 lines
Quoted 6 lines
drivers/clk/clk-pwm.c static int clk_pwm_probe(struct platform_device *pdev) · line 97
Quoted 2 lines
drivers/clk/clk-pwm.c +0
-0if (pargs.period !=NSEC_PER_SEC / clk_pwm->fixed_rate && pargs.period !=DIV_ROUND_UP (NSEC_PER_SEC , clk_pwm->fixed_rate)) {Doesn't this one need a check for "pargs.period>UINT_MAX" or "pargs.period >
NSEC_PER_SEC"?
With the assignment of period to unsigned int, wouldn't doing s/pargs.period/period suffice?
Also, will add a check to ensure that clk_pwm->fixed_rate is non-zero. If it is zero, fail probe.
Quoted 5 lines
Quoted 2 lines
It looks like truncating the 64-bit value to a 32-bit type can result in unexpected behavior.
I also suspect the last two lines ought to use the 32bit copy. And there is a chance that the division will explode.
The check mentioned above will ensure that the division will not explode.
What do you guys think?
Thank you.
Guru Das.
PATCH v11 12/12 pwm: core: Convert period and duty cycle to u64
In reply to Guru Das SrinageshBecause period and duty cycle are defined as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Change their definitions to u64 in the structs of the PWM framework so that higher durations may be set.
--- drivers/pwm/core.c | 4 ++-- drivers/pwm/sysfs.c | 8 ++++---- include/linux/pwm.h | 12 ++++++------ 3 files changed, 12 insertions(+), 12 deletions(-)
drivers/pwm/core.c +2 -2
@@ -1163,8 +1163,8 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)if (state.enabled)seq_puts (s," enabled" ); -seq_printf (s," period: %u ns" , state.period); -seq_printf (s," duty: %u ns" , state.duty_cycle); +seq_printf (s," period: %llu ns" , state.period); +seq_printf (s," duty: %llu ns" , state.duty_cycle);seq_printf (s," polarity: %s" , state.polarity ?"inverse" :"normal" );
drivers/pwm/sysfs.c +4 -4
@@ -42,7 +42,7 @@ static ssize_t period_show(struct device *child,pwm_get_state (pwm, &state); -return sprintf (buf,"%u\n" , state.period); +return sprintf (buf,"%llu\n" , state.period); } static ssize_t period_store(struct device *child,
@@ -52,10 +52,10 @@ static ssize_t period_store(struct device *child,struct pwm_export *export =child_to_pwm_export (child);struct pwm_device *pwm = export->pwm;struct pwm_state state; -unsigned int val; +u64 val;int ret; - ret =kstrtouint (buf,0 , &val); + ret =kstrtou64 (buf,0 , &val);if (ret)return ret;
@@ -77,7 +77,7 @@ static ssize_t duty_cycle_show(struct device *child,pwm_get_state (pwm, &state); -return sprintf (buf,"%u\n" , state.duty_cycle); +return sprintf (buf,"%llu\n" , state.duty_cycle); } static ssize_t duty_cycle_store(struct device *child,
include/linux/pwm.h +6 -6
@@ -39,7 +39,7 @@ enum pwm_polarity {* current PWM hardware state. */ struct pwm_args { -unsigned int period; +u64 period;enum pwm_polarity polarity; };
@@ -56,8 +56,8 @@ enum {* @enabled: PWM enabled status */ struct pwm_state { -unsigned int period; -unsigned int duty_cycle; +u64 period; +u64 duty_cycle;enum pwm_polarity polarity;bool enabled; };
@@ -105,13 +105,13 @@ static inline bool pwm_is_enabled(const struct pwm_device *pwm)return state.enabled; } -static inline void pwm_set_period (struct pwm_device *pwm,unsigned int period) +static inline void pwm_set_period (struct pwm_device *pwm,u64 period) {if (pwm) pwm->state.period = period; } -static inline unsigned int pwm_get_period (const struct pwm_device *pwm) +static inline u64 pwm_get_period (const struct pwm_device *pwm) {struct pwm_state state;
@@ -126,7 +126,7 @@ static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int duty) pwm->state.duty_cycle = duty; } -static inline unsigned int pwm_get_duty_cycle (const struct pwm_device *pwm) +static inline u64 pwm_get_duty_cycle (const struct pwm_device *pwm) {struct pwm_state state;
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project