linux-pwm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: "Tim Kryger" <tim.kryger@linaro.org>,
	"Lothar Waßmann" <LW@karo-electronics.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Linux PWM List" <linux-pwm@vger.kernel.org>,
	"Shawn Guo" <shawn.guo@linaro.org>,
	"Sascha Hauer" <kernel@pengutronix.de>,
	"Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCHv3 1/3] pwm: make the PWM_POLARITY flag in DTB optional
Date: Wed, 9 Apr 2014 09:22:50 +0200	[thread overview]
Message-ID: <20140409072248.GB9886@ulmo> (raw)
In-Reply-To: <20140409061209.GF27055@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

On Wed, Apr 09, 2014 at 08:12:09AM +0200, Sascha Hauer wrote:
> On Tue, Apr 08, 2014 at 01:43:22PM -0700, Tim Kryger wrote:
> > On Mon, Apr 7, 2014 at 10:02 PM, Lothar Waßmann <LW@karo-electronics.de> wrote:
> > > Thierry Reding wrote:
> > 
> > >> No. You cannot emulate polarity inversion in software.
> > >>
> > > Why not?
> > >
> > > duty_ns = period_ns - duty_ns;
> > 
> > Since I made the same mistake, I will pass along the pointer Thierry gave me.
> > 
> > In include/linux/pwm.h the second difference for an inverted signal is
> > described.
> > 
> > /**
> >  * enum pwm_polarity - polarity of a PWM signal
> >  * @PWM_POLARITY_NORMAL: a high signal for the duration of the duty-
> >  * cycle, followed by a low signal for the remainder of the pulse
> >  * period
> >  * @PWM_POLARITY_INVERSED: a low signal for the duration of the duty-
> >  * cycle, followed by a high signal for the remainder of the pulse
> >  * period
> >  */
> > enum pwm_polarity {
> > PWM_POLARITY_NORMAL,
> > PWM_POLARITY_INVERSED,
> > };
> > 
> > Of course, I suspect not all PWM hardware respects this definition of
> > inverted output.
> > 
> > Either way, hacking the duty in software certainly would get the
> > high/low order wrong.
> 
> This only relevant if you have some reference signal the PWM must be
> relative to, for example if you combine multiple PWMs for motor control.
> For PWMs used for backlight or beepers a signal inversion in software is
> perfectly fine. And I also think that it makes sense to put it once into
> the framework instead of bothering all consumer drivers with the
> inversion.

The PWM framework itself doesn't have enough knowledge about what a PWM
is being used for. Therefore it cannot determine whether emulating
polarity inversion by reversing the duty cycle will be appropriate.

Putting such functionality into the core will prevent PWM channels from
being used for cases where the signal polarity does matter.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-04-09  7:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 13:22 pwm: imx: support output polarity inversion Lothar Waßmann
2014-03-19 13:22 ` [PATCHv3 1/3] pwm: make the PWM_POLARITY flag in DTB optional Lothar Waßmann
2014-03-19 13:22 ` [PATCHv3 2/3] pwm: imx: indentation cleanup Lothar Waßmann
2014-03-19 13:22 ` [PATCHv3 3/3] pwm: imx: support output polarity inversion Lothar Waßmann
2014-03-28  8:48 ` [PATCHv3 0/3] " Lothar Waßmann
2014-03-28  8:48   ` [PATCHv3 1/3] pwm: make the PWM_POLARITY flag in DTB optional Lothar Waßmann
2014-04-02  5:53     ` Sascha Hauer
2014-04-07 11:36       ` Thierry Reding
2014-04-08  5:02         ` Lothar Waßmann
2014-04-08 20:37           ` Tim Kryger
2014-04-09  6:04             ` Lothar Waßmann
2014-04-09  7:16               ` Thierry Reding
2014-04-08 20:43           ` Tim Kryger
2014-04-09  6:12             ` Sascha Hauer
2014-04-09  7:22               ` Thierry Reding [this message]
2014-04-10  5:55                 ` Sascha Hauer
2014-03-28  8:48   ` [PATCHv3 2/3] pwm: imx: indentation cleanup Lothar Waßmann
2014-03-28  8:49   ` [PATCHv3 3/3] pwm: imx: support output polarity inversion Lothar Waßmann
2014-04-02  5:45     ` Sascha Hauer

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=20140409072248.GB9886@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=LW@karo-electronics.de \
    --cc=arnd@arndb.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawn.guo@linaro.org \
    --cc=tim.kryger@linaro.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).