26 May, 2016
1 commit
-
…erry.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
...
17 May, 2016
13 commits
-
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
Signed-off-by: Boris Brezillon
[thierry.reding@gmail.com: use more spaces in debugfs output]
Signed-off-by: Thierry Reding -
Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls
by pwm_get/apply_state().Signed-off-by: Boris Brezillon
Signed-off-by: Thierry Reding -
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
[thierry.reding@gmail.com: fix a couple of typos]
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding -
Commit 5c31252c4a86 ("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
Signed-off-by: Thierry Reding -
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 e39c0df1be5a ("pwm: Introduce the pwm_args concept").Signed-off-by: Boris Brezillon
Fixes: e39c0df1be5a ("pwm: Introduce the pwm_args concept")
Signed-off-by: Thierry Reding
13 May, 2016
1 commit
-
…', 'regulator/topic/rk808' and 'regulator/topic/s2mps11' into regulator-next
03 May, 2016
3 commits
-
kcalloc() should be preferred for allocations of arrays over kzalloc()
with multiplication.Signed-off-by: Thierry Reding
-
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
-
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
[thierry.reding@gmail.com: reword kerneldoc comments]
Signed-off-by: Thierry Reding
14 Apr, 2016
1 commit
-
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
Cc: Mark Brown
Signed-off-by: Thierry Reding
24 Mar, 2016
8 commits
-
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
Acked-by: Neil Armstrong
Signed-off-by: Thierry Reding -
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: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: David Rivshin
Acked-by: Neil Armstrong
Signed-off-by: Thierry Reding -
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: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: David Rivshin
Acked-by: Neil Armstrong
[thierry.reding@gmail.com: minor coding style cleanups]
Signed-off-by: Thierry Reding -
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: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: David Rivshin
Acked-by: Neil Armstrong
Tested-by: Adam Ford
Signed-off-by: Thierry Reding -
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
Fixes: 3a9f5957020f ("pwm: Add Broadcom BCM7038 PWM controller support")
Acked-by: Florian Fainelli
Signed-off-by: Thierry Reding -
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
Acked-by: Geert Uytterhoeven
Signed-off-by: Thierry Reding -
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
Acked-by: Joachim Eastwood
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding
21 Jan, 2016
1 commit
-
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
04 Jan, 2016
2 commits
-
"omap" is NULL so we can't dereference it.
Signed-off-by: Dan Carpenter
Signed-off-by: Thierry Reding -
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 statusdevm_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
17 Dec, 2015
6 commits
-
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 -
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 -
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 -
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 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.05vPWM_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 -
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 -
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
16 Dec, 2015
4 commits
-
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 -
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
Signed-off-by: Thierry Reding -
We have two users of core part right now. Let them to select core part
automatically.Signed-off-by: Andy Shevchenko
Signed-off-by: Mika Westerberg
Signed-off-by: Thierry Reding -
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
Acked-by: Mika Westerberg
Signed-off-by: Thierry Reding
