Convert PWM period and duty cycle to u64
Subsystems (15)
v9 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 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]/
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: stm32-lp: Use %llu format specifier for period
pwm: sun4i: Use 64-bit division function
backlight: pwm_bl: Use 64-bit division function
pwm: core: Convert period and duty cycle to u64
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 | 2 +- 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 ++++++------ 13 files changed, 25 insertions(+), 24 deletions(-)
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v9 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
@@ -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
Re: [PATCH v9 01/11] drm/i915: Use 64-bit division macro
Quoted 15 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using
DIV_ROUND_UP_ULLto handle a 64-bit dividend.Cc Jani Nikula <[email protected]>Cc Joonas Lahtinen <[email protected]>Cc David Airlie <[email protected]>Cc Daniel Vetter <[email protected]>Cc Chris Wilson <[email protected]>Cc "Ville Syrjälä" <[email protected]>Cc Rodrigo Vivi <[email protected]>Cc Maarten Lankhorst <[email protected]>
Quoted 1 line
Signed-off-by Guru Das Srinagesh <[email protected]>
Also ack for merging this via whichever tree you prefer; please let me know if you want me to take this via drm-intel.
Quoted 17 lines
--- 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 · 1 line
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v9 01/11] drm/i915: Use 64-bit division macro
Quoted 16 lines · Jani Nikula
Quoted 15 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using
DIV_ROUND_UP_ULLto handle a 64-bit dividend.Cc Jani Nikula <[email protected]>Cc Joonas Lahtinen <[email protected]>Cc David Airlie <[email protected]>Cc Daniel Vetter <[email protected]>Cc Chris Wilson <[email protected]>Cc "Ville Syrjälä" <[email protected]>Cc Rodrigo Vivi <[email protected]>Cc Maarten Lankhorst <[email protected]>
Quoted 3 lines
Quoted 1 line
Signed-off-by Guru Das Srinagesh <[email protected]>Reviewed-by Jani Nikula <[email protected]>
Thanks!
Quoted 2 lines
Also ack for merging this via whichever tree you prefer; please let me know if you want me to take this via drm-intel.
I'm not sure if this patch can be taken via drm-intel in isolation as it is part of a series... Will let you know if I need to make such a request.
Thank you.
Guru Das.
PATCH v9 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
@@ -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 v9 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 v9 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
Re: [PATCH v9 04/11] pwm: clps711x: Use 64-bit division macro
Quoted 18 lines · Guru Das Srinagesh
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using
DIV64_U64_ROUND_CLOSESTto handle a 64-bit divisor.Cc Alexander Shiyan <[email protected]>Cc Arnd Bergmann <[email protected]>Signed-off-by Guru Das Srinagesh <[email protected]>--- drivers/pwm/pwm-clps711x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/pwm/pwm-clps711x.c +0
-0
drivers/pwm/pwm-clps711x.c static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v) · line 47
Quoted 6 lines
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); }
Is it actually going to exceed U32_MAX? If not, a type cast may be more appropriate here than the expensive 64-bit division.
Arnd
Re: [PATCH v9 04/11] pwm: clps711x: Use 64-bit division macro
Quoted 6 lines · Arnd Bergmann
Quoted 6 lines
drivers/pwm/pwm-clps711x.c +0
-0@@ -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)
Quoted 8 lines
drivers/pwm/pwm-clps711x.c static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v) · line 47
Quoted 5 lines
drivers/pwm/pwm-clps711x.c +1
-1{/* Duty cycle 0..15 max */ -return DIV_ROUND_CLOSEST (v *0xf , pwm->args.period); +return DIV64_U64_ROUND_CLOSEST (v *0xf , pwm->args.period); }Is it actually going to exceed
U32_MAX? If not, a type cast may be more appropriate here than the expensive 64-bit division.
With the final change in this patch series, the framework will support periods that exceed U32_MAX. My concern is that using a typecast would mean that in those cases, this driver will not support > U32_MAX values. Using DIV64_U64_ROUND_CLOSEST makes the driver future proof and able to handle > U32_MAX values correctly. What do you think?
Thank you.
Guru Das.
Re: [PATCH v9 04/11] pwm: clps711x: Use 64-bit division macro
Quoted 17 lines · Guru Das Srinagesh
Quoted 6 lines · Arnd Bergmann
Quoted 6 lines
drivers/pwm/pwm-clps711x.c +0
-0@@ -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)Quoted 8 lines
drivers/pwm/pwm-clps711x.c static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v) · line 47
Quoted 5 lines
drivers/pwm/pwm-clps711x.c +1
-1{/* Duty cycle 0..15 max */ -return DIV_ROUND_CLOSEST (v *0xf , pwm->args.period); +return DIV64_U64_ROUND_CLOSEST (v *0xf , pwm->args.period); }Is it actually going to exceed
U32_MAX? If not, a type cast may be more appropriate here than the expensive 64-bit division.
Quoted 5 lines
With the final change in this patch series, the framework will support periods that exceed
U32_MAX. My concern is that using a typecast would mean that in those cases, this driver will not support >U32_MAXvalues. UsingDIV64_U64_ROUND_CLOSESTmakes the driver future proof and able to handle >U32_MAXvalues correctly. What do you think?
Ah, so if the period can actually be larger than U32_MAX, you need to handle that case. However, I see that the divident in this code (v * 0xf) is still a 32-bit number, so a correct and efficient implementation could be
if (pwm->args.period > (UINT_MAX / 0xf))
return 0;
return DIV_ROUND_CLOSEST(v * 0xf, (u32)pwm->args.period);Arnd
Re: [PATCH v9 04/11] pwm: clps711x: Use 64-bit division macro
Quoted 25 lines · Arnd Bergmann
Quoted 17 lines · Guru Das Srinagesh
Quoted 6 lines · Arnd Bergmann
Quoted 6 lines
drivers/pwm/pwm-clps711x.c +0
-0@@ -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)Quoted 8 lines
drivers/pwm/pwm-clps711x.c static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v) · line 47
Quoted 5 lines
drivers/pwm/pwm-clps711x.c +1
-1{/* Duty cycle 0..15 max */ -return DIV_ROUND_CLOSEST (v *0xf , pwm->args.period); +return DIV64_U64_ROUND_CLOSEST (v *0xf , pwm->args.period); }Is it actually going to exceed
U32_MAX? If not, a type cast may be more appropriate here than the expensive 64-bit division.Quoted 5 lines
With the final change in this patch series, the framework will support periods that exceed
U32_MAX. My concern is that using a typecast would mean that in those cases, this driver will not support >U32_MAXvalues. UsingDIV64_U64_ROUND_CLOSESTmakes the driver future proof and able to handle >U32_MAXvalues correctly. What do you think?
Quoted 5 lines
Ah, so if the period can actually be larger than
U32_MAX, you need to handle that case. However, I see that the divident in this code (v *0xf) is still a 32-bit number, so a correct and efficient implementation could beif (pwm->args.period > (UINT_MAX / 0xf))
Shouldn't the if condition be the following? Or am I missing something here?
if (pwm->args.period > (UINT_MAX / (v * 0xf)))
^^^^^^^^^Quoted 2 lines
return 0;return
DIV_ROUND_CLOSEST(v * 0xf, (u32)pwm->args.period);
Thank you.
Guru Das.
Re: [PATCH v9 04/11] pwm: clps711x: Use 64-bit division macro
Quoted 31 lines · Guru Das Srinagesh
Quoted 29 lines · Arnd Bergmann
Quoted 17 lines · Guru Das Srinagesh
Quoted 6 lines · Arnd Bergmann
Quoted 6 lines
drivers/pwm/pwm-clps711x.c +0
-0@@ -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)Quoted 8 lines
drivers/pwm/pwm-clps711x.c static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v) · line 47
Quoted 5 lines
drivers/pwm/pwm-clps711x.c +1
-1{/* Duty cycle 0..15 max */ -return DIV_ROUND_CLOSEST (v *0xf , pwm->args.period); +return DIV64_U64_ROUND_CLOSEST (v *0xf , pwm->args.period); }Is it actually going to exceed
U32_MAX? If not, a type cast may be more appropriate here than the expensive 64-bit division.Quoted 5 lines
With the final change in this patch series, the framework will support periods that exceed
U32_MAX. My concern is that using a typecast would mean that in those cases, this driver will not support >U32_MAXvalues. UsingDIV64_U64_ROUND_CLOSESTmakes the driver future proof and able to handle >U32_MAXvalues correctly. What do you think?Ah, so if the period can actually be larger than
U32_MAX, you need to handle that case. However, I see that the divident in this code (v *0xf) is still a 32-bit number, so a correct and efficient implementation could be
Quoted 7 lines
Quoted 1 line
if (pwm->args.period > (UINT_MAX / 0xf))Shouldn't the if condition be the following? Or am I missing something here?
if (pwm->args.period > (UINT_MAX / (v * 0xf))) ^^^^^^^^^
That would require performing a division, which is an external function call on ARMv4. My version just checks for an upper bound and completely avoids the division. You could also just check for ">UINT_MAX" if you find that clearer.
Arnd
Re: [PATCH v9 04/11] pwm: clps711x: Use 64-bit division macro
Quoted 37 lines · Arnd Bergmann
Quoted 36 lines · Guru Das Srinagesh
Quoted 25 lines · Arnd Bergmann
Quoted 17 lines · Guru Das Srinagesh
Quoted 6 lines · Arnd Bergmann
Quoted 6 lines
drivers/pwm/pwm-clps711x.c +0
-0@@ -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)Quoted 8 lines
drivers/pwm/pwm-clps711x.c static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v) · line 47
Quoted 5 lines
drivers/pwm/pwm-clps711x.c +1
-1{/* Duty cycle 0..15 max */ -return DIV_ROUND_CLOSEST (v *0xf , pwm->args.period); +return DIV64_U64_ROUND_CLOSEST (v *0xf , pwm->args.period); }Is it actually going to exceed
U32_MAX? If not, a type cast may be more appropriate here than the expensive 64-bit division.Quoted 5 lines
With the final change in this patch series, the framework will support periods that exceed
U32_MAX. My concern is that using a typecast would mean that in those cases, this driver will not support >U32_MAXvalues. UsingDIV64_U64_ROUND_CLOSESTmakes the driver future proof and able to handle >U32_MAXvalues correctly. What do you think?Quoted 5 lines
Ah, so if the period can actually be larger than
U32_MAX, you need to handle that case. However, I see that the divident in this code (v *0xf) is still a 32-bit number, so a correct and efficient implementation could beif (pwm->args.period > (UINT_MAX / 0xf))Shouldn't the if condition be the following? Or am I missing something here?
Quoted 7 lines
Quoted 2 lines
if (pwm->args.period > (UINT_MAX / (v * 0xf))) ^^^^^^^^^That would require performing a division, which is an external function call on ARMv4. My version just checks for an upper bound and completely avoids the division. You could also just check for ">UINT_MAX" if you find that clearer.
Thanks, have checked for UINT_MAX in v10 of my patchset that I just uploaded. Could you please review it?
Thank you.
Guru Das.
PATCH v9 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
@@ -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 v9 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.
--- 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
PATCH v9 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 v9 8/11 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
PATCH v9 9/11 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
PATCH v9 10/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
@@ -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
PATCH v9 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.
--- 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
kbuild test robot
build botRe: [PATCH v9 11/11] pwm: core: Convert period and duty cycle to u64
Thank you for the patch! Yet something to improve:
Hi Guru,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pwm/for-next]
[also build test ERROR on hwmon/hwmon-next linuxtv-media/master shawnguo/for-next stm32/stm32-next sunxi/sunxi/for-next v5.6-rc6] [cannot apply to drm-intel/for-linux-next next-20200317]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Guru-Das-Srinagesh/Convert-PWM-period-and-duty-cycle-to-u64/20200318-094102 base: https://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git for-next config: microblaze-randconfig-a001-20200318 (attached as .config) compiler: microblaze-linux-gcc (GCC) 9.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.2.0 make.cross ARCH=microblaze
If you fix the issue, kindly add following tag
All errors (new ones prefixed by >>):
microblaze-linux-ld: drivers/clk/clk-pwm.o: in function `clk_pwm_probe':
>> drivers/clk/clk-pwm.c:92: undefined reference to `__udivdi3'
.exit.data' referenced in section .exit.text' of drivers/tty/n_hdlc.o: defined in discarded section .exit.data' of drivers/tty/n_hdlc.o .exit.data' referenced in section .exit.text' of drivers/tty/n_hdlc.o: defined in discarded section .exit.data' of drivers/tty/n_hdlc.o
vim +92 drivers/clk/clk-pwm.c
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 66
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 67 static int clk_pwm_probe(struct platform_device *pdev)
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 68 {
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 69 struct device_node *node = pdev->dev.of_node;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 70 struct clk_init_data init;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 71 struct clk_pwm *clk_pwm;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 72 struct pwm_device *pwm;
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 73 struct pwm_args pargs;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 74 const char *clk_name;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 75 int ret;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 76
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 77 clk_pwm = devm_kzalloc(&pdev->dev, sizeof(*clk_pwm), GFP_KERNEL);
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 78 if (!clk_pwm)
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 79 return -ENOMEM;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 80
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 81 pwm = devm_pwm_get(&pdev->dev, NULL);
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 82 if (IS_ERR(pwm))
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 83 return PTR_ERR(pwm);
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 84
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 85 pwm_get_args(pwm, &pargs);
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 86 if (!pargs.period) {
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 87 dev_err(&pdev->dev, "invalid PWM period\n");
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 88 return -EINVAL;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 89 }
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 90
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 91 if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 @92 clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 93
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 94 if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 95 pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 96 dev_err(&pdev->dev,
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 97 "clock-frequency does not match PWM period\n");
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 98 return -EINVAL;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 99 }
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 100
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 101 /*
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 102 * FIXME: pwm_apply_args() should be removed when switching to the
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 103 * atomic PWM API.
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 104 */
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 105 pwm_apply_args(pwm);
dd0b38b7ca0d8c Boris Brezillon 2016-04-14 106 ret = pwm_config(pwm, (pargs.period + 1) >> 1, pargs.period);
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 107 if (ret < 0)
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 108 return ret;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 109
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 110 clk_name = node->name;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 111 of_property_read_string(node, "clock-output-names", &clk_name);
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 112
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 113 init.name = clk_name;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 114 init.ops = &clk_pwm_ops;
90b6c5c73c6904 Stephen Boyd 2019-04-25 115 init.flags = 0;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 116 init.num_parents = 0;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 117
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 118 clk_pwm->pwm = pwm;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 119 clk_pwm->hw.init = &init;
4cf915dfb8ede6 Stephen Boyd 2016-06-01 120 ret = devm_clk_hw_register(&pdev->dev, &clk_pwm->hw);
4cf915dfb8ede6 Stephen Boyd 2016-06-01 121 if (ret)
4cf915dfb8ede6 Stephen Boyd 2016-06-01 122 return ret;
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 123
4cf915dfb8ede6 Stephen Boyd 2016-06-01 124 return of_clk_add_hw_provider(node, of_clk_hw_simple_get, &clk_pwm->hw);
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 125 }
9a74ccdbbb8fa6 Philipp Zabel 2015-02-13 126 :::::: The code at line 92 was first introduced by commit
:::::: dd0b38b7ca0d8c8aadcf8a17d7c90d36ab8ab6e4 clk: pwm: Use pwm_get_args() where appropriate
:::::: TO: Boris Brezillon <[email protected]> :::::: CC: Thierry Reding <[email protected]>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org