From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> To: Stefan Agner <stefan@agner.ch> Cc: "Alexandre Belloni" <alexandre.belloni@free-electrons.com>, "Lothar Waßmann" <LW@karo-electronics.de>, linux-pwm@vger.kernel.org, "Sascha Hauer" <s.hauer@pengutronix.de>, "Thierry Reding" <thierry.reding@gmail.com>, "Shawn Guo" <shawn.guo@linaro.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCHv6 0/3] pwm: imx: support output polarity inversion Date: Mon, 12 Sep 2016 22:00:21 +0200 [thread overview] Message-ID: <20160912200021.fsnfdgnng4it354g@pengutronix.de> (raw) In-Reply-To: <074eed0df23199bc82f8d221690596d3@agner.ch> Hello Stefan, On Mon, Sep 12, 2016 at 09:51:26AM -0700, Stefan Agner wrote: > 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 actually I talked to Sascha in private before ranting :-) > I did not found where Thierry disagreed to that...? Hmm, I used gmane links before, most of them are dead today. :-| http://www.spinics.net/lists/linux-leds/msg03237.html is one example. > > 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? I want that the pwm driver disables its clock on pwm_config(mypwm, 0, someperiod) such that the consumer doesn't need to call pwm_disable(mypwm) to save power (assuming it's safe to do so, which only the pwm provider knows). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
WARNING: multiple messages have this Message-ID (diff)
From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König) To: linux-arm-kernel@lists.infradead.org Subject: [PATCHv6 0/3] pwm: imx: support output polarity inversion Date: Mon, 12 Sep 2016 22:00:21 +0200 [thread overview] Message-ID: <20160912200021.fsnfdgnng4it354g@pengutronix.de> (raw) In-Reply-To: <074eed0df23199bc82f8d221690596d3@agner.ch> Hello Stefan, On Mon, Sep 12, 2016 at 09:51:26AM -0700, Stefan Agner wrote: > 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 actually I talked to Sascha in private before ranting :-) > I did not found where Thierry disagreed to that...? Hmm, I used gmane links before, most of them are dead today. :-| http://www.spinics.net/lists/linux-leds/msg03237.html is one example. > > 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? I want that the pwm driver disables its clock on pwm_config(mypwm, 0, someperiod) such that the consumer doesn't need to call pwm_disable(mypwm) to save power (assuming it's safe to do so, which only the pwm provider knows). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2016-09-12 20:00 UTC|newest] Thread overview: 36+ 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 ` 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 ` 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-07 13:55 ` Lothar Waßmann 2014-10-09 15:16 ` Thierry Reding 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 ` 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 ` 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 ` Lothar Waßmann 2014-10-10 14:22 ` [PATCH 3/3] pwm: imx: support output polarity inversion Lothar Waßmann 2014-10-10 14:22 ` Lothar Waßmann 2016-09-08 22:15 ` [PATCHv6 0/3] " Stefan Agner 2016-09-08 22:15 ` Stefan Agner 2016-09-09 7:18 ` Lothar Waßmann 2016-09-09 7:18 ` Lothar Waßmann 2016-09-12 12:45 ` Alexandre Belloni 2016-09-12 12:45 ` Alexandre Belloni 2016-09-12 14:04 ` Uwe Kleine-König 2016-09-12 14:04 ` Uwe Kleine-König 2016-09-12 16:51 ` Stefan Agner 2016-09-12 16:51 ` Stefan Agner 2016-09-12 20:00 ` Uwe Kleine-König [this message] 2016-09-12 20:00 ` Uwe Kleine-König 2016-09-12 21:12 ` Clemens Gruber 2016-09-12 21:12 ` Clemens Gruber 2016-09-13 6:45 ` Uwe Kleine-König 2016-09-13 6:45 ` Uwe Kleine-König 2016-09-12 13:54 ` Vladimir Zapolskiy 2016-09-12 13:54 ` Vladimir Zapolskiy 2014-10-07 13:55 ` [PATCHv5 3/3] " Lothar Waßmann 2014-10-07 13:55 ` 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=20160912200021.fsnfdgnng4it354g@pengutronix.de \ --to=u.kleine-koenig@pengutronix.de \ --cc=LW@karo-electronics.de \ --cc=alexandre.belloni@free-electrons.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pwm@vger.kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=shawn.guo@linaro.org \ --cc=stefan@agner.ch \ --cc=thierry.reding@gmail.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.