This makes assumptions on the behaviour of the pwm API explicit. Note that there are drivers that assume that pwm_disable does result in a stable output matching the last pwm_config; leds-pwm is an example that is fixed in a followup patch. On arm/i.MX28 it can really happen that after pwm_config(led_dat->pwm, 0, 100); pwm_disable(led_dat->pwm); the output is stuck at 1. That's because the pwm only works with the newly configured config when a period is over for the previously configured setting to prevent spikes. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> --- Documentation/pwm.txt | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt index ca895fd211e4..abdd21d047ca 100644 --- a/Documentation/pwm.txt +++ b/Documentation/pwm.txt @@ -46,6 +46,11 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns); To start/stop toggling the PWM output use pwm_enable()/pwm_disable(). +Note that after calling pwm_disable() it's undefined if the output stops in a +high or low state, even if the duty cycle is set to 0% or 100%. So don't call +pwm_disable() if there is a need for a specific level. The same applies when +pwm_enable() was called, but pwm_config() was not. + Using PWMs with the sysfs interface ----------------------------------- -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-leds" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
