linux-stable.git/drivers/pwm, branch v4.5

pwm: Mark all devices as "might sleep"

2016-01-21T14:04:59+00:00

Commit d1cd21427747 ("pwm: Set enable state properly on failed call to
enable") introduced a mutex that is needed to protect internal state of
PWM devices. Since that mutex is acquired in pwm_set_polarity() and in
pwm_enable() and might potentially block, all PWM devices effectively
become "might sleep".

It's rather pointless to keep the .can_sleep field around, but given
that there are external users let's postpone the removal for the next
release cycle.

Signed-off-by: Thierry Reding

pwm: omap-dmtimer: Potential NULL dereference on error

2016-01-04T07:58:33+00:00

"omap" is NULL so we can't dereference it.

Signed-off-by: Dan Carpenter 
Signed-off-by: Thierry Reding

pwm: add HAS_IOMEM dependency to PWM_FSL_FTM

2016-01-04T07:55:03+00:00

Ran into this on UML:

drivers/built-in.o: In function `fsl_pwm_probe':
linux/drivers/pwm/pwm-fsl-ftm.c:436: undefined reference to `devm_ioremap_resource'
collect2: error: ld returned 1 exit status

devm_ioremap_resource() is defined only when HAS_IOMEM is selected.

Signed-off-by: Vegard Nossum 
Cc: Xiubo Li 
Cc: Alison Wang 
Cc: Jingchang Lu 
Cc: Sascha Hauer 
Cc: Yuan Yao 
Cc: Thierry Reding 
Signed-off-by: Thierry Reding

pwm: Add PWM driver for OMAP using dual-mode timers

2015-12-16T16:25:37+00:00

Adds support for using a OMAP dual-mode timer with PWM capability
as a Linux PWM device. The driver controls the timer by using the
dmtimer API.

Add a platform_data structure for each pwm-omap-dmtimer nodes containing
the dmtimers functions in order to get driver not rely on platform
specific functions.

Cc: Grant Erickson 
Cc: NeilBrown 
Cc: Joachim Eastwood 
Suggested-by: Tony Lindgren 
Signed-off-by: Neil Armstrong 
Acked-by: Tony Lindgren 
[thierry.reding@gmail.com: coding style bikeshed, fix timer leak]
Signed-off-by: Thierry Reding

pwm: rcar: Improve accuracy of frequency division setting

2015-12-16T16:02:14+00:00

From: Ryo Kodama 

When period_ns is set to the same value of RCAR_PWM_MAX_CYCLE in
rcar_pwm_get_clock_division(), this function should allow such value
for improving accuracy of frequency division setting.

Signed-off-by: Ryo Kodama 
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Thierry Reding

pwm: lpc32xx: return ERANGE, if requested period is not supported

2015-12-16T16:01:06+00:00

Instead of silent acceptance of unsupported requested configuration
for PWM period and setting the boundary supported value, return
-ERANGE to a caller.

Duty period value equal to 0 or period is still accepted to allow
configuration by PWM sysfs interface, when it is set to 0 by default.

For reference this is a list of restrictions on period_ns == 1/freq:

  | PWM parent clock | parent clock divisor | max freq | min freq |
  +------------------+----------------------+----------+----------+
  |   HCLK == 13 MHz |      1 (min)         | 50.7 KHz | 198.3 Hz |
  |   HCLK == 13 MHz |     15 (max)         | 3.38 KHz | 13.22 Hz |
  |  RTC == 32.7 KHz |      1 (min)         |   128 Hz |   0.5 Hz |
  |  RTC == 32.7 KHz |     15 (max)         | 8.533 Hz | 0.033 Hz |

Note that PWM sysfs interface does not support setting of period more
than NSEC_PER_SEC / MAX_INT32 ~ 2 seconds, however this PWM controller
supports a period up to 30 seconds.

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Thierry Reding

pwm: lpc32xx: fix and simplify duty cycle and period calculations

2015-12-16T16:00:49+00:00

The change fixes a problem, if duty_ns is too small in comparison
to period_ns (as a valid corner case duty_ns is 0 ns), then due to
PWM_DUTY() macro applied on a value the result is overflowed over 8
bits, and instead of the highest bitfield duty cycle value 0xff the
invalid duty cycle bitfield value 0x00 is written.

For reference the LPC32xx spec defines PWMx_DUTY bitfield description
is this way and it seems to be correct:

 [Low]/[High] = [PWM_DUTY]/[256-PWM_DUTY], where 0 < PWM_DUTY <= 255.

In addition according to my oscilloscope measurements LPC32xx PWM is
"tristate" in sense that it produces a wave with floating min/max
voltage levels for different duty cycle values, for corner cases:

  PWM_DUTY == 0x01 => signal is in range from -1.05v to 0v
  ....
  PWM_DUTY == 0x80 => signal is in range from -0.75v to +0.75v
  ....
  PWM_DUTY == 0xff => signal is in range from 0v to +1.05v

  PWM_DUTY == 0x00 => signal is around 0v, PWM is off

Due to this peculiarity on very long period ranges (less than 1KHz)
and odd pre-divider values PWM generated wave does not remind a
clock shape signal, but rather a heartbit shape signal with positive
and negative peaks, so I would recommend to use high-speed HCLK clock
as a PWM parent clock and avoid using RTC clock as a parent.

The change corrects PWM output in corner cases and prevents any
possible overflows in calculation of values for PWM_DUTY and
PWM_RELOADV bitfields, thus helper macro definitions may be removed.

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Thierry Reding

pwm: lpc32xx: make device usable with common clock framework

2015-12-16T16:00:33+00:00

As a preparatory change for switching LPC32xx mach support to common
clock framework fix clk_enable/clk_disable calls without matching
clk_prepare/clk_unprepare.

The driver can not be used on a platform with common clock framework
until clk_prepare/clk_unprepare calls are added, otherwise clk_enable
calls will fail and a WARN is generated:

    # echo 1 > /sys/bus/platform/drivers/lpc32xx-pwm/4005c000.pwm/pwm/pwmchip0/pwm0/enable
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 701 at drivers/clk/clk.c:727 clk_core_enable+0x2c/0xa4()
    Modules linked in: sc16is7xx
    CPU: 0 PID: 701 Comm: sh Tainted: G        W       4.3.0-rc2+ #171
    Hardware name: LPC32XX SoC (Flattened Device Tree)
    Backtrace:
    [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c)
    [<>] (show_stack) from [<>] (dump_stack+0x20/0x28)
    [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8)
    [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c)
    [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xa4)
    [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38)
    [<>] (clk_enable) from [<>] (lpc32xx_pwm_enable+0x1c/0x40)
    [<>] (lpc32xx_pwm_enable) from [<>] (pwm_enable+0x48/0x5c)
    [<>] (pwm_enable) from [<>] (pwm_enable_store+0x5c/0x78)
    [<>] (pwm_enable_store) from [<>] (dev_attr_store+0x20/0x2c)
    [<>] (dev_attr_store) from [<>] (sysfs_kf_write+0x44/0x50)
    [<>] (sysfs_kf_write) from [<>] (kernfs_fop_write+0x134/0x194)
    [<>] (kernfs_fop_write) from [<>] (__vfs_write+0x34/0xdc)
    [<>] (__vfs_write) from [<>] (vfs_write+0xb8/0x140)
    [<>] (vfs_write) from [<>] (SyS_write+0x50/0x90)
    [<>] (SyS_write) from [<>] (ret_fast_syscall+0x0/0x38)

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Thierry Reding

pwm: lpc32xx: correct number of PWM channels from 2 to 1

2015-12-16T16:00:01+00:00

LPC32xx SoC has two independent PWM controllers, they have different
clock parents, clock gates and even slightly different controls, and
each of these two PWM controllers has one output channel. Due to
almost similar controls arranged in a row it is incorrectly set that
there is one PWM controller with two channels, fix this problem, which
at the moment prevents separate configuration of different clock
parents and gates for both PWM controllers.

The change makes previous PWM device node description incompatible
with this update.

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Thierry Reding

pwm: fsl-ftm: Fix clock enable/disable when using PM

2015-12-16T15:54:32+00:00

A FTM PWM instance enables/disables three clocks: The bus clock, the
counter clock and the PWM clock. The bus clock gets enabled on
pwm_request, whereas the counter and PWM clocks will be enabled upon
pwm_enable.

The driver has three closesly related issues when enabling/disabling
clocks during suspend/resume:
- The three clocks are not treated differently in regards to the
  individual PWM state enabled/requested. This can lead to clocks
  getting disabled which have not been enabled in the first place
  (a PWM channel which only has been requested going through
  suspend/resume).

- When entering suspend, the current behavior relies on the
  FTM_OUTMASK register: If a PWM output is unmasked, the driver
  assumes the clocks are enabled. However, some PWM instances
  have only 2 channels connected (e.g. Vybrid's FTM1). In that case,
  the FTM_OUTMASK reads 0x3 if all channels are disabled, even if
  the code wrote 0xff to it before. For those PWM instances, the
  current approach to detect enabled PWM signals does not work.

- A third issue applies to the bus clock only, which can get enabled
  multiple times (once for each PWM channel of a PWM chip). This is
  fine, however when entering suspend mode, the clock only gets
  disabled once.

This change introduces a different approach by relying on the enable
and prepared counters of the clock framework and using the frameworks
PWM signal states to address all three issues.

Clocks get disabled during suspend and back enabled on resume
regarding to the PWM channels individual state (requested/enabled).

Since we do not count the clock enables in the driver, this change no
longer clears the Status and Control registers Clock Source Selection
(FTM_SC[CLKS]). However, since we disable the selected clock anyway,
and we explicitly select the clock source on reenabling a PWM channel
this approach should not make a difference in practice.

Signed-off-by: Stefan Agner 
Signed-off-by: Thierry Reding