linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	linux-pwm@vger.kernel.org, "Bryan Wu" <cooloney@gmail.com>,
	"Richard Purdie" <rpurdie@rpsys.net>,
	linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-leds@vger.kernel.org,
	"Sjoerd Simons" <sjoerd.simons@collabora.co.uk>,
	"Tim Kryger" <tim.kryger@linaro.org>,
	"Alex Elder" <elder@linaro.org>,
	"Markus Mayer" <markus.mayer@linaro.org>
Subject: Re: [PATCH 0/2] leds/pwm: don't call pwm_disable when setting brightness
Date: Fri, 27 Mar 2015 19:49:01 +0100	[thread overview]
Message-ID: <20150327184901.GY9742@pengutronix.de> (raw)
In-Reply-To: <20150327154301.GA27626@ulmo.nvidia.com>

On Fri, Mar 27, 2015 at 04:43:03PM +0100, Thierry Reding wrote:
> On Fri, Mar 27, 2015 at 03:35:59PM +0100, Uwe Kleine-König wrote:
> > > Why do you think it is the worst? If we define the behaviour as b) what
> > > does that gain us? Why would users want to call these functions if their
> > The gain is that the three (or more?) pwm drivers don't need to special
> > case an artificial requirement of the framework. OK, users have to
> > adapt, but it's as simple as substituting all questionable calls to
> > pwm_disable by a call to pwm_config(duty=0).
> 
> There is no gain. If users suddenly have to care about hardware
> specifics I call that a loss. Equivalently if the PWM core framework
> needs to know about these specifics that's also a loss because it puts
> complexity in the core where device-specific properties clearly
> shouldn't be handled.

The easy way out for PWM users, the core and the driver is:

Declare the output status of a disabled PWM as undefined.

The core is not affected by this change. The users are even simplified
by this change, because at the moment they all have to special case in
some way if (duty == 0) pwm_disable(pwm);, this code could be removed.
The PWM drivers could be simplified aswell since they no longer have to
care about getting the PWM in a well defined state and don't have to
take care about the correct disabled state of inverted PWMs. If a PWM
driver wishes it can do some special casing for 0 and 100% duty cycle in
order to save some power, but that would only be a bonus. As an
additional bonus inverted PWMs could be completely software emulated in
the core, then this code could also be removed from the drivers.
PWM Users generally don't want to disable or enable the PWMs, instead
they want a duty cycle of 0 or 100%. If they really don't care about the
output status then they can call pwm_disable().

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

      reply	other threads:[~2015-03-27 18:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12  9:44 [PATCH 0/2] leds/pwm: don't call pwm_disable when setting brightness Uwe Kleine-König
2015-02-12  9:44 ` [PATCH 1/2] pwm/doc: Clearify that the pin state after pwm_disable is undefined Uwe Kleine-König
2015-02-12  9:44 ` [PATCH 2/2] leds/pwm: Don't disable pwm when setting brightness to 0 Uwe Kleine-König
2015-02-12  9:47   ` Uwe Kleine-König
2015-02-24 18:56   ` Stefan Wahren
2015-02-24 19:06     ` Uwe Kleine-König
2015-02-25  8:13       ` Stefan Wahren
2015-02-25  8:42         ` Uwe Kleine-König
2015-03-25 10:14 ` [PATCH 0/2] leds/pwm: don't call pwm_disable when setting brightness Uwe Kleine-König
2015-03-25 12:00   ` Thierry Reding
2015-03-27  8:59     ` Uwe Kleine-König
2015-03-27 11:26       ` Thierry Reding
2015-03-27 14:35         ` Uwe Kleine-König
2015-03-27 15:43           ` Thierry Reding
2015-03-27 18:49             ` Sascha Hauer [this message]

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=20150327184901.GY9742@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=cooloney@gmail.com \
    --cc=elder@linaro.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=markus.mayer@linaro.org \
    --cc=rpurdie@rpsys.net \
    --cc=sjoerd.simons@collabora.co.uk \
    --cc=thierry.reding@gmail.com \
    --cc=tim.kryger@linaro.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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).