litmus-rt-ext-res.git/drivers/pwm, branch EXT-RES

pwm: rockchip: State of PWM clock should synchronize with PWM enabled state

2017-04-21T07:31:22+00:00

commit a900152b5c29aea8134cc7a4c5db25552b3cd8f7 upstream.

If the PWM was not enabled at U-Boot loader, PWM could not work for
clock always disabled at PWM driver. The PWM clock is enabled at
beginning of pwm_apply(), but disabled at end of pwm_apply().

If the PWM was enabled at U-Boot loader, PWM clock is always enabled
unless closed by ATF. The pwm-backlight might turn off the power at
early suspend, should disable PWM clock for saving power consume.

It is important to provide opportunity to enable/disable clock at PWM
driver, the PWM consumer should ensure correct order to call PWM enable
and disable, and PWM driver ensure state of PWM clock synchronized with
PWM enabled state.

Fixes: 2bf1c98aa5a4 ("pwm: rockchip: Add support for atomic update")
Signed-off-by: David Wu 
Reviewed-by: Boris Brezillon 
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman

pwm: pca9685: Fix period change with same duty cycle

2017-03-15T02:02:46+00:00

commit 8d254a340efb12b40c4c1ff25a48a4f48f7bbd6b upstream.

When first implementing support for changing the output frequency, an
optimization was added to continue the PWM after changing the prescaler
without having to reprogram the ON and OFF registers for the duty cycle,
in case the duty cycle stayed the same. This was flawed, because we
compared the absolute value of the duty cycle in nanoseconds instead of
the ratio to the period.

Fix the problem by removing the shortcut.

Fixes: 01ec8472009c9 ("pwm-pca9685: Support changing the output frequency")
Signed-off-by: Clemens Gruber 
Reviewed-by: Mika Westerberg 
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman

pwm: Fix device reference leak

2016-11-29T15:43:24+00:00

Make sure to drop the reference to the parent device taken by
class_find_device() after "unexporting" any children when deregistering
a PWM chip.

Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal")
Signed-off-by: Johan Hovold 
Signed-off-by: Thierry Reding

pwm: meson: Add missing spin_lock_init()

2016-10-21T07:10:11+00:00

The driver uses the spin_lock but does not initialize it. Fix it.

Signed-off-by: Axel Lin 
Acked-by: Neil Armstrong 
Signed-off-by: Thierry Reding

Merge branch 'for-4.9/drivers' into for-next

2016-09-08T08:59:30+00:00

pwm: meson: Handle unknown ID values

2016-09-08T08:58:33+00:00

When building with -Wmaybe-uninitialized, we get a couple of harmless
warnings about three functions in this new driver that don't look
safe to the compiler:

drivers/pwm/pwm-meson.c: In function 'meson_pwm_get_state':
drivers/pwm/pwm-meson.c:355:26: error: 'mask' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c: In function 'meson_pwm_disable':
drivers/pwm/pwm-meson.c:263:13: error: 'enable' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c: In function 'meson_pwm_apply':
drivers/pwm/pwm-meson.c:231:13: error: 'clk_shift' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c:231:36: error: 'enable' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c:231:24: error: 'clk_enable' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Specifically, if we have a device with an ID other than 0 or 1,
this would result in undefined behavior. This is currently not
possible, but the compiler cannot be expected to know this.

This patch adds a 'default' clause to let the compiler know
what to do instead, which shuts up the warning and makes the
code slightly more resiliant in case it gets extended to other
identifiers.

Signed-off-by: Arnd Bergmann 
Acked-by: Neil Armstrong 
Signed-off-by: Thierry Reding

pwm: sti: Take the opportunity to conduct a little house keeping

2016-09-08T08:55:12+00:00

This includes fixing some Coding Style issues and re-ordering and/or
simplifying a little code.

Signed-off-by: Lee Jones 
[thierry.reding@gmail.com: applied some bikeshedding>
Signed-off-by: Thierry Reding

pwm: sti: It's now valid for number of PWM channels to be zero

2016-09-08T08:55:11+00:00

Setting up the STI PWM IP as capture only, with zero PWM output devices
is a perfectly valid configuration. It is no longer okay to assume that
there must be at least 1 PWM output device. In this patch we make the
default number of PWM output devices zero and only configure channels
explicitly requested.

Reported-by: Peter Griffin 
Signed-off-by: Lee Jones 
Signed-off-by: Thierry Reding

pwm: sti: Add PWM capture callback

2016-09-08T08:55:11+00:00

Once a PWM capture has been initiated, the capture call enables a rising
edge detection interrupt, then waits. Once each of the 3 phase changes
have been recorded the thread then wakes. The remaining part of the call
carries out the relevant calculations and returns a structure filled out
with the capture data.

Signed-off-by: Lee Jones 
Signed-off-by: Thierry Reding

pwm: sti: Add support for PWM capture interrupts

2016-09-08T08:55:10+00:00

Here we're requesting the PWM capture IRQ and supplying the handler that
will be called in the event of an interrupt to handle it.

Signed-off-by: Lee Jones 
Signed-off-by: Thierry Reding