This series adds a few related fixes to the pwm .apply and .get_state
callbacks.
The first patch was originally part of the series adding Armada 8K/7K pwm
support. I split it out to a separate series following review comments from
Uwe Kleine-König who spotted a few more issues. There is no dependency between
this and the Armada 8K/7K series.
v5:
* Drop a patch applied to the gpio tree
* Fix patch 4/4 description typo (Uwe)
* Reduce the number of multiplications (Uwe)
* Add spaces around '+' (Uwe)
* Use '1ULL' instead of explicit cast to reduce verbosity
* Add Linus' Reviewed-by tags to patches that are unchanged since v2
v4:
* Take advantage of zero value being treated as 2^32 by hardware. Rewrite
patch 5/5 (Uwe).
v3:
* Improve patch 3/5 description (Uwe)
* Add more Reviewed-by tags from Uwe
v2:
Address Uwe Kleine-König comments.
* Improve patch 1/5 summary line
* Add more information to patch 1/5 description
* Add more information to patch 2/5 description
* Don't round period/duty_cycle up in .apply (patch 3/5)
* Expand the comment in path 5/5 based on RMK's analysis of hardware
behaviour
* Add Uwe's Reviewed-by tags
Baruch Siach (4):
gpio: mvebu: improve pwm period calculation accuracy
gpio: mvebu: make pwm .get_state closer to idempotent
gpio: mvebu: don't limit pwm period/duty_cycle to UINT_MAX
gpio: mvebu: improve handling of pwm zero on/off values
drivers/gpio/gpio-mvebu.c | 47 +++++++++++++++++++++------------------
1 file changed, 25 insertions(+), 22 deletions(-)
--
2.29.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hardware appears to treat zero value as 2^32. Take advantage of this
fact to support on/off values of up to UINT_MAX+1 == 2^32. Adjust both
.apply and .get_state to handle zero as a special case.
Rounded up division result in .get_state can't be zero, since the
dividend is now larger than 0. Remove check for this case.
Reported-by: Uwe Kleine-König <redacted>
Analyzed-by: Russell King [off-list ref]
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/gpio/gpio-mvebu.c | 39 +++++++++++++++++++++++----------------
1 file changed, 23 insertions(+), 16 deletions(-)
@@ -667,22 +667,21 @@ static void mvebu_pwm_get_state(struct pwm_chip *chip,spin_lock_irqsave(&mvpwm->lock,flags);regmap_read(mvpwm->regs,mvebu_pwmreg_blink_on_duration(mvpwm),&u);-val=(unsignedlonglong)u*NSEC_PER_SEC;-val=DIV_ROUND_UP_ULL(val,mvpwm->clk_rate);-if(val)-state->duty_cycle=val;+/* Hardware treats zero as 2^32. See mvebu_pwm_apply(). */+if(u>0)+val=u;else-state->duty_cycle=1;+val=UINT_MAX+1ULL;+state->duty_cycle=DIV_ROUND_UP_ULL(val*NSEC_PER_SEC,+mvpwm->clk_rate);-val=(unsignedlonglong)u;/* on duration */regmap_read(mvpwm->regs,mvebu_pwmreg_blink_off_duration(mvpwm),&u);-val+=(unsignedlonglong)u;/* period = on + off duration */-val*=NSEC_PER_SEC;-val=DIV_ROUND_UP_ULL(val,mvpwm->clk_rate);-if(val)-state->period=val;+/* period = on + off duration */+if(u>0)+val+=u;else-state->period=1;+val+=UINT_MAX+1ULL;+state->period=DIV_ROUND_UP_ULL(val*NSEC_PER_SEC,mvpwm->clk_rate);regmap_read(mvchip->regs,GPIO_BLINK_EN_OFF+mvchip->offset,&u);if(u)
Round up the divisions in .get_state() to make applying the read out
configuration idempotent in most cases as .apply rounds down.
Reported-by: Uwe Kleine-König <redacted>
Reviewed-by: Uwe Kleine-König <redacted>
Reviewed-by: Linus Walleij <redacted>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/gpio/gpio-mvebu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
PWM on/off registers are limited to UINT_MAX. However the state period
and duty_cycle fields are ns values of type u64. There is no reason to
limit them to UINT_MAX.
Reported-by: Uwe Kleine-König <redacted>
Reviewed-by: Uwe Kleine-König <redacted>
Reviewed-by: Linus Walleij <redacted>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/gpio/gpio-mvebu.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
On Wed, Jan 20, 2021 at 06:16:28PM +0200, Baruch Siach wrote:
Hardware appears to treat zero value as 2^32. Take advantage of this
fact to support on/off values of up to UINT_MAX+1 == 2^32. Adjust both
.apply and .get_state to handle zero as a special case.
Rounded up division result in .get_state can't be zero, since the
dividend is now larger than 0. Remove check for this case.
Reported-by: Uwe Kleine-König <redacted>
Analyzed-by: Russell King [off-list ref]
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
On Wed, Jan 20, 2021 at 5:16 PM Baruch Siach [off-list ref] wrote:
This series adds a few related fixes to the pwm .apply and .get_state
callbacks.
The first patch was originally part of the series adding Armada 8K/7K pwm
support. I split it out to a separate series following review comments from
Uwe Kleine-König who spotted a few more issues. There is no dependency between
this and the Armada 8K/7K series.
v5:
* Drop a patch applied to the gpio tree
* Fix patch 4/4 description typo (Uwe)
* Reduce the number of multiplications (Uwe)
* Add spaces around '+' (Uwe)
* Use '1ULL' instead of explicit cast to reduce verbosity
* Add Linus' Reviewed-by tags to patches that are unchanged since v2
v4:
* Take advantage of zero value being treated as 2^32 by hardware. Rewrite
patch 5/5 (Uwe).
v3:
* Improve patch 3/5 description (Uwe)
* Add more Reviewed-by tags from Uwe
v2:
Address Uwe Kleine-König comments.
* Improve patch 1/5 summary line
* Add more information to patch 1/5 description
* Add more information to patch 2/5 description
* Don't round period/duty_cycle up in .apply (patch 3/5)
* Expand the comment in path 5/5 based on RMK's analysis of hardware
behaviour
* Add Uwe's Reviewed-by tags
Baruch Siach (4):
gpio: mvebu: improve pwm period calculation accuracy
gpio: mvebu: make pwm .get_state closer to idempotent
gpio: mvebu: don't limit pwm period/duty_cycle to UINT_MAX
gpio: mvebu: improve handling of pwm zero on/off values
drivers/gpio/gpio-mvebu.c | 47 +++++++++++++++++++++------------------
1 file changed, 25 insertions(+), 22 deletions(-)
--
2.29.2
Series applied, thanks a lot for the improvements! And thanks to Uwe
and Russel for the reviews.
Bartosz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel