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 a586cfe4191b..bebcbebacccd 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->chip.dev,
"New real_period = %u ns\n", ddata->real_period);
}
--
2.43.0Hello, On Thu, Feb 22, 2024 at 04:12:31PM +0800, Nylon Chen wrote: > 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 a586cfe4191b..bebcbebacccd 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->chip.dev, > "New real_period = %u ns\n", ddata->real_period); > } pwm_sifive_apply has a DIV64_U64_ROUND_CLOSEST(). I wonder if that needs adaption, too?! Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2024年3月19日 週二 上午2:17寫道： > > Hello, > > On Thu, Feb 22, 2024 at 04:12:31PM +0800, Nylon Chen wrote: > > 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 a586cfe4191b..bebcbebacccd 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->chip.dev, > > "New real_period = %u ns\n", ddata->real_period); > > } Hi Uwe > > pwm_sifive_apply has a DIV64_U64_ROUND_CLOSEST(). I wonder if that needs > adaption, too?! According to my experiments, no adjustment is necessary. > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | https://www.pengutronix.de/ |
On Tue, Apr 02, 2024 at 10:01:39AM +0800, Nylon Chen wrote: > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2024年3月19日 週二 上午2:17寫道： > > > > Hello, > > > > On Thu, Feb 22, 2024 at 04:12:31PM +0800, Nylon Chen wrote: > > > 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 a586cfe4191b..bebcbebacccd 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->chip.dev, > > > "New real_period = %u ns\n", ddata->real_period); > > > } > Hi Uwe > > > > pwm_sifive_apply has a DIV64_U64_ROUND_CLOSEST(). I wonder if that needs > > adaption, too?! > According to my experiments, no adjustment is necessary. Did you enable PWM_DEBUG and tested with something like: seq 5000 100000 | while read p; do echo p > /sys/class/pwm/pwmchipX/pwmY/period; done and then verified that this test didn't result in kernel messages about wrong settings? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2024年4月12日 週五 下午3:05寫道： > > On Tue, Apr 02, 2024 at 10:01:39AM +0800, Nylon Chen wrote: > > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2024年3月19日 週二 上午2:17寫道： > > > > > > Hello, > > > > > > On Thu, Feb 22, 2024 at 04:12:31PM +0800, Nylon Chen wrote: > > > > 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 a586cfe4191b..bebcbebacccd 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->chip.dev, > > > > "New real_period = %u ns\n", ddata->real_period); > > > > } > > Hi Uwe > > > > > > pwm_sifive_apply has a DIV64_U64_ROUND_CLOSEST(). I wonder if that needs > > > adaption, too?! > > According to my experiments, no adjustment is necessary. > > Did you enable PWM_DEBUG and tested with something like: > > seq 5000 100000 | while read p; do echo p > /sys/class/pwm/pwmchipX/pwmY/period; done > Hi Uwe, I apologize for the significant delay in responding to your query, I've now completed a thorough verification of the PWM_DEBUG functionality. The Period Testing: seq 5000 5000 100000 | while read p; do echo $p > /sys/class/pwm/pwmchip0/pwm0/period echo "Testing period: $p" done The Duty Cycle Testing: for percent in 0 25 50 75 100; do duty=$((100000 * percent / 100)) echo $duty > /sys/class/pwm/pwmchip0/pwm0/duty_cycle done - All period values from 5000ns to 100000ns were applied successfully - Various duty cycle ratios were tested without issues - Monitored dmesg output during tests - no kernel messages about wrong settings were observed Let me know if you need any additional test data or have other parameters you'd like me to verify. > and then verified that this test didn't result in kernel messages about > wrong settings? > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | https://www.pengutronix.de/ | -- ========================================== sifive system software team 陳伯綸 Cell phone: 0989057854 E-mail: nylon7717@gmail.com ==========================================
On Tue, Dec 24, 2024 at 04:34:53PM +0800, Nylon Chen wrote: > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2024年4月12日 週五 下午3:05寫道： > > > > On Tue, Apr 02, 2024 at 10:01:39AM +0800, Nylon Chen wrote: > > > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2024年3月19日 週二 上午2:17寫道： > > > > > > > > Hello, > > > > > > > > On Thu, Feb 22, 2024 at 04:12:31PM +0800, Nylon Chen wrote: > > > > > 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 a586cfe4191b..bebcbebacccd 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->chip.dev, > > > > > "New real_period = %u ns\n", ddata->real_period); > > > > > } > > > Hi Uwe > > > > > > > > pwm_sifive_apply has a DIV64_U64_ROUND_CLOSEST(). I wonder if that needs > > > > adaption, too?! > > > According to my experiments, no adjustment is necessary. > > > > Did you enable PWM_DEBUG and tested with something like: > > > > seq 5000 100000 | while read p; do echo p > /sys/class/pwm/pwmchipX/pwmY/period; done > > > Hi Uwe, > I apologize for the significant delay in responding to your query, > I've now completed a thorough verification of the PWM_DEBUG > functionality. > > The Period Testing: > seq 5000 5000 100000 | while read p; do echo $p > > /sys/class/pwm/pwmchip0/pwm0/period echo "Testing period: $p" done > > The Duty Cycle Testing: > for percent in 0 25 50 75 100; do duty=$((100000 * percent / 100)) > echo $duty > /sys/class/pwm/pwmchip0/pwm0/duty_cycle done This is unlikely to find the issues that I have in mind. If doing ~100k assignments is too much, please keep the +1 step but restrict the interval. Best regards Uwe
Uwe Kleine-König <u.kleine-koenig@baylibre.com> 於 2024年12月27日 週五 下午11:39寫道： > > On Tue, Dec 24, 2024 at 04:34:53PM +0800, Nylon Chen wrote: > > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2024年4月12日 週五 下午3:05寫道： > > > > > > On Tue, Apr 02, 2024 at 10:01:39AM +0800, Nylon Chen wrote: > > > > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 於 2024年3月19日 週二 上午2:17寫道： > > > > > > > > > > Hello, > > > > > > > > > > On Thu, Feb 22, 2024 at 04:12:31PM +0800, Nylon Chen wrote: > > > > > > 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 a586cfe4191b..bebcbebacccd 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->chip.dev, > > > > > > "New real_period = %u ns\n", ddata->real_period); > > > > > > } > > > > Hi Uwe > > > > > > > > > > pwm_sifive_apply has a DIV64_U64_ROUND_CLOSEST(). I wonder if that needs > > > > > adaption, too?! > > > > According to my experiments, no adjustment is necessary. > > > > > > Did you enable PWM_DEBUG and tested with something like: > > > > > > seq 5000 100000 | while read p; do echo p > /sys/class/pwm/pwmchipX/pwmY/period; done > > > > > Hi Uwe, > > I apologize for the significant delay in responding to your query, > > I've now completed a thorough verification of the PWM_DEBUG > > functionality. > > > > The Period Testing: > > seq 5000 5000 100000 | while read p; do echo $p > > > /sys/class/pwm/pwmchip0/pwm0/period echo "Testing period: $p" done > > > > The Duty Cycle Testing: > > for percent in 0 25 50 75 100; do duty=$((100000 * percent / 100)) > > echo $duty > /sys/class/pwm/pwmchip0/pwm0/duty_cycle done > > This is unlikely to find the issues that I have in mind. If doing ~100k > assignments is too much, please keep the +1 step but restrict the > interval. Hi Uwe, I have made the following adjustments based on your requirements. Does this align with what you had in mind? - period seq 5000 1 15000 | while read p; do echo $p > /sys/class/pwm/pwmchip0/pwm0/period echo "Testing period: $p" done - duty cycle for duty in $(seq 0 1 10000); do echo $duty > /sys/class/pwm/pwmchip0/pwm0/duty_cycle echo "Testing duty cycle: $duty" done > > Best regards > Uwe
Hello Nylon, On Mon, Jan 06, 2025 at 05:00:32PM +0800, Nylon Chen wrote: > Hi Uwe, I have made the following adjustments based on your > requirements. Does this align with what you had in mind? > - period > seq 5000 1 15000 | while read p; do echo $p > > /sys/class/pwm/pwmchip0/pwm0/period echo "Testing period: $p" done > > - duty cycle > for duty in $(seq 0 1 10000); do echo $duty > > /sys/class/pwm/pwmchip0/pwm0/duty_cycle echo "Testing duty cycle: > $duty" done That + doing the same test backwards (i.e. using seq 15000 -1 5000 for the period test and seq 10000 -1 0 for duty_cycle) should catch most rounding bugs. Best regards Uwe
Uwe Kleine-König <u.kleine-koenig@baylibre.com> 於 2025年1月7日 週二 下午12:52寫道： > > Hello Nylon, > > On Mon, Jan 06, 2025 at 05:00:32PM +0800, Nylon Chen wrote: > > Hi Uwe, I have made the following adjustments based on your > > requirements. Does this align with what you had in mind? > > - period > > seq 5000 1 15000 | while read p; do echo $p > > > /sys/class/pwm/pwmchip0/pwm0/period echo "Testing period: $p" done > > > > - duty cycle > > for duty in $(seq 0 1 10000); do echo $duty > > > /sys/class/pwm/pwmchip0/pwm0/duty_cycle echo "Testing duty cycle: > > $duty" done > > That + doing the same test backwards (i.e. using seq 15000 -1 5000 for > the period test and seq 10000 -1 0 for duty_cycle) should catch most > rounding bugs. > Hi Uwe, I understand what you mean now (testing must consider both backwards and forwards). Thank you for taking the time to explain it to me. > Best regards > Uwe
© 2016 - 2026 Red Hat, Inc.