Hi,
Tim Kryger wrote:
> On Mon, Apr 7, 2014 at 10:02 PM, Lothar Waßmann <[email protected]>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.
>
OK. But for a periodic signal this doesn't make any difference. It's
just a matter of where you set your reference point.
Only if you program the PWM to create a single cycle you would see the
difference. I wonder if this is a real life usecase though.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
http://www.karo-electronics.de | [email protected]
___________________________________________________________
On Wed, Apr 09, 2014 at 08:04:50AM +0200, Lothar Waßmann wrote:
> Hi,
>
> Tim Kryger wrote:
> > On Mon, Apr 7, 2014 at 10:02 PM, Lothar Waßmann <[email protected]>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.
> >
> OK. But for a periodic signal this doesn't make any difference. It's
> just a matter of where you set your reference point.
> Only if you program the PWM to create a single cycle you would see the
> difference. I wonder if this is a real life usecase though.
It doesn't make a difference if all you're concerned about is the signal
power (which happens to be the case for LED and backlight use-cases).
Currently any in-kernel users only care about the signal power, but
there's no guarantee that it will stay that way. Furthermore, PWM
channels are exposed to userspace via sysfs, so code that we don't
actually see may rely on this behaviour.
Thierry