Convert PWM period and duty cycle to u64
Subsystems (15)
v16 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 v15:
- Rebased to tip of for-next.
Changes from v14:
- Collected Uwe's Acked-by for the pwm core patch.
- Addressed comments in pwm-clps711x.c.
Changes from v13:
- Pruned cc-list and added same (reduced) set of reviewers to all patches.
- Added Lee Jones' Acked-by to the pwm_bl.c patch.
- Added Jani Nikula's Acked-by to intel-panel.c patch.
- Added Stephen Boyd's Acked-by to pwm-clk.c patch.
- Addressed Geert's review comments in clps711x.c patch.
Changes from v12:
- Rebased to tip of for-next
- Collected Acked-by for sun4i
- Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as a result
Changes from v11:
- Rebased to tip of for-next.
- Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
- Squished stm32-lp.c change with final patch in series
- sun4i: Used nsecs_to_jiffies()
- imx27: Added overflow handling logic
- clps711x: Corrected the if condition for skipping the division
- clk: pwm: Reverted to v8 version, added check to prevent division-by-zero
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/20200312190859.GA19605@xxxxxxxxxxxxxx/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.html
Guru Das Srinagesh (11):
drm/i915: Use 64-bit division macro
hwmon: pwm-fan: Use 64-bit division macro
ir-rx51: Use 64-bit division macro
pwm: clps711x: Use 64-bit division macro
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: sun4i: Use nsecs_to_jiffies to avoid a division
backlight: pwm_bl: Use 64-bit division function
clk: pwm: Use 64-bit division function
pwm: core: Convert period and duty cycle to u64
drivers/clk/clk-pwm.c | 7 ++++- 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 | 14 ++++----- drivers/pwm/pwm-clps711x.c | 2 +- drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c | 48 ++++++++++++++++++++++++++---- 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, 77 insertions(+), 32 deletions(-)
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v16 1/11 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
@@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,return retval; } - level =DIV_ROUND_UP (pwm_get_duty_cycle (panel->backlight.pwm) *100 , + level =DIV_ROUND_UP_ULL (pwm_get_duty_cycle (panel->backlight.pwm) *100 ,CRC_PMIC_PWM_PERIOD_NS ); panel->backlight.level =intel_panel_compute_brightness (connector, level);
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v16 2/11 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
@@ -447,7 +447,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 v16 3/11 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 v16 4/11 pwm: clps711x: 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-clps711x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pwm/pwm-clps711x.c +1 -1
@@ -43,7 +43,7 @@ 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); +return DIV64_U64_ROUND_CLOSEST (v *0xf , 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
PATCH v16 5/11 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
@@ -124,7 +124,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 v16 6/11 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.
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.
--- drivers/pwm/pwm-imx27.c | 48 +++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 43 insertions(+), 5 deletions(-)
drivers/pwm/pwm-imx27.c +43 -5
@@ -202,7 +202,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);
@@ -212,6 +212,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) {
@@ -226,10 +265,9 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,pwm_get_state (pwm, &cstate); clkrate =clk_get_rate (imx->clk_per); - c = clkrate * state->period; - -do_div (c,NSEC_PER_SEC ); - period_cycles = c; + ret =pwm_imx27_calc_period_cycles (state, clkrate, &period_cycles); +if (ret) +return ret; prescale = period_cycles /0x10000 +1 ;
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v16 06/11] pwm: imx27: Use 64-bit division macro and function
Hello,
Quoted 74 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_ROUND_UP_ULLto handle a 64-bit dividend, anddiv64_u64to handle a 64-bit divisor.Also handle a possible overflow in the calculation of
period_cycleswhen bothclk_rateand period are large numbers. This logic was unit-tested out by calculatingperiod_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)----------------------------------------------------------------------------
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 <[email protected]>Cc Sascha Hauer <[email protected]>Cc Pengutronix Kernel Team <[email protected]>Cc Fabio Estevam <[email protected]>Cc NXP Linux Team <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>--- drivers/pwm/pwm-imx27.c | 48 +++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 43 insertions(+), 5 deletions(-)drivers/pwm/pwm-imx27.c +23
-1@@ -202,7 +202,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);@@ -212,6 +212,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 ))) {
drivers/pwm/pwm-imx27.c static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip, · line 246
Quoted 10 lines
drivers/pwm/pwm-imx27.c +10
-0+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;
} else {
???Quoted 11 lines
drivers/pwm/pwm-imx27.c +7
-0+ } + + *period_cycles = c; + +return 0 ; +} +static int pwm_imx27_apply (struct pwm_chip *chip,struct pwm_device *pwm,const struct pwm_state *state) {
drivers/pwm/pwm-imx27.c static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, · line 270
Quoted 10 lines
drivers/pwm/pwm-imx27.c +3
-4@@ -226,10 +265,9 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,pwm_get_state (pwm, &cstate); clkrate =clk_get_rate (imx->clk_per); - c = clkrate * state->period; - -do_div (c,NSEC_PER_SEC ); - period_cycles = c; + ret =pwm_imx27_calc_period_cycles (state, clkrate, &period_cycles); +if (ret) +return ret;
I would expect this problem to be generic enough that it justifies a function in pwm-core (or even more generic?).
Something like:
/*
* calculates *result = a * b / c.
* Returns false on overflow (and doesn't assign result in this
* case); true otherwise.
*/
static inline bool multdiv(u64 *result, u64 a, u64 b, u64 c)
I'd split this out in a separate patch though? (Or is imx27 the only driver in this series with this problem?)
Best regards
Uwe
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
PATCH v16 6/11 pwm: imx27: 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_UP_ULL to handle a 64-bit dividend.
--- drivers/pwm/pwm-imx27.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pwm/pwm-imx27.c +1 -1
@@ -202,7 +202,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);
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v16 06/11] pwm: imx27: Use 64-bit division macro
Quoted 15 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_ROUND_UP_ULLto handle a 64-bit dividend.Signed-off-by Guru Das Srinagesh <[email protected]>--- drivers/pwm/pwm-imx27.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/pwm/pwm-imx27.c +0
-0
drivers/pwm/pwm-imx27.c static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip, · line 208
Quoted 8 lines
drivers/pwm/pwm-imx27.c +1
-1@@ -202,7 +202,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);
Please disregard this patch, it was sent by mistake. The correct patch is [1].
Thank you.
Guru Das.
PATCH v16 7/11 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 v16 8/11 pwm: sun4i: Use nsecs_to_jiffies to avoid a division
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 nsecs_to_jiffies() which does away with the need for a division operation.
--- drivers/pwm/pwm-sun4i.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pwm/pwm-sun4i.c +1 -1
@@ -285,7 +285,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 ); +nsecs_to_jiffies (cstate.period +1000 );if (state->polarity !=PWM_POLARITY_NORMAL ) ctrl &= ~BIT_CH (PWM_ACT_STATE , pwm->hwpwm);
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v16 9/11 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
@@ -606,7 +606,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
PATCH v16 10/11 clk: pwm: Use 64-bit division function
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() to handle a 64-bit divisor.
Also ensure that divide-by-zero (with fixed_rate as denominator) does not happen with an explicit check with probe failure as a consequence.
--- drivers/clk/clk-pwm.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/clk/clk-pwm.c +6 -1
@@ -89,7 +89,12 @@ static int clk_pwm_probe(struct platform_device *pdev) }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 =div64_u64 (NSEC_PER_SEC , pargs.period); + +if (!clk_pwm->fixed_rate) { +dev_err (&pdev->dev,"fixed_rate cannot be zero\n" ); +return -EINVAL ; + }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
PATCH v16 11/11 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.
Also use the right format specifiers in debug prints in both core.c as well as pwm-stm32-lp.c.
--- drivers/pwm/core.c | 14 +++++++------- drivers/pwm/pwm-stm32-lp.c | 2 +- drivers/pwm/sysfs.c | 8 ++++---- include/linux/pwm.h | 12 ++++++------ 4 files changed, 18 insertions(+), 18 deletions(-)
drivers/pwm/core.c +7 -7
@@ -510,12 +510,12 @@ static void pwm_apply_state_debug(struct pwm_device *pwm, last->period > s2.period && last->period <= state->period)dev_warn (chip->dev, -".apply didn't pick the best available period (requested: %u, applied: %u, possible: %u)\n" , +".apply didn't pick the best available period (requested: %llu, applied: %llu, possible: %llu)\n" , state->period, s2.period, last->period);if (state->enabled && state->period < s2.period)dev_warn (chip->dev, -".apply is supposed to round down period (requested: %u, applied: %u)\n" , +".apply is supposed to round down period (requested: %llu, applied: %llu)\n" , state->period, s2.period); if (state->enabled &&
@@ -524,14 +524,14 @@ static void pwm_apply_state_debug(struct pwm_device *pwm, last->duty_cycle > s2.duty_cycle && last->duty_cycle <= state->duty_cycle)dev_warn (chip->dev, -".apply didn't pick the best available duty cycle (requested: %u/%u, applied: %u/%u, possible: %u/%u)\n" , +".apply didn't pick the best available duty cycle (requested: %llu/%llu, applied: %llu/%llu, possible: %llu/%llu)\n" , state->duty_cycle, state->period, s2.duty_cycle, s2.period, last->duty_cycle, last->period);if (state->enabled && state->duty_cycle < s2.duty_cycle)dev_warn (chip->dev, -".apply is supposed to round down duty_cycle (requested: %u/%u, applied: %u/%u)\n" , +".apply is supposed to round down duty_cycle (requested: %llu/%llu, applied: %llu/%llu)\n" , state->duty_cycle, state->period, s2.duty_cycle, s2.period);
@@ -558,7 +558,7 @@ static void pwm_apply_state_debug(struct pwm_device *pwm, (s1.enabled && s1.period != last->period) || (s1.enabled && s1.duty_cycle != last->duty_cycle)) {dev_err (chip->dev, -".apply is not idempotent (ena=%d pol=%d %u/%u) -> (ena=%d pol=%d %u/%u)\n" , +".apply is not idempotent (ena=%d pol=%d %llu/%llu) -> (ena=%d pol=%d %llu/%llu)\n" , s1.enabled, s1.polarity, s1.duty_cycle, s1.period, last->enabled, last->polarity, last->duty_cycle, last->period);
@@ -1284,8 +1284,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/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 ; }
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; };
@@ -107,13 +107,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;
@@ -128,7 +128,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
Quoted 118 lines · Guru Das Srinagesh
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 v15:
- Rebased to tip of for-next.Changes from v14:
- Collected Uwe's Acked-by for the pwm core patch.
- Addressed comments inpwm-clps711x.c.Changes from v13:
- Pruned cc-list and added same (reduced) set of reviewers to all patches.
- Added Lee Jones' Acked-by to thepwm_bl.cpatch.
- Added Jani Nikula's Acked-by tointel-panel.cpatch.
- Added Stephen Boyd's Acked-by topwm-clk.cpatch.
- Addressed Geert's review comments inclps711x.cpatch.Changes from v12:
- Rebased to tip of for-next
- Collected Acked-by for sun4i
- Reworked patch forintel-panel.cdue to rebase, dropped Jani's Acked-by as a resultChanges from v11:
- Rebased to tip of for-next.
- Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
- Squishedstm32-lp.cchange with final patch in series
- sun4i: Usednsecs_to_jiffies()
- imx27: Added overflow handling logic
- clps711x: Corrected the if condition for skipping the division
- clk: pwm: Reverted to v8 version, added check to prevent division-by-zeroChanges 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 theclk-pwm.cpatch 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 toclk-pwm.cfor reasons mentiond in [2]
- Expanded audience of unreviewed patchesChanges from v7:
- Changed commit messages of all patches to be brief and to the point.
- Added explanation of change in cover letter.
- Dropped change topwm-sti.cas upon review it was unnecessary as structpwm_captureis 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 structpwm_captureto u64 for reasons mentionedin https://www.spinics.net/lists/linux-pwm/msg11541.htmlChanges 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_divis 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 adev_dbginpwm-stm32-lp.c, thanks to kbuild test robot
- Added a couple of fixes topwm-imx-tpm.candpwm-sifive.cChanges 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 setpwm_stateparameters as usual.[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/20200312190859.GA19605@xxxxxxxxxxxxxx/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.htmlGuru Das Srinagesh (11):
drm/i915: Use 64-bit division macro
hwmon: pwm-fan: Use 64-bit division macro
ir-rx51: Use 64-bit division macro
pwm: clps711x: Use 64-bit division macro
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: sun4i: Usensecs_to_jiffiesto avoid a division
backlight:pwm_bl: Use 64-bit division function
clk: pwm: Use 64-bit division function
pwm: core: Convert period and duty cycle to u64
Quoted 17 lines
drivers/clk/clk-pwm.c | 7 ++++- 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 | 14 ++++----- drivers/pwm/pwm-clps711x.c | 2 +- drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c | 48 ++++++++++++++++++++++++++---- 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, 77 insertions(+), 32 deletions(-)
Hello Thierry, Uwe, Lee,
Gentle reminder for this patch series :) Earlier discussions on next steps were as per [1] and [2].
[1] https://lore.kernel.org/lkml/20200522125028.GG2163848@ulmo/
[2] https://lore.kernel.org/lkml/20200526065935.GA3628@dell/
Thank you.
Guru Das.
Quoted 137 lines · Guru Das Srinagesh
Quoted 118 lines · Guru Das Srinagesh
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 v15:
- Rebased to tip of for-next.Changes from v14:
- Collected Uwe's Acked-by for the pwm core patch.
- Addressed comments inpwm-clps711x.c.Changes from v13:
- Pruned cc-list and added same (reduced) set of reviewers to all patches.
- Added Lee Jones' Acked-by to thepwm_bl.cpatch.
- Added Jani Nikula's Acked-by tointel-panel.cpatch.
- Added Stephen Boyd's Acked-by topwm-clk.cpatch.
- Addressed Geert's review comments inclps711x.cpatch.Changes from v12:
- Rebased to tip of for-next
- Collected Acked-by for sun4i
- Reworked patch forintel-panel.cdue to rebase, dropped Jani's Acked-by as a resultChanges from v11:
- Rebased to tip of for-next.
- Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
- Squishedstm32-lp.cchange with final patch in series
- sun4i: Usednsecs_to_jiffies()
- imx27: Added overflow handling logic
- clps711x: Corrected the if condition for skipping the division
- clk: pwm: Reverted to v8 version, added check to prevent division-by-zeroChanges 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 theclk-pwm.cpatch 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 toclk-pwm.cfor reasons mentiond in [2]
- Expanded audience of unreviewed patchesChanges from v7:
- Changed commit messages of all patches to be brief and to the point.
- Added explanation of change in cover letter.
- Dropped change topwm-sti.cas upon review it was unnecessary as structpwm_captureis 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 structpwm_captureto u64 for reasons mentionedin https://www.spinics.net/lists/linux-pwm/msg11541.htmlChanges 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_divis 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 adev_dbginpwm-stm32-lp.c, thanks to kbuild test robot
- Added a couple of fixes topwm-imx-tpm.candpwm-sifive.cChanges 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 setpwm_stateparameters as usual.[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/20200312190859.GA19605@xxxxxxxxxxxxxx/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.htmlGuru Das Srinagesh (11):
drm/i915: Use 64-bit division macro
hwmon: pwm-fan: Use 64-bit division macro
ir-rx51: Use 64-bit division macro
pwm: clps711x: Use 64-bit division macro
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: sun4i: Usensecs_to_jiffiesto avoid a division
backlight:pwm_bl: Use 64-bit division function
clk: pwm: Use 64-bit division function
pwm: core: Convert period and duty cycle to u64Quoted 17 lines
drivers/clk/clk-pwm.c | 7 ++++- 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 | 14 ++++----- drivers/pwm/pwm-clps711x.c | 2 +- drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c | 48 ++++++++++++++++++++++++++---- 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, 77 insertions(+), 32 deletions(-)
Quoted 7 lines
Hello Thierry, Uwe, Lee,
Gentle reminder for this patch series :) Earlier discussions on next steps were as per [1] and [2].
[1] https://lore.kernel.org/lkml/20200522125028.GG2163848@ulmo/
[2] https://lore.kernel.org/lkml/20200526065935.GA3628@dell/
Not much happens during the merge-window.
I don't have insider info on this, but my best guess is that Thierry will pick this up once -rc1 has been released.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 135 lines · Guru Das Srinagesh
Quoted 134 lines · Guru Das Srinagesh
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 v15:
- Rebased to tip of for-next.Changes from v14:
- Collected Uwe's Acked-by for the pwm core patch.
- Addressed comments inpwm-clps711x.c.Changes from v13:
- Pruned cc-list and added same (reduced) set of reviewers to all patches.
- Added Lee Jones' Acked-by to thepwm_bl.cpatch.
- Added Jani Nikula's Acked-by tointel-panel.cpatch.
- Added Stephen Boyd's Acked-by topwm-clk.cpatch.
- Addressed Geert's review comments inclps711x.cpatch.Changes from v12:
- Rebased to tip of for-next
- Collected Acked-by for sun4i
- Reworked patch forintel-panel.cdue to rebase, dropped Jani's Acked-by as a resultChanges from v11:
- Rebased to tip of for-next.
- Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
- Squishedstm32-lp.cchange with final patch in series
- sun4i: Usednsecs_to_jiffies()
- imx27: Added overflow handling logic
- clps711x: Corrected the if condition for skipping the division
- clk: pwm: Reverted to v8 version, added check to prevent division-by-zeroChanges 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 theclk-pwm.cpatch 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 toclk-pwm.cfor reasons mentiond in [2]
- Expanded audience of unreviewed patchesChanges from v7:
- Changed commit messages of all patches to be brief and to the point.
- Added explanation of change in cover letter.
- Dropped change topwm-sti.cas upon review it was unnecessary as structpwm_captureis 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 structpwm_captureto u64 for reasons mentionedin https://www.spinics.net/lists/linux-pwm/msg11541.htmlChanges 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_divis 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 adev_dbginpwm-stm32-lp.c, thanks to kbuild test robot
- Added a couple of fixes topwm-imx-tpm.candpwm-sifive.cChanges 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 setpwm_stateparameters as usual.[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/20200312190859.GA19605@xxxxxxxxxxxxxx/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.htmlGuru Das Srinagesh (11):
drm/i915: Use 64-bit division macro
hwmon: pwm-fan: Use 64-bit division macro
ir-rx51: Use 64-bit division macro
pwm: clps711x: Use 64-bit division macro
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: sun4i: Usensecs_to_jiffiesto avoid a division
backlight:pwm_bl: Use 64-bit division function
clk: pwm: Use 64-bit division function
pwm: core: Convert period and duty cycle to u64drivers/clk/clk-pwm.c | 7 ++++- 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 | 14 ++++----- drivers/pwm/pwm-clps711x.c | 2 +- drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c | 48 ++++++++++++++++++++++++++---- 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, 77 insertions(+), 32 deletions(-)
Quoted 6 lines
Quoted 1 line
Hello Thierry, Uwe, Lee,
Gentle reminder for this patch series :) Earlier discussions on next steps were as per [1] and [2].
Hi Guru,
I ended up deciding against queueing this for v5.8-rc1 because I want this to soak for a bit in linux-next. I'll apply them early next week after v5.8-rc1 is out.
Thierry
Quoted 140 lines · Thierry Reding
Quoted 139 lines · Guru Das Srinagesh
Quoted 118 lines · Guru Das Srinagesh
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 v15:
- Rebased to tip of for-next.Changes from v14:
- Collected Uwe's Acked-by for the pwm core patch.
- Addressed comments inpwm-clps711x.c.Changes from v13:
- Pruned cc-list and added same (reduced) set of reviewers to all patches.
- Added Lee Jones' Acked-by to thepwm_bl.cpatch.
- Added Jani Nikula's Acked-by tointel-panel.cpatch.
- Added Stephen Boyd's Acked-by topwm-clk.cpatch.
- Addressed Geert's review comments inclps711x.cpatch.Changes from v12:
- Rebased to tip of for-next
- Collected Acked-by for sun4i
- Reworked patch forintel-panel.cdue to rebase, dropped Jani's Acked-by as a resultChanges from v11:
- Rebased to tip of for-next.
- Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
- Squishedstm32-lp.cchange with final patch in series
- sun4i: Usednsecs_to_jiffies()
- imx27: Added overflow handling logic
- clps711x: Corrected the if condition for skipping the division
- clk: pwm: Reverted to v8 version, added check to prevent division-by-zeroChanges 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 theclk-pwm.cpatch 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 toclk-pwm.cfor reasons mentiond in [2]
- Expanded audience of unreviewed patchesChanges from v7:
- Changed commit messages of all patches to be brief and to the point.
- Added explanation of change in cover letter.
- Dropped change topwm-sti.cas upon review it was unnecessary as structpwm_captureis 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 structpwm_captureto u64 for reasons mentionedin https://www.spinics.net/lists/linux-pwm/msg11541.htmlChanges 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_divis 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 adev_dbginpwm-stm32-lp.c, thanks to kbuild test robot
- Added a couple of fixes topwm-imx-tpm.candpwm-sifive.cChanges 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 setpwm_stateparameters as usual.[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/20200312190859.GA19605@xxxxxxxxxxxxxx/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.htmlGuru Das Srinagesh (11):
drm/i915: Use 64-bit division macro
hwmon: pwm-fan: Use 64-bit division macro
ir-rx51: Use 64-bit division macro
pwm: clps711x: Use 64-bit division macro
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: sun4i: Usensecs_to_jiffiesto avoid a division
backlight:pwm_bl: Use 64-bit division function
clk: pwm: Use 64-bit division function
pwm: core: Convert period and duty cycle to u64Quoted 17 lines
drivers/clk/clk-pwm.c | 7 ++++- 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 | 14 ++++----- drivers/pwm/pwm-clps711x.c | 2 +- drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c | 48 ++++++++++++++++++++++++++---- 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, 77 insertions(+), 32 deletions(-)Hello Thierry, Uwe, Lee,
Quoted 8 lines
Quoted 2 lines
Gentle reminder for this patch series :) Earlier discussions on next steps were as per [1] and [2].
Hi Guru,
I ended up deciding against queueing this for v5.8-rc1 because I want this to soak for a bit in linux-next. I'll apply them early next week after v5.8-rc1 is out.
Thank you for the update, Thierry.
Thank you.
Guru Das.