leds/pwm: don't call pwm_disable when setting brightness

This fixes disabling the LED on i.MX28. The PWM hardware delays using the newly set pwm-config until the beginning of a new period. It's very likely that pwm_disable is called before the current period ends. In case the LED was on brightness=max before the LED stays on because in the disabled PWM block the period never ends.

Also only call pwm_enable only once in the probe call back and the matching pwm_disable in .remove(). Moreover the pwm is explicitly initialized to off.

Quoted 6 lines · Uwe Kleine-K?nig

This fixes disabling the LED on i.MX28. The PWM hardware delays using the newly set pwm-config until the beginning of a new period. It's very likely that pwm_disable is called before the current period ends. In case the LED was on brightness=max before the LED stays on because in the disabled PWM block the period never ends.

Quoted 3 lines

Also only call pwm_enable only once in the probe call back and the matching pwm_disable in .remove(). Moreover the pwm is explicitly initialized to off.

While I do understand the reasoning behind this, if this is really the behaviour that we need then there's no use in having pwm_enable() and pwm_disable() at all. They can just be folded into pwm_get() and pwm_put(), respectively.

Quoted 11 lines · Thierry Reding

Quoted 9 lines · Uwe Kleine-K?nig

This fixes disabling the LED on i.MX28. The PWM hardware delays using the newly set pwm-config until the beginning of a new period. It's very likely that pwm_disable is called before the current period ends. In case the LED was on brightness=max before the LED stays on because in the disabled PWM block the period never ends.

Also only call pwm_enable only once in the probe call back and the matching pwm_disable in .remove(). Moreover the pwm is explicitly initialized to off.

Quoted 4 lines

While I do understand the reasoning behind this, if this is really the behaviour that we need then there's no use in having pwm_enable() and pwm_disable() at all. They can just be folded into pwm_get() and pwm_put(), respectively.

So after the first pwm_get the pwm starts with an unspecified duty cycle? That's not that nice, is it?

Hello Thierry,

Quoted 12 lines · Uwe Kleine-K?nig

Quoted 11 lines · Thierry Reding

Quoted 9 lines · Uwe Kleine-K?nig

This fixes disabling the LED on i.MX28. The PWM hardware delays using the newly set pwm-config until the beginning of a new period. It's very likely that pwm_disable is called before the current period ends. In case the LED was on brightness=max before the LED stays on because in the disabled PWM block the period never ends.

Also only call pwm_enable only once in the probe call back and the matching pwm_disable in .remove(). Moreover the pwm is explicitly initialized to off.

Quoted 6 lines

Quoted 4 lines

While I do understand the reasoning behind this, if this is really the behaviour that we need then there's no use in having pwm_enable() and pwm_disable() at all. They can just be folded into pwm_get() and pwm_put(), respectively.

So after the first pwm_get the pwm starts with an unspecified duty cycle? That's not that nice, is it?

How can we come forward here? After all it's a real bug being fixed.

Quoted 19 lines · Uwe Kleine-K?nig

Hello Thierry,

Quoted 16 lines · Uwe Kleine-K?nig

Quoted 15 lines · Thierry Reding

Quoted 9 lines · Uwe Kleine-K?nig

This fixes disabling the LED on i.MX28. The PWM hardware delays using the newly set pwm-config until the beginning of a new period. It's very likely that pwm_disable is called before the current period ends. In case the LED was on brightness=max before the LED stays on because in the disabled PWM block the period never ends.

Also only call pwm_enable only once in the probe call back and the matching pwm_disable in .remove(). Moreover the pwm is explicitly initialized to off.

While I do understand the reasoning behind this, if this is really the behaviour that we need then there's no use in having pwm_enable() and pwm_disable() at all. They can just be folded into pwm_get() and pwm_put(), respectively.

Quoted 3 lines

Quoted 2 lines

So after the first pwm_get the pwm starts with an unspecified duty cycle? That's not that nice, is it?

How can we come forward here? After all it's a real bug being fixed.

I've thought about this some more, and this isn't actually fixing a bug. Rather it's working around some quirk of the hardware in your setup. So

in the long run I think the best option would have to be to define the behaviour of the PWM subsystem, and then make sure in drivers that they behave accordingly. So if we define, or rather keep with the existing implied behaviour, that the configuration is active when pwm_config() returns, we can easily write generic client drivers because it means they can rely on said behaviour. If a driver doesn't behave accordingly it needs to be fixed.

If that means that a particular PWM controller applies the configuration only after the current period has expired, then that's something only the driver can now and therefore the driver should handle this by only returning from pwm_config() when that's actually happened.

That seems to me the only reasonable approach. Otherwise we'll have to keep changing API whenever some new controller comes around that behaves slightly differently.

Signed-off-by Uwe Kleine-K?nig <[email protected]>

---
 drivers/leds/leds-pwm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/leds/leds-pwm.c +2 -2

index cdc3e4d..0796ca3 100644
@@ -239,6 +239,6 @@ static struct platform_driver led_pwm_driver = {
 module_platform_driver(led_pwm_driver);
 
 MODULE_AUTHOR("Luotao Fu <[email protected]>");
-MODULE_DESCRIPTION("PWM LED driver for PXA");
-MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("generic PWM LED driver");
+MODULE_LICENSE("GPL v2");
 MODULE_ALIAS("platform:leds-pwm");

Signature · 1 line

1.8.4.2

Hello,

while the other two patches in this thread are controversal, this one shouldn't. It still sits in my branch with unapplied patches since nearly two years, which is enormous considering it's such an easy patch.

Best regards
Uwe

Quoted 22 lines · Uwe Kleine-K?nig

Signed-off-by Uwe Kleine-K?nig <[email protected]>

---
  drivers/leds/leds-pwm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

drivers/leds/leds-pwm.c +2 -3

index cdc3e4d..0796ca3 100644
@@ -239,6 +239,6 @@ static struct platform_driver led_pwm_driver = {
  module_platform_driver(led_pwm_driver);
 
  MODULE_AUTHOR("Luotao Fu <[email protected]>");
-MODULE_DESCRIPTION("PWM LED driver for PXA");
-MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("generic PWM LED driver");
+MODULE_LICENSE("GPL v2");
  MODULE_ALIAS("platform:leds-pwm");
--

1.8.4.2

Hello,

some time ago I pointed out a problem with leds-pwm on i.MX28, because on this SoC it can happen that after:

	pwm_config(pwm, 0, period);
	pwm_disable(pwm);

the connected LED stays on. The mail thread is available at

	http://thread.gmane.org/gmane.linux.kernel/1381289

This series implements the outcome that didn't get any opposition, i.e. the pin state is explicitly undefined after pwm_disable. The first patch adds this fact to the general pwm docs, the second patch fixes the leds-pwm driver accordingly. The third patch is just a trivial fix that I noticed while patching the leds-pwm driver and not really related to any problem.

Best regards
Uwe

Uwe Kleine-K?nig (3):
pwm/doc: Clearify that the pin state after pwm_disable is undefined leds/pwm: Don't disable pwm when setting brightness to 0 leds/pwm: fix driver description and make license match the header

 Documentation/pwm.txt   |  5 +++++
 drivers/leds/leds-pwm.c | 14 +++++++-------
 2 files changed, 12 insertions(+), 7 deletions(-)