Messages in this thread | | | Date | Thu, 10 Apr 2014 07:55:23 +0200 | From | Sascha Hauer <> | Subject | Re: [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/
| |