linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: "Vokáč Michal" <Michal.Vokac@ysoft.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
	"Lukasz Majewski" <l.majewski@majess.pl>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"Fabio Estevam" <fabio.estevam@nxp.com>,
	"Lothar Waßmann" <LW@karo-electronics.de>,
	"Linus Walleij" <linus.walleij@linaro.org>
Subject: Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state
Date: Thu, 22 Nov 2018 17:17:48 +0100	[thread overview]
Message-ID: <20181122161748.2ud7f26xkww5g24m@pengutronix.de> (raw)
In-Reply-To: <20181122150338.GA24661@ulmo>

Hello Thierry,

On Thu, Nov 22, 2018 at 04:03:38PM +0100, Thierry Reding wrote:
> On Sun, Nov 18, 2018 at 09:08:15PM +0100, Uwe Kleine-König wrote:
> > Thinking a bit about this it doesn't really matter for the consumer if
> > the pin stays in the idle level because there is a pull into the right
> > direction and the PWM is high-Z or if the PWM pulls actively in the
> > right direction. Also for pwm_config(pwm, 0, 100) the PWM could disable
> > its output in the presence of a pull, so the property says true that the
> > effects of pwm_config(pwm, 0, 100) and pwm_disable(pwm) should be the
> > same. And so my claim that pwm_disable is a part of the API that
> > doesn't give any value stays true.
> 
> I still think there's a slight difference there. Granted the effect on
> the consumer is the same whether you disable or set the duty-cycle to
> zero because the power output is the same. pwm_disable() is still more
> explicit, though, so it may involve more than just setting the duty-
> cycle.

If pwm_disable() vs. duty-cycle=0 doesn't make a difference to the
consumer, who do we do a favour by providing pwm_disable()?

> > > But again, why should PWMs be special? You turn off all other resources
> > > when you no longer need them, right? If you power your panel with a
> > > regulator, then when the panel is disabled you want to disable the
> > > regulator, right? Similarily if you don't use your I2C controller you
> > > want to turn off the clock that drives it, right? This is the same for
> > > any resource in your system: if you no longer need it, disable it. The
> > > fact that "disabling" the PWM is not straightforward on i.MX doesn't
> > > mean that we should simply ignore it.
> > 
> > I don't say we should ignore it. I say we shouldn't disable the hardware
> > if the consumer calls pwm_disable() if disabling the hardware results in
> > a state that shouldn't happen on pwm_disable().
> 
> That's backwards. If disabling the hardware results in a state that
> shouldn't happen when you disable the hardware, that just means that
> you're doing something wrong. When you do something wrong you fix it.

For you pwm_disable must imply disabling the PWM hardware. As you cannot
have both (disable the hardware and keep the pin on the idle level
without involving pinmux and GPIO) on i.MX in my eyes it is sensible to
drop one requirement from the framework's expectations to make it
possible for i.MX to fulfill them.

As there is no advantage for anyone to force .disable() to actually
disable the hardware (apart from a little power saving that probably
isn't even measurable) that's IMHO the one to drop.

> If the pin goes to the wrong level when you disable the hardware, the
> natural fix for the problem is to make sure the pin stays at the right
> level.

Ack. And you can do this either in an easy variant or in a more
complicated one.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  reply	other threads:[~2018-11-22 16:17 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10  9:33 [RCF PATCH v2 0/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal
2018-10-10  9:33 ` [RCF PATCH v2 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO Vokáč Michal
2018-10-10 13:39   ` Thierry Reding
2018-10-29 15:52     ` Vokáč Michal
2018-10-10  9:33 ` [RCF PATCH v2 2/2] pwm: imx: Configure output to GPIO in disabled state Vokáč Michal
2018-10-12  8:57   ` [RCF PATCH,v2,2/2] " Uwe Kleine-König
2018-10-12 15:04     ` Vokáč Michal
2018-10-12 15:54       ` Thierry Reding
2018-10-12 16:08       ` Uwe Kleine-König
2018-10-14 20:24         ` Uwe Kleine-König
2018-10-15  8:45           ` Thierry Reding
2018-10-29 15:55             ` Vokáč Michal
2018-10-29 15:54         ` Vokáč Michal
2018-11-07  9:33           ` Uwe Kleine-König
2018-11-07 13:32             ` Vokáč Michal
2018-11-07 15:01               ` Uwe Kleine-König
2018-11-08 15:21                 ` Vokáč Michal
2018-11-08 19:18                   ` Uwe Kleine-König
2018-11-09 14:24                     ` Vokáč Michal
2018-11-09 16:55                       ` Uwe Kleine-König
2018-11-14  9:09                         ` Uwe Kleine-König
2018-11-14 11:34                         ` Thierry Reding
2018-11-14 21:51                           ` Uwe Kleine-König
2018-11-15 15:25                             ` Thierry Reding
2018-11-15 20:37                               ` Uwe Kleine-König
2018-11-16  7:34                                 ` Lothar Waßmann
2018-11-16  8:25                                   ` Uwe Kleine-König
2018-11-22 15:42                                     ` Vokáč Michal
2018-11-22 16:23                                       ` Uwe Kleine-König
2018-11-22 16:46                                         ` Vokáč Michal
2018-11-22 19:03                                           ` Uwe Kleine-König
2018-11-23 15:15                                             ` Vokáč Michal
2018-11-25 20:56                                               ` Uwe Kleine-König
2018-11-26  9:11                                                 ` Lothar Waßmann
2018-11-26  9:18                                                   ` Uwe Kleine-König
2018-11-26 10:03                                                     ` Lothar Waßmann
2018-11-26 11:51                                               ` Thierry Reding
2018-11-26 12:23                                                 ` Lothar Waßmann
2018-11-26 13:34                                                   ` Thierry Reding
2018-11-26 15:50                                                     ` Vokáč Michal
2018-11-16  9:51                                 ` Thierry Reding
2018-11-16 10:39                                   ` Uwe Kleine-König
2018-11-16 11:56                                     ` Lothar Waßmann
2018-11-18 11:30                                       ` Uwe Kleine-König
2018-11-16 12:24                                     ` Thierry Reding
2018-11-18 20:08                                       ` Uwe Kleine-König
2018-11-19  8:48                                         ` Uwe Kleine-König
2018-11-22 15:03                                         ` Thierry Reding
2018-11-22 16:17                                           ` Uwe Kleine-König [this message]
2018-11-20 13:14                                   ` Vokáč Michal
2018-11-20 16:54                                     ` Uwe Kleine-König
2018-11-22 14:23                                       ` Vokáč Michal
2018-11-19  7:44                             ` Linus Walleij
2018-11-19  8:32                               ` Uwe Kleine-König
2018-11-20  8:35                                 ` Linus Walleij
2018-11-20  9:16                                   ` Viresh Kumar
2018-11-20  9:53                                   ` Uwe Kleine-König
2018-11-14 11:14                   ` Thierry Reding
2018-10-12 16:00   ` [RCF PATCH v2 2/2] " Thierry Reding
2018-10-29 15:53     ` Vokáč Michal

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=20181122161748.2ud7f26xkww5g24m@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=LW@karo-electronics.de \
    --cc=Michal.Vokac@ysoft.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fabio.estevam@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=l.majewski@majess.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --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: 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).