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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
"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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
...
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>
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>
Use the result of pwm_is_enabled() directly instead of storing it in a
temporary variable.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When looking up a PWM using the lookup table, assume that all entries
will have been added already, so failure to find a match means that no
corresponding entry has been registered.
This fixes an issue where -EPROBE_DEFER would be returned if the PWM
lookup table is empty. After this fix, -EPROBE_DEFER is reserved for
situations where no provider has yet registered for a matching entry.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM controller on sun5i SoCs is identical to the one found on sun7i
SoCs. On the A13 package only one of the 2 pins is routed to the outside,
so only advertise one PWM channel there.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The pwm_enable() function didn't clear the enabled bit if a call to the
driver's ->enable() callback returned an error. The result was that the
state of the PWM core was wrong. Clearing the bit when enable returns
an error ensures the state is properly set.
Tested-by: Jonathan Richardson <jonathar@broadcom.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jonathan Richardson <jonathar@broadcom.com>
[thierry.reding@gmail.com: add missing kerneldoc for the lock]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
To be able to save some power when PWM is not in use, add support for
runtime PM for this driver. This also allows the platform to transition to
low power S0ix states when the system is idle.
Signed-off-by: Huiquan Zhong <huiquan.zhong@intel.com>
Signed-off-by: Qipeng Zha <qipeng.zha@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add more Intel Broxton ACPI and PCI IDs to the driver supported devices
list.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Intel Broxton has similar PWM than Intel Braswell but instead of one it has
four PWMs included in one PCI/ACPI device. This patch adds support for all
the four PWMs and changes the PCI part of the driver to use
'pwm_lpss_bxt_info' instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
New Intel SoCs such as Broxton will have four PWMs per PCI (or ACPI)
device. Each PWM has 1k of register space allocated from the parent device.
Add support for this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via
ACPI ID INT3492.
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add display PWM driver support to modify backlight for MT8173 and
MT6595. The PWM has one channel to control the brightness of the
display. When the (high_width / period) is closer to 1, the screen
is brighter; otherwise, it is darker.
Signed-off-by: YH Huang <yh.huang@mediatek.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
TIPWMSS is present on TI's DRA7x and AM437x SoCs. Enable its usage.
Instead of adding each SoC individually, use the more generic symbol
ARCH_OMAP2PLUS instead.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add sama5d2 hlcdc backlight PWM support. This chip doesn't have to deal with an
errata, so it's a simple addition of the mfd compatible string.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add support for the BCM7038-style PWM controller found in all BCM7xxx STB SoCs.
This controller has a hardcoded 2 channels per controller, and cascades a
variable frequency generator on top of a fixed frequency generator which offers
a range of a 148ns period all the way to ~622ms periods.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Commit dca1a4b5ff ("clk: at91: keep slow clk enabled to prevent system
hang") added a workaround for the slow clock as it is not properly handled
by its users.
Get and use the slow clock as it is necessary for the timer counters.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
This patch adds support for R-Car SoCs PWM Timer. The PWM timer of
R-Car H2 has 7 channels. So, we can use the channels if we describe
device tree nodes.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add a PWM controller driver for the Marvell Berlin SoCs. This PWM
controller has 4 channels.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This platform driver has a OF device ID table but the OF module alias
information is not created so module autoloading won't work.
This patch adds the missing MODULE_DEVICE_TABLE() for OF to export that
information so modules have the correct aliases built-in and autoloading
works correctly.
A longer explanation by Javier Canillas can be found here:
https://lkml.org/lkml/2015/7/30/519
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This set of changes introduces the beginnings of a new API that's based
around the concept of states that can be atomically applied. Drivers go
to various lengths to implement something similar, which indicates that
the core should really be providing the necessary framework.
On top of that, there is a bit of cleanup as well as improved kerneldoc
and integration into the device-drivers DocBook.
Regarding drivers there is a new one for the NXP LPC18xx family of SoCs
and a couple of fixes for existing drivers (pca9685, Broadcom Kona and
Atmel HLCDC).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJV8DLwAAoJEN0jrNd/PrOhSf4P/RYwdDGB/xvI0ifXS5p9znNA
hr6+MUH87+f9NY1jcDye0RrxIkRsckQ3x3fe/nTmODjCSM/cyrWrVAEKbkqE5bZH
LTRT6M6jolSAUGXFTBDuHktYdMU9yaD0PJvm0RgBEC7z2BeBmCgCXTFc4paxw2GA
NvikouXZX9XDlXp598pHPFoL92vTLevQQMBHYW9myY8cjAOG0X8Dn05xQaC2kRvJ
5q+OD1D/kIEMJxONrpef7bwzPgCkuGTHqqIIm6gLVoPBPGWz43kaZ5+x/j2E98E9
fkfcP+21GvZ/tdAUEkrRnpy5Jnn+Nk0m+yzPtRkvj4TLwPd93EjumiPg5sb53pys
ZfoHgnOAArVxEnTYLQk4IyBWcHyyzIxZBKZZpXkMXjY4QVq6wZLAP+vyCAzcm4tV
vHqUN5BYAkwYPUNU58fgFWGHg6rFlb2QSN1bIj5opgygWmRbPgmwVj3trvS2Dkoe
NOv47pp0OyWvTvx+wLql8BUt1zK1M6QldfPF6pR4FB18SLyKYH89ZbjHTyGdsuCv
SiaWrqNB4eRmEKW1MA20Kc4wlF5c2peXVp2EHeddh/oHPES8IVWBPMPwSkJZrpQb
bIUMStKlJ/Y1GPo6Dd7njK/kA3GwwsbYXYHmyPm0IRuAeZKrzGzVSIIljbfpL6Vf
LBuKRMQHY4iWtF8A5SmY
=ymH8
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.3-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 the beginnings of a new API that's
based around the concept of states that can be atomically applied.
Drivers go to various lengths to implement something similar, which
indicates that the core should really be providing the necessary
framework.
On top of that, there is a bit of cleanup as well as improved
kerneldoc and integration into the device-drivers DocBook.
Regarding drivers there is a new one for the NXP LPC18xx family of
SoCs and a couple of fixes for existing drivers (pca9685, Broadcom
Kona and Atmel HLCDC)"
* tag 'pwm/for-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
ARM: at91: pwm: atmel-hlcdc: Add at91sam9n12 errata
pwm: Add NXP LPC18xx PWM/SCT DT binding documentation
pwm: NXP LPC18xx PWM/SCT driver
pwm-pca9685: Support changing the output frequency
pwm-pca9685: Fix several driver bugs
pwm: kona: Modify settings application sequence
pwm: pca9685: Drop owner assignment
pwm: Add to device-drivers documentation
pwm: Clean up kerneldoc
pwm: Remove useless whitespace
pwm: sysfs: Remove unnecessary padding
pwm: sysfs: Properly convert from enum to string
pwm: Make use of pwm_get_xxx() helpers where appropriate
pwm: Add pwm_get_polarity() helper function
pwm: Constify PWM device where possible
pwm: Add the pwm_is_enabled() helper
The errata for HLCDC PWM of at91sam9n12 are the same as for at91sam9x5.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This commit adds support for NXP LPC18xx PWM/SCT.
NXP LPC SoCs family, which includes LPC18xx/LPC43xx, provides a State
Configurable Timer (SCT) which can be configured as a Pulse Width
Modulator. Other SoCs in that family may share the same hardware.
The PWM supports a total of 16 channels, but only 15 can be simultaneously
requested. There's only one period, global to all the channels, thus PWM
driver will refuse setting different values to it, unless there's only one
channel requested.
Signed-off-by: Ariel D'Alessandro <ariel@vanguardiasur.com.ar>
[thierry.reding@gmail.com: remove excessive padding of fields]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Previously, period_ns and duty_ns were only used to determine the
ratio of ON and OFF time, the default frequency of 200 Hz was never
changed.
The PCA9685 however is capable of changing the PWM output frequency,
which is expected when changing the period.
This patch configures the prescaler accordingly, using the formula
and notes provided in the PCA9685 datasheet.
Bounds checking for the minimum and maximum frequencies, last updated
in revision v.4 of said datasheet, is also added.
The prescaler is only touched if the period changed, because we have to
put the chip into sleep mode to unlock the prescale register.
If it is changed, the PWM output frequency changes for all outputs,
because there is one prescaler per chip. This is documented in the
PCA9685 datasheet and in the comments.
If the duty cycle is not changed at the same time as the period, then
we restart the PWM output using the duty cycle to period ratio from
before the period change.
When using LEDs for example, previously set brightness levels stay the
same when the frequency changes.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Stefan Agner