lkml.org 
[lkml]   [2014]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv3 1/3] pwm: make the PWM_POLARITY flag in DTB optional
    On Wed, Apr 09, 2014 at 09:22:50AM +0200, Thierry Reding wrote:
    > 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

    The PWM core is in no way prepared for handling such situations. Should
    we want to add support it a PWM_POLARITY_INVERSED flag would be the
    least of our problems. It could be renamed to
    PWM_POLARITY_INVERSED_ASYNC for the beeper/led drivers which do not need
    synchronization.

    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 |
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2014-04-10 08:41    [W:5.418 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site