From: stefan@agner.ch (Stefan Agner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv6 0/3] pwm: imx: support output polarity inversion
Date: Mon, 12 Sep 2016 09:51:26 -0700 [thread overview]
Message-ID: <074eed0df23199bc82f8d221690596d3@agner.ch> (raw)
In-Reply-To: <20160912140401.qkezay7sqqavsf4i@pengutronix.de>
Hi,
Thanks for that insight Uwe!
On 2016-09-12 07:04, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Mon, Sep 12, 2016 at 02:45:53PM +0200, Alexandre Belloni wrote:
>> Isn't a properly designed PWM putting a high level on its pin when
>> disabled and configured with inversed polarity ?
>
> it's not well defined. When trying several times over the years to
> properly define and document it, I didn't manage to agree with Thierry
> what is the right thing to define.
>
> IMHO it would be sensible to make it explicitly undefined what happens
> when a PMW is disabled. This would simplify drivers from
>
> pwm_config(mypwm, value, period);
> if (!value)
> pwm_disable(mypwm)
> else
> pwm_enable(led_dat->pwm);
>
> to
>
> pwm_config(mypwm, value, period);
>
> and let the pwm driver disable it's clock (or whatever) when value is 0
> and there are energy saving benefits that don't hurt the expected
> behaviour of the pin. So the hardware specific stuff is handled in the
> hardware specific driver and usage in pwm-consumers is simplified.
> Moreover this also simplifies some pwm drivers because they don't have
> to catch in software the cases where the hardware differs from the
> expectation[1].
That sounds like a sane definition to me and what I would have expected
from the PWM framework. That the pin is not defined after pwm_disable is
totally understandable. It is usually a case which the board designer
anyway needs to take care of (e.g. what is the state right after power
on? If the designer cares about, he will put a pull-up/down in place).
And it seems also Sascha suggested that:
https://lkml.org/lkml/2013/1/4/139
I did not found where Thierry disagreed to that...?
> Looking at drivers/leds/leds-pwm.c it doesn't ensure that each
> pwm_enable is paired by an pwm_disable (e.g. on .remove). Is this a bug?
> With my purposed semantics of .config and .disable this would be much
> easier to fix.
That looks like a bug to me.
>
> Regarding your question: Yeah, maybe all properly designed PWMs behave
> like you expect. But reality isn't only about properly designed
> hardware, so I wouldn't expect all hardware to behave. The inverse
> property might be software emulated and so on pwm_disable the pin might
> become 0.
>
> The obvious downside of my suggestion is that this is a change in what
> most people expect (because it was "safe" to call pwm_enable before),
> but the resulting code is simpler and cleaner.
>
> Today it's a (maybe small) bug, when a pwm consumer calls pwm_config with
> value=0 and doesn't disable it afterwards. IMHO that's a bug in the pwm
> API that pwm_config with value=0 doesn't imply (the wanted effects of)
> pwm_disable.
I don't quite get what you are saying here. What wanted effects of
pwm_disable would you like to move into pwm_config with value=0?
--
Stefan
>
> Best regards
> Uwe
>
> [1] This might even be impossible: Consider a PWM that gets 0 (or
> high-z) on hw-disable independent of configured duty or inversion. The
> driver now sees for an inverted pwm: pwm_config(this, 0, 100);
> pwm_disable(this); The driver cannot know if it should continue to drive
> the pin at 1, or if the pwm consumer stopped caring about the pwm and
> disabling the hardware is OK.
next prev parent reply other threads:[~2016-09-12 16:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 13:55 [PATCHv4 0/3] pwm: imx: support output polarity inversion Lothar Waßmann
2014-10-07 13:55 ` [PATCHv5 1/3] pwm: print error messages with pr_err() instead of pr_debug() Lothar Waßmann
2014-10-07 13:55 ` [PATCHv5 2/3] pwm: make the PWM_POLARITY flag in DTB optional Lothar Waßmann
2014-10-09 15:16 ` Thierry Reding
2014-10-10 14:22 ` [PATCHv6 0/3] pwm: imx: support output polarity inversion Lothar Waßmann
2014-10-10 14:22 ` [PATCHv6 1/3] pwm: print error messages with pr_err() instead of pr_debug() Lothar Waßmann
2014-10-10 14:22 ` [PATCHv6 2/3] pwm: make the PWM_POLARITY flag in DTB optional Lothar Waßmann
2014-10-10 14:22 ` [PATCH 3/3] pwm: imx: support output polarity inversion Lothar Waßmann
2016-09-08 22:15 ` [PATCHv6 0/3] " Stefan Agner
2016-09-09 7:18 ` Lothar Waßmann
2016-09-12 12:45 ` Alexandre Belloni
2016-09-12 14:04 ` Uwe Kleine-König
2016-09-12 16:51 ` Stefan Agner [this message]
2016-09-12 20:00 ` Uwe Kleine-König
2016-09-12 21:12 ` Clemens Gruber
2016-09-13 6:45 ` Uwe Kleine-König
2016-09-12 13:54 ` Vladimir Zapolskiy
2014-10-07 13:55 ` [PATCHv5 3/3] " Lothar Waßmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=074eed0df23199bc82f8d221690596d3@agner.ch \
--to=stefan@agner.ch \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).