* [PATCH v13 1/5] riscv: dts: sifive: unleashed/unmatched: Remove PWM controlled LED's active-low properties
2025-04-23 9:04 [PATCH v13 0/5] Change PWM-controlled LED pin active mode and algorithm Nylon Chen
@ 2025-04-23 9:04 ` Nylon Chen
2025-04-23 9:04 ` [PATCH v13 2/5] pwm: sifive: change the PWM algorithm Nylon Chen
` (3 subsequent siblings)
4 siblings, 0 replies; 7+ messages in thread
From: Nylon Chen @ 2025-04-23 9:04 UTC (permalink / raw)
To: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Samuel Holland, Uwe Kleine-König
Cc: linux-riscv, devicetree, linux-kernel, linux-pwm, Nylon Chen,
Conor Dooley, Vincent Chen
This removes the active-low properties of the PWM-controlled LEDs in
the HiFive Unmatched device tree.
The reference is hifive-unleashed-a00.pdf[0] and hifive-unmatched-schematics-v3.pdf[1].
Link: https://sifive.cdn.prismic.io/sifive/c52a8e32-05ce-4aaf-95c8-7bf8453f8698_hifive-unleashed-a00-schematics-1.pdf [0]
Link: https://sifive.cdn.prismic.io/sifive/6a06d6c0-6e66-49b5-8e9e-e68ce76f4192_hifive-unmatched-schematics-v3.pdf [1]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Nylon Chen <nylon.chen@sifive.com>
---
arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 12 ++++--------
arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts | 12 ++++--------
2 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
index 900a50526d77..06731b8c7bc3 100644
--- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
+++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
@@ -49,32 +49,28 @@ led-controller {
compatible = "pwm-leds";
led-d1 {
- pwms = <&pwm0 0 7812500 PWM_POLARITY_INVERTED>;
- active-low;
+ pwms = <&pwm0 0 7812500 0>;
color = <LED_COLOR_ID_GREEN>;
max-brightness = <255>;
label = "d1";
};
led-d2 {
- pwms = <&pwm0 1 7812500 PWM_POLARITY_INVERTED>;
- active-low;
+ pwms = <&pwm0 1 7812500 0>;
color = <LED_COLOR_ID_GREEN>;
max-brightness = <255>;
label = "d2";
};
led-d3 {
- pwms = <&pwm0 2 7812500 PWM_POLARITY_INVERTED>;
- active-low;
+ pwms = <&pwm0 2 7812500 0>;
color = <LED_COLOR_ID_GREEN>;
max-brightness = <255>;
label = "d3";
};
led-d4 {
- pwms = <&pwm0 3 7812500 PWM_POLARITY_INVERTED>;
- active-low;
+ pwms = <&pwm0 3 7812500 0>;
color = <LED_COLOR_ID_GREEN>;
max-brightness = <255>;
label = "d4";
diff --git a/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts b/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
index 72b87b08ab44..03ce2cee4e97 100644
--- a/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
+++ b/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
@@ -51,8 +51,7 @@ led-controller-1 {
compatible = "pwm-leds";
led-d12 {
- pwms = <&pwm0 0 7812500 PWM_POLARITY_INVERTED>;
- active-low;
+ pwms = <&pwm0 0 7812500 0>;
color = <LED_COLOR_ID_GREEN>;
max-brightness = <255>;
label = "d12";
@@ -68,20 +67,17 @@ multi-led {
label = "d2";
led-red {
- pwms = <&pwm0 2 7812500 PWM_POLARITY_INVERTED>;
- active-low;
+ pwms = <&pwm0 2 7812500 0>;
color = <LED_COLOR_ID_RED>;
};
led-green {
- pwms = <&pwm0 1 7812500 PWM_POLARITY_INVERTED>;
- active-low;
+ pwms = <&pwm0 1 7812500 0>;
color = <LED_COLOR_ID_GREEN>;
};
led-blue {
- pwms = <&pwm0 3 7812500 PWM_POLARITY_INVERTED>;
- active-low;
+ pwms = <&pwm0 3 7812500 0>;
color = <LED_COLOR_ID_BLUE>;
};
};
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH v13 2/5] pwm: sifive: change the PWM algorithm
2025-04-23 9:04 [PATCH v13 0/5] Change PWM-controlled LED pin active mode and algorithm Nylon Chen
2025-04-23 9:04 ` [PATCH v13 1/5] riscv: dts: sifive: unleashed/unmatched: Remove PWM controlled LED's active-low properties Nylon Chen
@ 2025-04-23 9:04 ` Nylon Chen
2025-04-23 9:04 ` [PATCH v13 3/5] pwm: sifive: Fix the error in the idempotent test within the pwm_apply_state_debug function Nylon Chen
` (2 subsequent siblings)
4 siblings, 0 replies; 7+ messages in thread
From: Nylon Chen @ 2025-04-23 9:04 UTC (permalink / raw)
To: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Samuel Holland, Uwe Kleine-König
Cc: linux-riscv, devicetree, linux-kernel, linux-pwm, Nylon Chen,
Zong Li, Vincent Chen
The `frac` variable represents the pulse inactive time, and the result
of this algorithm is the pulse active time. Therefore, we must reverse the result.
The reference is SiFive FU740-C000 Manual[0]
Link: https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu740-c000-manual-v1p6.pdf [0]
Co-developed-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Zong Li <zong.li@sifive.com>
Co-developed-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Nylon Chen <nylon.chen@sifive.com>
---
drivers/pwm/pwm-sifive.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index d5b647e6be78..bb9146267bc5 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -110,9 +110,10 @@ static int pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state)
{
struct pwm_sifive_ddata *ddata = pwm_sifive_chip_to_ddata(chip);
- u32 duty, val;
+ u32 duty, val, inactive;
- duty = readl(ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
+ inactive = readl(ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
+ duty = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - inactive;
state->enabled = duty > 0;
@@ -123,7 +124,7 @@ static int pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
state->period = ddata->real_period;
state->duty_cycle =
(u64)duty * ddata->real_period >> PWM_SIFIVE_CMPWIDTH;
- state->polarity = PWM_POLARITY_INVERSED;
+ state->polarity = PWM_POLARITY_NORMAL;
return 0;
}
@@ -137,9 +138,9 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
unsigned long long num;
bool enabled;
int ret = 0;
- u32 frac;
+ u32 frac, inactive;
- if (state->polarity != PWM_POLARITY_INVERSED)
+ if (state->polarity != PWM_POLARITY_NORMAL)
return -EINVAL;
cur_state = pwm->state;
@@ -157,8 +158,9 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
*/
num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
- /* The hardware cannot generate a 100% duty cycle */
+ /* The hardware cannot generate a 0% duty cycle */
frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
+ inactive = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
mutex_lock(&ddata->lock);
if (state->period != ddata->approx_period) {
@@ -190,7 +192,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
}
}
- writel(frac, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
+ writel(inactive, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
if (!state->enabled)
clk_disable(ddata->clk);
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH v13 3/5] pwm: sifive: Fix the error in the idempotent test within the pwm_apply_state_debug function
2025-04-23 9:04 [PATCH v13 0/5] Change PWM-controlled LED pin active mode and algorithm Nylon Chen
2025-04-23 9:04 ` [PATCH v13 1/5] riscv: dts: sifive: unleashed/unmatched: Remove PWM controlled LED's active-low properties Nylon Chen
2025-04-23 9:04 ` [PATCH v13 2/5] pwm: sifive: change the PWM algorithm Nylon Chen
@ 2025-04-23 9:04 ` Nylon Chen
2025-04-23 9:04 ` [PATCH v13 4/5] pwm: sifive: Fix rounding issues in apply and get_state functions Nylon Chen
2025-04-23 9:04 ` [PATCH v13 5/5] pwm: sifive: clarify inverted compare logic in comments Nylon Chen
4 siblings, 0 replies; 7+ messages in thread
From: Nylon Chen @ 2025-04-23 9:04 UTC (permalink / raw)
To: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Samuel Holland, Uwe Kleine-König
Cc: linux-riscv, devicetree, linux-kernel, linux-pwm, Nylon Chen,
Zong Li
Round the result to the nearest whole number. This ensures that real_period
is always a reasonable integer that is not lower than the actual value.
e.g.
$ echo 110 > /sys/devices/platform/led-controller-1/leds/d12/brightness
$ .apply is not idempotent (ena=1 pol=0 1739692/4032985) -> (ena=1 pol=0
1739630/4032985)
Co-developed-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Nylon Chen <nylon.chen@sifive.com>
---
drivers/pwm/pwm-sifive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index bb9146267bc5..6259f8500f71 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -101,7 +101,7 @@ static void pwm_sifive_update_clock(struct pwm_sifive_ddata *ddata,
/* As scale <= 15 the shift operation cannot overflow. */
num = (unsigned long long)NSEC_PER_SEC << (PWM_SIFIVE_CMPWIDTH + scale);
- ddata->real_period = div64_ul(num, rate);
+ ddata->real_period = DIV_ROUND_UP_ULL(num, rate);
dev_dbg(ddata->parent,
"New real_period = %u ns\n", ddata->real_period);
}
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH v13 4/5] pwm: sifive: Fix rounding issues in apply and get_state functions
2025-04-23 9:04 [PATCH v13 0/5] Change PWM-controlled LED pin active mode and algorithm Nylon Chen
` (2 preceding siblings ...)
2025-04-23 9:04 ` [PATCH v13 3/5] pwm: sifive: Fix the error in the idempotent test within the pwm_apply_state_debug function Nylon Chen
@ 2025-04-23 9:04 ` Nylon Chen
2025-05-07 19:23 ` kernel test robot
2025-04-23 9:04 ` [PATCH v13 5/5] pwm: sifive: clarify inverted compare logic in comments Nylon Chen
4 siblings, 1 reply; 7+ messages in thread
From: Nylon Chen @ 2025-04-23 9:04 UTC (permalink / raw)
To: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Samuel Holland, Uwe Kleine-König
Cc: linux-riscv, devicetree, linux-kernel, linux-pwm, Nylon Chen,
Zong Li
Fix PWM apply and get_state rounding to ensure consistency between
setting and reading values
This fixes the reported errors:
pwm-sifive 10021000.pwm: .apply is supposed to round down
duty_cycle (requested: 360/504000, applied: 361/504124)
pwm-sifive 10021000.pwm: .apply is supposed to round down
period (requested: 504000, applied: 504124)
Co-developed-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Nylon Chen <nylon.chen@sifive.com>
---
drivers/pwm/pwm-sifive.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index 6259f8500f71..4cf3e715fd84 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -122,8 +122,8 @@ static int pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
state->enabled = false;
state->period = ddata->real_period;
- state->duty_cycle =
- (u64)duty * ddata->real_period >> PWM_SIFIVE_CMPWIDTH;
+ state->duty_cycle = DIV_ROUND_UP_ULL((u64)duty * ddata->real_period,
+ (1U << PWM_SIFIVE_CMPWIDTH));
state->polarity = PWM_POLARITY_NORMAL;
return 0;
@@ -157,7 +157,8 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
* consecutively
*/
num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
- frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
+ frac = num;
+ do_div(frac, state->period);
/* The hardware cannot generate a 0% duty cycle */
frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
inactive = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v13 4/5] pwm: sifive: Fix rounding issues in apply and get_state functions
2025-04-23 9:04 ` [PATCH v13 4/5] pwm: sifive: Fix rounding issues in apply and get_state functions Nylon Chen
@ 2025-05-07 19:23 ` kernel test robot
0 siblings, 0 replies; 7+ messages in thread
From: kernel test robot @ 2025-05-07 19:23 UTC (permalink / raw)
To: Nylon Chen, Conor Dooley, Rob Herring, Krzysztof Kozlowski,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Samuel Holland,
Uwe Kleine-König
Cc: llvm, oe-kbuild-all, linux-riscv, devicetree, linux-kernel,
linux-pwm, Nylon Chen, Zong Li
Hi Nylon,
kernel test robot noticed the following build errors:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v6.15-rc5 next-20250507]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Nylon-Chen/riscv-dts-sifive-unleashed-unmatched-Remove-PWM-controlled-LED-s-active-low-properties/20250423-165906
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/20250423090446.294846-5-nylon.chen%40sifive.com
patch subject: [PATCH v13 4/5] pwm: sifive: Fix rounding issues in apply and get_state functions
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20250508/202505080303.dBfU5YMS-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250508/202505080303.dBfU5YMS-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505080303.dBfU5YMS-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
>> drivers/pwm/pwm-sifive.c:161:2: warning: comparison of distinct pointer types ('typeof ((frac)) *' (aka 'unsigned int *') and 'uint64_t *' (aka 'unsigned long long *')) [-Wcompare-distinct-pointer-types]
161 | do_div(frac, state->period);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/div64.h:183:28: note: expanded from macro 'do_div'
183 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
| ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
>> drivers/pwm/pwm-sifive.c:161:2: error: incompatible pointer types passing 'u32 *' (aka 'unsigned int *') to parameter of type 'uint64_t *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types]
161 | do_div(frac, state->period);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/div64.h:199:22: note: expanded from macro 'do_div'
199 | __rem = __div64_32(&(n), __base); \
| ^~~~
include/asm-generic/div64.h:174:38: note: passing argument to parameter 'dividend' here
174 | extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
| ^
>> drivers/pwm/pwm-sifive.c:161:2: warning: shift count >= width of type [-Wshift-count-overflow]
161 | do_div(frac, state->period);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/div64.h:195:25: note: expanded from macro 'do_div'
195 | } else if (likely(((n) >> 32) == 0)) { \
| ^ ~~
include/linux/compiler.h:76:40: note: expanded from macro 'likely'
76 | # define likely(x) __builtin_expect(!!(x), 1)
| ^
2 warnings and 1 error generated.
vim +161 drivers/pwm/pwm-sifive.c
131
132 static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
133 const struct pwm_state *state)
134 {
135 struct pwm_sifive_ddata *ddata = pwm_sifive_chip_to_ddata(chip);
136 struct pwm_state cur_state;
137 unsigned int duty_cycle;
138 unsigned long long num;
139 bool enabled;
140 int ret = 0;
141 u32 frac, inactive;
142
143 if (state->polarity != PWM_POLARITY_NORMAL)
144 return -EINVAL;
145
146 cur_state = pwm->state;
147 enabled = cur_state.enabled;
148
149 duty_cycle = state->duty_cycle;
150 if (!state->enabled)
151 duty_cycle = 0;
152
153 /*
154 * The problem of output producing mixed setting as mentioned at top,
155 * occurs here. To minimize the window for this problem, we are
156 * calculating the register values first and then writing them
157 * consecutively
158 */
159 num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
160 frac = num;
> 161 do_div(frac, state->period);
162 /* The hardware cannot generate a 0% duty cycle */
163 frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
164 inactive = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
165
166 mutex_lock(&ddata->lock);
167 if (state->period != ddata->approx_period) {
168 /*
169 * Don't let a 2nd user change the period underneath the 1st user.
170 * However if ddate->approx_period == 0 this is the first time we set
171 * any period, so let whoever gets here first set the period so other
172 * users who agree on the period won't fail.
173 */
174 if (ddata->user_count != 1 && ddata->approx_period) {
175 mutex_unlock(&ddata->lock);
176 return -EBUSY;
177 }
178 ddata->approx_period = state->period;
179 pwm_sifive_update_clock(ddata, clk_get_rate(ddata->clk));
180 }
181 mutex_unlock(&ddata->lock);
182
183 /*
184 * If the PWM is enabled the clk is already on. So only enable it
185 * conditionally to have it on exactly once afterwards independent of
186 * the PWM state.
187 */
188 if (!enabled) {
189 ret = clk_enable(ddata->clk);
190 if (ret) {
191 dev_err(pwmchip_parent(chip), "Enable clk failed\n");
192 return ret;
193 }
194 }
195
196 writel(inactive, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
197
198 if (!state->enabled)
199 clk_disable(ddata->clk);
200
201 return 0;
202 }
203
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v13 5/5] pwm: sifive: clarify inverted compare logic in comments
2025-04-23 9:04 [PATCH v13 0/5] Change PWM-controlled LED pin active mode and algorithm Nylon Chen
` (3 preceding siblings ...)
2025-04-23 9:04 ` [PATCH v13 4/5] pwm: sifive: Fix rounding issues in apply and get_state functions Nylon Chen
@ 2025-04-23 9:04 ` Nylon Chen
4 siblings, 0 replies; 7+ messages in thread
From: Nylon Chen @ 2025-04-23 9:04 UTC (permalink / raw)
To: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Samuel Holland, Uwe Kleine-König
Cc: linux-riscv, devicetree, linux-kernel, linux-pwm, Nylon Chen,
Zong Li
The reference manual says "pwms >= pwmcmpX -> HIGH", but in Figure 29 pwmcmpXcenter
is forced to 0 via an XOR, so hardware actually outputs HIGH when pwms < pwmcmpX.
Thus pwmcmp holds the off-period count, and the driver must invert it
to expose a normal active-high interface.
Co-developed-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Nylon Chen <nylon.chen@sifive.com>
---
drivers/pwm/pwm-sifive.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index 4cf3e715fd84..84a7f79589df 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -4,11 +4,28 @@
* For SiFive's PWM IP block documentation please refer Chapter 14 of
* Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf
*
+ * PWM output inversion: According to the SiFive Reference manual
+ * the output of each comparator is high whenever the value of pwms is
+ * greater than or equal to the corresponding pwmcmpX[Reference Manual].
+ *
+ * Figure 29 in the same manual shows that the pwmcmpXcenter bit is
+ * hard-tied to 0 (XNOR), which effectively inverts the comparison so that
+ * the output goes HIGH when `pwms < pwmcmpX`.
+ *
+ * In other words, each pwmcmp register actually defines the **inactive**
+ * (low) period of the pulse, not the active time exactly opposite to what
+ * the documentation text implies.
+ *
+ * To compensate, this driver always **inverts** the duty value when reading
+ * or writing pwmcmp registers , so that users interact with a conventional
+ * **active-high** PWM interface.
+ *
+ *
* Limitations:
* - When changing both duty cycle and period, we cannot prevent in
* software that the output might produce a period with mixed
* settings (new period length and old duty cycle).
- * - The hardware cannot generate a 100% duty cycle.
+ * - The hardware cannot generate a 0% duty cycle.
* - The hardware generates only inverted output.
*/
#include <linux/clk.h>
@@ -113,6 +130,10 @@ static int pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
u32 duty, val, inactive;
inactive = readl(ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
+ /*
+ * PWM hardware uses 'inactive' counts in pwmcmp, so invert to get actual duty.
+ * Here, 'inactive' is the low time and we compute duty as max_count - inactive.
+ */
duty = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - inactive;
state->enabled = duty > 0;
@@ -161,6 +182,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
do_div(frac, state->period);
/* The hardware cannot generate a 0% duty cycle */
frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
+ /* pwmcmp register must be loaded with the inactive(invert the duty) */
inactive = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
mutex_lock(&ddata->lock);
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread