Commit Graph

358 Commits

Author SHA1 Message Date
Boris Brezillon cc51846ba8 pwm: atmel-hlcdc: Fix default PWM polarity
The PWM device exposed by the HLCDC IP is configured with an inverted
polarity by default. Registering the PWM chip with the normal polarity
was not a problem before commit 42e8992c58d4 ("pwm: Add core
infrastructure to allow atomic updates") because the ->set_polarity()
hook was called no matter the current polarity state, but this is no longer
the case.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-06-14 10:51:45 +02:00
Ryo Kodama fe5aa34d6e pwm: sysfs: Get return value from pwm_apply_state()
This patch adds to check the return value from pwm_apply_state()
used in enable_store(). The error of enable_store() doesn't work
if the return value doesn't received.

Signed-off-by: Ryo Kodama <ryo.kodama.vz@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Fixes: 39100ceea7 ("pwm: Switch to the atomic API")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-06-10 14:24:40 +02:00
Brian Norris ef2bf4997f pwm: Improve args checking in pwm_apply_state()
It seems like in the process of refactoring pwm_config() to utilize the
newly-introduced pwm_apply_state() API, some args/bounds checking was
dropped.

In particular, I noted that we are now allowing invalid period
selections, e.g.:

  # echo 1 > /sys/class/pwm/pwmchip0/export
  # cat /sys/class/pwm/pwmchip0/pwm1/period
  100
  # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
  [... driver may or may not reject the value, or trigger some logic bug ...]

It's better to see:

  # echo 1 > /sys/class/pwm/pwmchip0/export
  # cat /sys/class/pwm/pwmchip0/pwm1/period
  100
  # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
  -bash: echo: write error: Invalid argument

This patch reintroduces some bounds checks in both pwm_config() (for its
signed parameters; we don't want to convert negative values into large
unsigned values) and in pwm_apply_state() (which fix the above described
behavior, as well as other potential API misuses).

Fixes: 5ec803edcb ("pwm: Add core infrastructure to allow atomic updates")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-06-10 14:21:00 +02:00
Linus Torvalds ecc5fbd5ef pwm: Changes for v4.7-rc1
This set of changes introduces an atomic API to the PWM subsystem. This
 is influenced by the DRM atomic API that was introduced a while back,
 though it is obviously a lot simpler. The fundamental idea remains the
 same, though: drivers provide a single callback to implement the atomic
 configuration of a PWM channel.
 
 As a side-effect the PWM subsystem gains the ability for initial state
 retrieval, so that the logical state mirrors that of the hardware. Many
 use-cases don't care about this, but for others it is essential.
 
 These new features require changes in all users, which these patches
 take care of. The core is transitioned to use the atomic callback if
 available and provides a fallback mechanism for other drivers.
 
 Changes to transition users and drivers to the atomic API are postponed
 to v4.8.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJXRcVWAAoJEN0jrNd/PrOhO3EP/RDuuco1fROml1ElCjcnWWfv
 3dPyKEJhZktMmRNd/V0zMUJiOwr77wlbX4oQ5HajMHNYFQ65jfihbbylhSDepnxg
 mjKV/yo18rzYZt9fv8huwvlwMOlLrJ9wQn4Gkbr5tzke6nITp52DTNH5y/anPQIk
 B7neA1TerodAbE9FWjYuBZIltkmYZDqdm//RCHXVyYym8VuotE+jf+nrMXI78FoL
 lgG64z/2OaGI+NZJQcpWftuz9nnenpa3sSLrvpitWEb/dAsXroMW/f08uVuOW87v
 0xk7N7zmEkef7izVOWiPOK/MxIdc8hI4A5JftzMJ7nbgJvwG78dJiOxgFhrJYx0z
 7zrYfjvvzjW0dpjZUvO37T/V5Rfxrk9sM7qUHJmN0+1oEkkCo1/c75JWTU2AmT4l
 qkJdOGhgv7LumIiwbEyxc/5Jyh1akKOUX2svO0+0dptLRX2UpN3yeKIYinG1dAuT
 86+/uuM6CL5gc+jVZ3GLNWfzHUu2RFVX0r0pzywq53pK5gMEs5WyxoIb5mHb8liA
 sHsrZ3wbGGn95yZo8CwkzXIUsUH7qKYK+UVWA6OVBoTq4AOBZtII1AqvUttl25qL
 xuKpj70xaBhK7VGqzDYQ68lqBaRySh+yzL/QsmnPEyx59mW81ytMrsn1Kmnuae2l
 bzUsnWrpHc6530fRggTD
 =sxT9
 -----END PGP SIGNATURE-----

Merge tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

Pull pwm updates from Thierry Reding:
 "This set of changes introduces an atomic API to the PWM subsystem.
  This is influenced by the DRM atomic API that was introduced a while
  back, though it is obviously a lot simpler.  The fundamental idea
  remains the same, though: drivers provide a single callback to
  implement the atomic configuration of a PWM channel.

  As a side-effect the PWM subsystem gains the ability for initial state
  retrieval, so that the logical state mirrors that of the hardware.
  Many use-cases don't care about this, but for others it is essential.

  These new features require changes in all users, which these patches
  take care of.  The core is transitioned to use the atomic callback if
  available and provides a fallback mechanism for other drivers.

  Changes to transition users and drivers to the atomic API are
  postponed to v4.8"

* tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (30 commits)
  pwm: Add information about polarity, duty cycle and period to debugfs
  pwm: Switch to the atomic API
  pwm: Update documentation
  pwm: Add core infrastructure to allow atomic updates
  pwm: Add hardware readout infrastructure
  pwm: Move the enabled/disabled info into pwm_state
  pwm: Introduce the pwm_state concept
  pwm: Keep PWM state in sync with hardware state
  ARM: Explicitly apply PWM config extracted from pwm_args
  drm: i915: Explicitly apply PWM config extracted from pwm_args
  input: misc: pwm-beeper: Explicitly apply PWM config extracted from pwm_args
  input: misc: max8997: Explicitly apply PWM config extracted from pwm_args
  backlight: lm3630a: explicitly apply PWM config extracted from pwm_args
  backlight: lp855x: Explicitly apply PWM config extracted from pwm_args
  backlight: lp8788: Explicitly apply PWM config extracted from pwm_args
  backlight: pwm_bl: Use pwm_get_args() where appropriate
  fbdev: ssd1307fb: Use pwm_get_args() where appropriate
  regulator: pwm: Use pwm_get_args() where appropriate
  leds: pwm: Use pwm_get_args() where appropriate
  input: misc: max77693: Use pwm_get_args() where appropriate
  ...
2016-05-25 10:40:15 -07:00
Thierry Reding 18c588786c Merge branch 'for-4.7/pwm-atomic' into for-next 2016-05-17 14:57:58 +02:00
Thierry Reding bf5dd9abcb Merge branch 'for-4.7/pwm-args' into for-next 2016-05-17 14:57:47 +02:00
Heiko Stübner 23e3523f5d pwm: Add information about polarity, duty cycle and period to debugfs
The PWM states make it possible to also output the polarity, duty cycle
and period information in the debugfs summary output. This simplifies
gathering information about PWMs without needing to walk through the
sysfs attributes of every PWM.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: use more spaces in debugfs output]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:05 +02:00
Boris Brezillon 39100ceea7 pwm: Switch to the atomic API
Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls
by pwm_get/apply_state().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:04 +02:00
Boris Brezillon 5ec803edcb pwm: Add core infrastructure to allow atomic updates
Add an ->apply() method to the pwm_ops struct to allow PWM drivers to
implement atomic updates. This method is preferred over the ->enable(),
->disable() and ->config() methods if available.

Add the pwm_apply_state() function to the PWM user API.

Note that the pwm_apply_state() does not guarantee the atomicity of the
update operation, it all depends on the availability and implementation
of the ->apply() method.

pwm_enable/disable/set_polarity/config() are now implemented as wrappers
around the pwm_apply_state() function.

pwm_adjust_config() is allowing smooth handover between the bootloader
and the kernel. This function tries to adapt the current PWM state to
the PWM arguments coming from a PWM lookup table or a DT definition
without changing the duty_cycle/period proportion.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: fix a couple of typos]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:03 +02:00
Boris Brezillon 15fa8a43c1 pwm: Add hardware readout infrastructure
Add a ->get_state() function to the pwm_ops struct to let PWM drivers
initialize the PWM state attached to a PWM device.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:03 +02:00
Boris Brezillon 09a7e4a3d9 pwm: Move the enabled/disabled info into pwm_state
Prepare the transition to PWM atomic update by moving the enabled and
disabled state into the pwm_state struct. This way we can easily update
the whole PWM state by copying the new state in the ->state field.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:02 +02:00
Boris Brezillon 43a276b003 pwm: Introduce the pwm_state concept
The PWM state, represented by its period, duty_cycle and polarity is
currently directly stored in the PWM device. Declare a pwm_state
structure embedding those field so that we can later use this struct
to atomically update all the PWM parameters at once.

All pwm_get_xxx() helpers are now implemented as wrappers around
pwm_get_state().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:02 +02:00
Boris Brezillon a8c3862551 pwm: Keep PWM state in sync with hardware state
Before the introduction of pwm_args, the core was resetting the PWM
period and polarity states to the reference values (those provided
through the DT, a PWM lookup table or hardcoded in the driver).

Now that all PWM users are correctly using pwm_args to configure their
PWM device, we can safely remove the pwm_apply_args() call in pwm_get()
and of_pwm_get().

We can also get rid of the pwm_set_period() call in pwm_apply_args(),
because PWM users are now directly using pargs->period instead of
pwm_get_period(). By doing that we avoid messing with the current PWM
period.

The only remaining bit in pwm_apply_args() is the initial polarity
setting, and it should go away when all PWM users have been patched to
use the atomic API (with this API the polarity will be set along with
other PWM arguments when configuring the PWM).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:47:30 +02:00
Boris Brezillon 4b58896f72 pwm: Use pwm_get/set_xxx() helpers where appropriate
Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx
field. Doing that will ease adaptation of the PWM framework to support
atomic update.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:44:59 +02:00
Boris BREZILLON 459a25afe9 pwm: Get rid of pwm->lock
PWM devices are not protected against concurrent accesses. The lock in
struct pwm_device might let PWM users think it is, but it's actually
only protecting the enabled state.

Removing this lock should be fine as long as all PWM users are aware
that accesses to the PWM device have to be serialized, which seems to be
the case for all of them except the sysfs interface. Patch the sysfs
code by adding a lock to the pwm_export struct and making sure it's
taken for all relevant accesses to the exported PWM device.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:44:59 +02:00
Boris BREZILLON 3587c26090 pwm: rcar: Make use of pwm_is_enabled()
Commit 5c31252c4a ("pwm: Add the pwm_is_enabled() helper") introduced
a new function to test whether a PWM device is enabled or not without
manipulating PWM internal fields.

Hiding this is necessary if we want to smoothly move to the atomic PWM
config approach without impacting PWM drivers. Fix this driver to use
pwm_is_enabled() instead of directly accessing the ->flags field.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:44:57 +02:00
Boris Brezillon fbd45a1298 pwm: Fix pwm_apply_args() call sites
pwm_apply_args() is supposed to initialize a PWM device according to the
arguments provided by the DT or the PWM lookup, but this function was
called inside pwm_device_request(), which in turn was called before the
core had a chance to initialize the pwm->args fields.

Fix that by calling pwm_apply_args directly in pwm_get() and of_pwm_get()
after initializing pwm->args field.

This commit also fixes an invalid pointer dereference introduced by
commit e39c0df1be ("pwm: Introduce the pwm_args concept").

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: e39c0df1be ("pwm: Introduce the pwm_args concept")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:41:18 +02:00
Mark Brown 39d652e066 Merge remote-tracking branches 'regulator/topic/pwm', 'regulator/topic/qcom-spmi', 'regulator/topic/rk808' and 'regulator/topic/s2mps11' into regulator-next 2016-05-13 14:23:46 +01:00
Thierry Reding 2907f8abb7 pwm: Use kcalloc() instead of kzalloc()
kcalloc() should be preferred for allocations of arrays over kzalloc()
with multiplication.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-03 13:57:05 +02:00
Thierry Reding 83a98864ff pwm: Add missing newline
checkpatch requires that declarations be separated from code by a blank
line. Add one for readability and to silence the warning.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-03 13:57:03 +02:00
Boris Brezillon e39c0df1be pwm: Introduce the pwm_args concept
Currently the PWM core mixes the current PWM state with the per-platform
reference config (specified through the PWM lookup table, DT definition
or directly hardcoded in PWM drivers).

Create a struct pwm_args to store this reference configuration, so that
PWM users can differentiate between the current and reference
configurations.

Patch all places where pwm->args should be initialized. We keep the
pwm_set_polarity/period() calls until all PWM users are patched to use
pwm_args instead of pwm_get_period/polarity().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: reword kerneldoc comments]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-03 13:44:37 +02:00
Stefan Agner ad06fdeeef pwm: fsl-ftm: Use flat regmap cache
Use flat regmap cache to avoid lockdep warning at probe:

[    0.697285] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755 lockdep_trace_alloc+0x15c/0x160()
[    0.697449] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))

The RB-tree regmap cache needs to allocate new space on first writes.
However, allocations in an atomic context (e.g. when a spinlock is held)
are not allowed. The function regmap_write calls map->lock, which
acquires a spinlock in the fast_io case. Since the pwm-fsl-ftm driver
uses MMIO, the regmap bus of type regmap_mmio is being used which has
fast_io set to true.

The MMIO space of the pwm-fsl-ftm driver is reasonable condense, hence
using the much faster flat regmap cache is anyway the better choice.

Signed-off-by: Stefan Agner <stefan@agner.ch>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-04-14 16:54:00 +02:00
David Rivshin 922201d129 pwm: omap-dmtimer: Add debug message for effective period and duty cycle
After going through the math and constraints checking to compute load
and match values, it is helpful to know what the resultant period and
duty cycle are.

Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-03-23 17:11:48 +01:00
David Rivshin 7b0883f338 pwm: omap-dmtimer: Round load and match values rather than truncate
When converting period and duty_cycle from nanoseconds to fclk cycles,
the error introduced by the integer division can be appreciable, especially
in the case of slow fclk or short period. Use DIV_ROUND_CLOSEST_ULL() so
that the error is kept to +/- 0.5 clock cycles.

Fixes: 6604c6556d ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-03-23 17:11:47 +01:00
David Rivshin cd37888142 pwm: omap-dmtimer: Add sanity checking for load and match values
Add sanity checking to ensure that we do not program load or match values
that are out of range if a user requests period or duty_cycle values which
are not achievable. The match value cannot be less than the load value (but
can be equal), and neither can be 0xffffffff. This means that there must be
at least one fclk cycle between load and match, and another between match
and overflow.

Fixes: 6604c6556d ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
[thierry.reding@gmail.com: minor coding style cleanups]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-03-23 17:11:46 +01:00
David Rivshin f8caa79226 pwm: omap-dmtimer: Fix inaccurate period and duty cycle calculations
Fix the calculation of load_value and match_value. Currently they
are slightly too low, which produces a noticeably wrong PWM rate with
sufficiently short periods (i.e. when 1/period approaches clk_rate/2).

Example:
 clk_rate=32768Hz, period=122070ns, duty_cycle=61035ns (8192Hz/50% PWM)
 Correct values: load = 0xfffffffc, match = 0xfffffffd
 Current values: load = 0xfffffffa, match = 0xfffffffc
 effective PWM: period=183105ns, duty_cycle=91553ns (5461Hz/50% PWM)

Fixes: 6604c6556d ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-03-23 17:11:45 +01:00
Vladimir Zapolskiy c5857e3f94 pwm: brcmstb: Fix check of devm_ioremap_resource() return code
The change fixes potential oops while accessing iomem on invalid address
if devm_ioremap_resource() fails due to some reason.

The devm_ioremap_resource() function returns ERR_PTR() and never returns
NULL, which makes useless a following check for NULL.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Fixes: 3a9f595702 ("pwm: Add Broadcom BCM7038 PWM controller support")
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-03-23 17:11:45 +01:00
Simon Horman 03d99531ae pwm: rcar: Depend on ARCH_RENESAS instead of ARCH_SHMOBILE
This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a
more appropriate name than SHMOBILE for the majority of Renesas ARM
based SoCs.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-03-23 17:11:44 +01:00
Wolfram Sang 0e47b5981a pwm: lpc18xx-sct: Test clock rate to avoid division by 0
The clk API may return 0 on clk_get_rate(), so we should check the
result before using it as a divisor.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-03-23 17:11:29 +01:00
Wolfram Sang bea307c16a pwm: img: Test clock rate to avoid division by 0
The clk API may return 0 on clk_get_rate(), so we should check the
result before using it as a divisor.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-03-23 17:11:02 +01:00
Thierry Reding ff01c944cf pwm: Mark all devices as "might sleep"
Commit d1cd214277 ("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 <thierry.reding@gmail.com>
2016-01-21 15:04:59 +01:00
Dan Carpenter 074726402b pwm: omap-dmtimer: Potential NULL dereference on error
"omap" is NULL so we can't dereference it.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-01-04 08:58:33 +01:00
Vegard Nossum 36d5be4bc9 pwm: add HAS_IOMEM dependency to PWM_FSL_FTM
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 <vegard.nossum@oracle.com>
Cc: Xiubo Li <Li.Xiubo@freescale.com>
Cc: Alison Wang <b18965@freescale.com>
Cc: Jingchang Lu <b35083@freescale.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Yuan Yao <yao.yuan@freescale.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-01-04 08:55:03 +01:00
Neil Armstrong 6604c6556d pwm: Add PWM driver for OMAP using dual-mode timers
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 <marathon96@gmail.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Joachim Eastwood <manabian@gmail.com>
Suggested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Tony Lindgren <tony@atomide.com>
[thierry.reding@gmail.com: coding style bikeshed, fix timer leak]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 17:25:37 +01:00
Ryo Kodama 72c16a9f98 pwm: rcar: Improve accuracy of frequency division setting
From: Ryo Kodama <ryo.kodama.vz@renesas.com>

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 <ryo.kodama.vz@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 17:02:14 +01:00
Vladimir Zapolskiy d6dbdf0dde pwm: lpc32xx: return ERANGE, if requested period is not supported
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 <vz@mleia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 17:01:06 +01:00
Vladimir Zapolskiy 5a9fc9c666 pwm: lpc32xx: fix and simplify duty cycle and period calculations
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 <vz@mleia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 17:00:49 +01:00
Vladimir Zapolskiy 82aff048dd pwm: lpc32xx: make device usable with common clock framework
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 <vz@mleia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 17:00:33 +01:00
Vladimir Zapolskiy ebe1fca350 pwm: lpc32xx: correct number of PWM channels from 2 to 1
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 <vz@mleia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 17:00:01 +01:00
Stefan Agner 816aec2325 pwm: fsl-ftm: Fix clock enable/disable when using PM
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 <stefan@agner.ch>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 16:54:32 +01:00
Mika Westerberg 37670676a1 pwm: lpss: Rework the sequence of programming PWM_SW_UPDATE
Setting of PWM_SW_UPDATE is bit different in Intel Broxton compared to the
previous generation SoCs. Previously it was OK to set the bit many times
(from userspace via sysfs for example) before the PWM is actually enabled.

Starting from Intel Broxton it seems that we must set PWM_SW_UPDATE only
once before the PWM is enabled. Otherwise it is possible that the PWM does
not start properly.

Change the sequence of how PWM_SW_UPDATE is programmed so that we only set
it in pwm_lpss_config() when the PWM is already enabled. The initial
setting of PWM_SW_UPDATE will be done when PWM gets enabled. This should
make the driver work with the previous generation Intel SoCs and Broxton.

Add also small delay after the bit is set to let the hardware propagate it
properly.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 16:52:09 +01:00
Andy Shevchenko 6f90a00c66 pwm: lpss: Select core part automatically
We have two users of core part right now. Let them to select core part
automatically.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 16:50:31 +01:00
qipeng.zha 883e4d070f pwm: lpss: Update PWM setting for Broxton
For Broxton PWM controller, base unit is defined as 8-bit integer
and 14-bit fraction, so need to update base unit setting to output
wave with right frequency.

Signed-off-by: Qipeng Zha <qipeng.zha@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 16:45:38 +01:00
Stefan Wahren 6ef7d1c46f pwm: bcm2835: Fix email address specification
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 16:45:32 +01:00
Stefan Wahren fd13c14426 pwm: bcm2835: Prevent division by zero
It's possible that the PWM clock becomes an orphan. So better check the
result of clk_get_rate() in order to prevent a division by zero.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 16:45:10 +01:00
Stefan Wahren ebe88b6ae4 pwm: bcm2835: Calculate scaler in ->config()
Currently pwm-bcm2835 assumes a fixed clock rate and stores the
resulting scaler in the driver structure. But with the upcoming
PWM clock support for clk-bcm2835 the rate could change, so
calculate the scaler in the ->config() callback.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 16:44:36 +01:00
Mika Westerberg c7b91b33cf pwm: lpss: Remove ->free() callback
The LPSS PWM driver calls pwm_lpss_disable() when the PWM device is
released (for example unexported from sysfs). This in turn calls
pm_runtime_put() which makes runtime PM count to be unbalanced if the
device has not been enabled at this point.

This is easy to reproduce:

  # cd /sys/class/pwm/pwmchip0
  # echo 0 > export
  # echo 0 > unexport

The count is unbalanced and prevents the PWM device from being powered on
next time.

Fix this by removing ->free() callback. There are no resources to be
released anyway.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-12-16 16:31:27 +01:00
Linus Torvalds c8fff3ed32 pwm: Changes for v4.4-rc1
This round contains a couple of new drivers for the Marvell Berlin
 family of SoCs, various SoCs from Renesas and Broadcom as well as the
 backlight PWM present on MediaTek SoCs.
 
 Further existing drivers are extended to support a wider range of
 hardware.
 
 The remaining patches are minor fixes and cleanups across the board.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJWQ12TAAoJEN0jrNd/PrOhVMwP/RK0Vr0GogxpHc4endw/L1Tf
 aDmC8LVxEBxaUOtjWB2sVB4ZSGfHfThOLTddiw5CTrka2fSAMTwhJueu6EZuLQ/V
 lJWb0bgneaH9VYqL26BPPw0sDHpFOBTg+QgXWsvipH3YQIWlOlSsQJZNrVpNkGWe
 Iw/+Ic45YwtGPLxwjgHLJyRZVuu6RV3se0voZhIuj33OLuYJ/1MCFYKTb3M8LZk3
 6q+NwkhSnKgftu5rYRL+HvFHdu3p06W3hxTBp8KbPCDHpKVYY4S6z2pI7ol40BiT
 7DFxr+PJ2GWURWVh9K6zmsamYAcKKeJhRjb2G8nBqgbKd9w+buNcAFjVkFAwGPK9
 g6/QO6s/ZXwUOb518j3X/ABx/0dJmZRZXtlLqBikzlpjKLVrIGpgNz+s9nWzZq90
 VJeun5S2FUKZYXqCquUWMZvSIDn0zyvwsW4p4bs4U/SuOGfqUnzeGW6+LOaY+RTj
 adzo3WxOmkWP2NRjWIwdzuLYekWgDFusbIsmWNfPWnu+1DNGzRZ7jTKUdSELQCM0
 mzoZIRxxsU90jYA9XXfDWxS5X/h7YdkMhzxE/JI5aV7kUAHgV6U2F8eWCWV3WcRg
 pPRN8BJ+bO6DLdj5AwN60GNU79M8ciRLyhzqTAN3dsvLPhliAs/b7XyhADh+wLSk
 XRX5sTGww3pnvKZLIIPh
 =gwbt
 -----END PGP SIGNATURE-----

Merge tag 'pwm/for-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

Pull pwm updates from Thierry Reding:
 "This round contains a couple of new drivers for the Marvell Berlin
  family of SoCs, various SoCs from Renesas and Broadcom as well as the
  backlight PWM present on MediaTek SoCs.

  Further existing drivers are extended to support a wider range of
  hardware.

  The remaining patches are minor fixes and cleanups across the board.

  Note that one of the patches included in this pull request is against
  arch/unicore32.  I've included it here because I couldn't get a
  response from Guan Xuetao and I consider the change low-risk.
  Equivalent patches have been merged and tested in Samsung and PXA
  trees.  The goal is to finally get rid of legacy code paths that have
  repeatedly been causing headaches"

* tag 'pwm/for-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (24 commits)
  pwm: sunxi: Fix whitespace issue
  pwm: sysfs: Make use of the DEVICE_ATTR_[RW][WO] macro's
  pwm: sysfs: Remove unnecessary temporary variable
  unicore32: nb0916: Use PWM lookup table
  pwm: pwm-rcar: Revise the device tree binding document about compatible
  pwm: Return -ENODEV if no PWM lookup match is found
  pwm: sun4i: Add support for PWM controller on sun5i SoCs
  pwm: Set enable state properly on failed call to enable
  pwm: lpss: Add support for runtime PM
  pwm: lpss: Add more Intel Broxton IDs
  pwm: lpss: Support all four PWMs on Intel Broxton
  pwm: lpss: Add support for multiple PWMs
  pwm-pca9685: enable ACPI device found on Galileo Gen2
  pwm: Add MediaTek display PWM driver support
  dt-bindings: pwm: Add MediaTek display PWM bindings
  pwm: tipwmss: Enable on TI DRA7x and AM437x
  pwm: atmel-hlcdc: add sama5d2 SoC support.
  pwm: Add Broadcom BCM7038 PWM controller support
  Documentation: dt: add Broadcom BCM7038 PWM controller binding
  pwm: Add support for R-Car PWM Timer
  ...
2015-11-11 09:16:10 -08:00
Olliver Schinagl 5dcd7b42f1 pwm: sunxi: Fix whitespace issue
This patch changes no code, it just fixes the whitespacing. Operators
should be separated from operands by a single space.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-11-10 13:06:47 +01:00
Olliver Schinagl 65cdc6914a pwm: sysfs: Make use of the DEVICE_ATTR_[RW][WO] macro's
For the npwm property the PWM sysfs interface already made use of the
DEVICE_ATTR_RO macro. This patch expands this to the other sysfs
properties so that the code base is concise and makes use of this
helpful macro.

This has the advantage of slightly reducing the code size, improving
readability and no longer using magic values for permissions.

Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-11-10 13:06:46 +01:00