A duty cycle is represented by values [0..<period>] which reflects [0%..100%].
0% of the duty cycle means always off (logical "0") on output. Allow this in
the driver.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The resolution of base_unit is derived from base_unit_bits and thus must be
equal to (2^base_unit_bits - 1). Otherwise frequency and therefore base_unit
might potentially overflow.
Prevent the above by substracting 1 in all cases where base_unit_bits or
derivative is used.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This driver adds support for PWM driver on STM32 platform.
The SoC have multiple instances of the hardware IP and each
of them could have small differences: number of channels,
complementary output, auto reload register size...
version 9:
- fix commit message header
- remove one space MODULE_ALIAS
version 8:
- fix comments done by Thierry on version 7
version 6:
- change st,breakinput parameter to make it usuable for stm32f7 too.
version 4:
- detect at probe time hardware capabilities
- fix comments done on v2 and v3
- use PWM atomic ops
version 2:
- only keep one comptatible
- use DT parameters to discover hardware block configuration
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
When first implementing support for changing the output frequency, an
optimization was added to continue the PWM after changing the prescaler
without having to reprogram the ON and OFF registers for the duty cycle,
in case the duty cycle stayed the same. This was flawed, because we
compared the absolute value of the duty cycle in nanoseconds instead of
the ratio to the period.
Fix the problem by removing the shortcut.
Fixes: 01ec847200 ("pwm-pca9685: Support changing the output frequency")
Cc: <stable@vger.kernel.org> # v4.3+
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Declare pwm_ops structures as const as they are only stored in the ops
field of a pwm_chip structure. This field is of type const struct pwm_ops
*, so pwm_ops structures having this property can be declared as const.
Done using Coccinelle:
@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct pwm_ops i@p={...};
@ok1@
identifier r1.i;
position p;
struct pxa_pwm_chip pwm;
struct bfin_pwm_chip bwm;
struct vt8500_chip vp;
struct imx_chip icp;
@@
(
pwm.chip.ops=&i@p
|
bwm.chip.ops=&i@p
|
vp.chip.ops=&i@p
|
icp.chip.ops=&i@p
)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct pwm_ops i;
File size details:
text data bss dec hex filename
1646 328 0 1974 7b6 drivers/pwm/pwm-imx.o
1742 224 0 1966 7ae drivers/pwm/pwm-imx.o
1941 296 0 2237 8bd drivers/pwm/pwm-pxa.o
2037 192 0 2229 8b5 drivers/pwm/pwm-pxa.o
1946 296 0 2242 8c2 drivers/pwm/pwm-vt8500.o
2050 192 0 2242 8c2 drivers/pwm/pwm-vt8500.o
The drivers/pwm/pwm-bfin.o file did not compile.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add dependency on COMMON_CLK and allow COMPILE_TEST for broader compile
coverage. Default to Y for IPROC SoCs. This allows the driver to simply
be enabled by selecting PWM.
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
[thierry.reding@gmail.com: reword commit message]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PCA9685 controller has full on/off bit for each PWM channel. Setting
this bit bypasses the PWM control and the line works just as it would be a
GPIO. Furthermore in Intel Galileo it is actually used as GPIO output for
discreet muxes on the board.
This patch adds GPIO output only support for the driver so that we can
control the muxes on Galileo using standard GPIO interfaces available in
the kernel. GPIO and PWM functionality is exclusive so only one can be
active at a time on a single PWM channel.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
All PWM devices have been marked as "might sleep" since v4.5, there is
no longer a need to differentiate on a per-chip basis.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This is a very tiny pull request, with just a new driver for HiSilicon
BVT SoCs and a cleanup for the Amlogic Meson driver.
There are other patches on the list, but my timing was really bad this
time and I ended up not having the time to look at them in enough detail
to be comfortable merging them.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlhSc4MZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoeVaD/sEvL+BP0IagagRpxsUKifH
9EYcr/d4986vk1tW3HdbiydLWqbW3ud2n2CK1Quo6ZMpTp14SUa0OMgeHnBuJ4wl
XNwkXldCHnFe0Hk2fMEIXYYsQAY8TslceUswTFzt7vWvRUwDmbF/oTmCT3fjMlBJ
6u9aUX6Wq+EiD7cqpl9/a33vpMhwXANJq29LSac40HoPThga71ZgIIknIHjBGBAa
Ji5cWa8DLSQFsVvWOd6cmna8z6C8lhWFghKRyRT/F0ssvQy6pHYHisRvt6ujACYQ
X8aqfXz6tu/iLUI7r9N7edQ5MDGAY+kwooM9QKERb3tba91zcwojsBhoTJavQidB
9bPp9Khq++erInrWPo78qsgvd2PGda73AZbgBjH5mcCPjtKC0yYn6wYQh5VcP1Sc
pDxdZpJUqwjFPuLHrfYnd+/ui9dJLrP8WhXt7C6WqpCyTHCVe1GJxHARrga3OM2P
sOH4Get75Iwj2CCMTLp3hnezKsKt6TYCFa1T9of0yIz7fPMRk71EDVGUOLcXP8Nu
6oJK/34vKhfjAmRMbrirJyAMU94ihFHiHWj0zeivwuCU2Oh1Dt6sfhHRvc3IZfzB
0lXR0ERF/XFc2cOckIkW4eu0UGfAr9mvd3ADYCD/eF/HMZJKxt6+5+KoMUdw4WZ7
wPjYPUaAadHoVVkVF+Qtpg==
=WHNA
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This is a very tiny pull request, with just a new driver for HiSilicon
BVT SoCs and a cleanup for the Amlogic Meson driver.
There are other patches on the list, but my timing was really bad this
time and I ended up not having the time to look at them in enough
detail to be comfortable merging them"
* tag 'pwm/for-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: Add PWM driver for HiSilicon BVT SOCs
pwm: meson: Remove unneeded platform MODULE_ALIAS
Add PWM driver for the PWM controller found on HiSilicon BVT SoCs such
as Hi3519V100, Hi3516CV300, etc. The PWM controller is primarily in
charge of controlling the P-Iris lens.
Reviewed-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
Signed-off-by: Jian Yuan <yuanjian12@hisilicon.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Make sure to drop the reference to the parent device taken by
class_find_device() after "unexporting" any children when deregistering
a PWM chip.
Fixes: 0733424c9b ("pwm: Unexport children before chip removal")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The Amlogic Meson is a DT-only platform, which means the devices are
registered via OF and not using the legacy platform devices support.
So there's no need to have a MODULE_ALIAS("platform:meson-pwm") since
the reported uevent MODALIAS to user-space will always be the OF one.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The driver uses the spin_lock but does not initialize it. Fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When building with -Wmaybe-uninitialized, we get a couple of harmless
warnings about three functions in this new driver that don't look
safe to the compiler:
drivers/pwm/pwm-meson.c: In function 'meson_pwm_get_state':
drivers/pwm/pwm-meson.c:355:26: error: 'mask' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c: In function 'meson_pwm_disable':
drivers/pwm/pwm-meson.c:263:13: error: 'enable' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c: In function 'meson_pwm_apply':
drivers/pwm/pwm-meson.c:231:13: error: 'clk_shift' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c:231:36: error: 'enable' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/pwm/pwm-meson.c:231:24: error: 'clk_enable' may be used uninitialized in this function [-Werror=maybe-uninitialized]
Specifically, if we have a device with an ID other than 0 or 1,
this would result in undefined behavior. This is currently not
possible, but the compiler cannot be expected to know this.
This patch adds a 'default' clause to let the compiler know
what to do instead, which shuts up the warning and makes the
code slightly more resiliant in case it gets extended to other
identifiers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This includes fixing some Coding Style issues and re-ordering and/or
simplifying a little code.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[thierry.reding@gmail.com: applied some bikeshedding>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Setting up the STI PWM IP as capture only, with zero PWM output devices
is a perfectly valid configuration. It is no longer okay to assume that
there must be at least 1 PWM output device. In this patch we make the
default number of PWM output devices zero and only configure channels
explicitly requested.
Reported-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Once a PWM capture has been initiated, the capture call enables a rising
edge detection interrupt, then waits. Once each of the 3 phase changes
have been recorded the thread then wakes. The remaining part of the call
carries out the relevant calculations and returns a structure filled out
with the capture data.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Here we're requesting the PWM capture IRQ and supplying the handler that
will be called in the event of an interrupt to handle it.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Each PWM capture device is allocated a structure to hold its own state.
During a capture the device may be partaking in one of 3 phases. Initial
(rising) phase change, a subsequent (falling) phase change indicating
end of the duty-cycle phase and finally a final (rising) phase change
indicating the end of the period. The timer value snapshot each event is
held in a variable of the same name, and the phase number (0, 1, 2) is
contained in the index variable. Other device specific information, such
as GPIO pin, the IRQ wait queue and locking is also contained in the
structure. This patch initialises this structure for each of the
available devices.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
ST's PWM IP is supplied by 2 different clocks. One for PWM output and
the other for capture. This patch provides clock handling for the
latter.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This is in preparation for subsequent patches that add support for PWM
capture to this driver.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
In the original code the clock rate was only obtained during
initialisation; however, the rate may change between then and
its use. This patch ensures the correct rate is acquired just
before use.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Exciting functionality is on the way to this device. But
before we can add it, we need to do some basic housekeeping
so the additions can be added cleanly.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This is to bring the terminology used in the STi PWM driver more
into line with the PWM subsystem.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The lpc-18xx driver currently manipulates the pwm_device struct directly
rather than using the pwm_set_chip_data() function. While the current
method may save a clock cycle or two, using the explicit function call
makes it more obvious that data is set to the local chip data pointer.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Reviewed-by: Ariel D'Alessandro <ariel@vanguardiasur.com.ar>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add support for the PWM controller found in the Amlogic SoCs. This
driver supports the Meson8b and GXBB SoCs.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
From pwm_samsung_calc_tin(), there is routine to find the lowest divider
possible to generate lower frequency than requested one. But it is
always possible to generate requested frequency with large enough
modulation bits except on s3c24xx, so this patch fixes to use lowest div
for the case. This patch removes following UBSAN warning:
UBSAN: Undefined behaviour in drivers/pwm/pwm-samsung.c:197:13
shift exponent 32 is too large for 32-bit type 'long unsigned int'
[...]
[<c0670248>] (ubsan_epilogue) from [<c06707b4>] (__ubsan_handle_shift_out_of_bounds+0xd8/0x120)
[<c06707b4>] (__ubsan_handle_shift_out_of_bounds) from [<c0694b28>] (pwm_samsung_config+0x508/0x6a4)
[<c0694b28>] (pwm_samsung_config) from [<c069286c>] (pwm_apply_state+0x174/0x40c)
[<c069286c>] (pwm_apply_state) from [<c0b2e070>] (pwm_fan_probe+0xc8/0x488)
[<c0b2e070>] (pwm_fan_probe) from [<c07ba8b0>] (platform_drv_probe+0x70/0x150)
[...]
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Remove all pm_runtime_get_sync() and pm_runtime_put_sync() call as well
as the dummy pm_ops from the pwm-tipwmss driver. No registers are being
modified. The runtime PM still needs to be enabled, so that the runtime
PM framework can take care of enabling/disabling the PWMSS clock when
submodules of PWMSS (ECAP or EHRPWM) call runtime PM APIs. With this
change PWMSS clock goes to idle when none of the submodules are in use.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
While the particular usage in question is likely safe (struct
cros_ec_command is 32-bit aligned, followed by <= 32-bit fields), it's
been suggested this is not a great pattern to follow for the general
case -- for example, if we follow a 'struct cros_ec_command' (which is
32-bit- but not 64-bit-aligned) with a struct that starts with a 64-bit
type (e.g., u64), the compiler may add padding.
Let's add __packed, to inform the compiler of our true intention -- to
have no padding between these struct elements -- and to future proof for
any refactorings that might occur.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use the mtk_pwm_data struction to define different registers
and add MT2701 specific register operations, such as MT2701
doesn't have commit register, needs to disable double buffer
before writing register, and needs to select manual mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Weiqing Kong <weiqing.kong@mediatek.com>
[thierry.reding@gmail.com: use of_device_get_match_data()]
[thierry.reding@gmail.com: parameterize more consistently]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch adds suspend-to-RAM support to the Berlin PWM driver.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.
Signed-off-by: David Hsu <davidhsu@google.com>
Fixes: 76abbdde2d ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The current TWL6030 code for the TWL PWM driver does not reliably disable the
PWM output, as tested with LEDs. The previous commit to that driver introduced
that regression.
However, it does make sense to disable the PWM clock after resetting the PWM,
but for some obscure reason, doing it all at once simply doesn't work.
The TWL6030 datasheet mentions that PWMs have to be disabled in two distinct
steps. However, clearing the clock enable bit in a second step (after issuing a
reset first) does not work.
The only approach that works is the one that was in place before the previous
commit to the driver. It consists in enabling the PWM clock after issuing a
reset. This is what TI kernel trees and production code seem to be using.
However, adding an extra step to disable the PWM clock seems to work reliably,
despite looking quite odd.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This set of changes improve some aspects of the atomic API as well as
make use of this new API in the regulator framework to allow properly
dealing with critical regulators controlled by a PWM.
Aside from that there's a bunch of updates and cleanups for existing
drivers, as well as the addition of new drivers for the Broadcom iProc,
STMPE and ChromeOS EC controllers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQI2BAABCAAgBQJXpLFKGRx0aGllcnJ5LnJlZGluZ0BnbWFpbC5jb20ACgkQ3SOs
138+s6E2Nw/9FggtgYlVQRS5lzwTKxQI/5HMlOfdyH84S76fUS8uAxvEsZvyHXZ7
NiwCJMkmMqPHMlrfuXacs4nueKz3jvy8csaffH5T2yHf0ZPGmkxBsdX97rvQp3z/
WTUXX8vo8fiEPQSXQOUzIYk10s7CBO2094uL8FBqfYeSySY3Ti35SpmZSQKVd1LS
A1rR/qRgNbIlhI7+L5CotdrNMkHXqHZIHDyXO1dWBDVL+3MU3IPpB//J/WjU/OMs
5MHEtTr7943s8LQYhM1p5PFDn8ehe31L1quSswmMTLuepPrTUjD31476VYW8p8gg
lzOv5JF5b8Rkw0B+4vDC0z/OPZA47tg8DfiS9Sa1SrCGxslOH7pvI7m9dV89FOc2
/hA1n048jBhIrHPylXZ+hUPKNM0WTwFrHVxROgtEb6/wtYskgOFGQrYKpD4FtH+j
zqXxvCRMX4ZLLXy2QO4GAW3dv51pLjiM2yxVWtM1lWFWiKKvRoqHiFcnmCJJwQ4T
NXUPnyt+G/GCtpVHlMtHW9YszJ650ECt+H8I1EhuGLkpOXncCPdmw34oR1wSmMi3
+1yjCvZV8bNJLt2GQDpoFEUc1dqY6g/SLqm9sz+W69QYA0oDt9JpFK+RFw118282
EX24GT9+PYe0kMt1WWopjHeFZ+6HhsG/ODwOUOaG/8kp6qZLB4EKP9k=
=TdEI
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.8-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 improve some aspects of the atomic API as well as
make use of this new API in the regulator framework to allow properly
dealing with critical regulators controlled by a PWM.
Aside from that there's a bunch of updates and cleanups for existing
drivers, as well as the addition of new drivers for the Broadcom
iProc, STMPE and ChromeOS EC controllers"
* tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits)
regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range
regulator: pwm: Support extra continuous mode cases
pwm: Add ChromeOS EC PWM driver
dt-bindings: pwm: Add binding for ChromeOS EC PWM
mfd: cros_ec: Add EC_PWM function definitions
mfd: cros_ec: Add cros_ec_cmd_xfer_status() helper
pwm: atmel: Use of_device_get_match_data()
pwm: atmel: Fix checkpatch warnings
pwm: atmel: Fix disabling of PWM channels
dt-bindings: pwm: Add R-Car H3 device tree bindings
pwm: rcar: Use ARCH_RENESAS
pwm: tegra: Add support for Tegra186
dt-bindings: pwm: tegra: Add compatible string for Tegra186
pwm: tegra: Avoid overflow when calculating duty cycle
pwm: tegra: Allow 100 % duty cycle
pwm: tegra: Add support for reset control
pwm: tegra: Rename mmio_base to regs
pwm: tegra: Remove useless padding
pwm: tegra: Drop NUM_PWM macro
pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value
...
Driver updates for ARM SoCs.
A slew of changes this release cycle. The reset driver tree, that we merge
through arm-soc for historical reasons, is also sizable this time around.
Among the changes:
- clps711x: Treewide changes to compatible strings, merged here for simplicity.
- Qualcomm: SCM firmware driver cleanups, move to platform driver
- ux500: Major cleanups, removal of old mach-specific infrastructure.
- Atmel external bus memory driver
- Move of brcmstb platform to the rest of bcm
- PMC driver updates for tegra, various fixes and improvements
- Samsung platform driver updates to support 64-bit Exynos platforms
- Reset controller cleanups moving to devm_reset_controller_register() APIs
- Reset controller driver for Amlogic Meson
- Reset controller driver for Hisilicon hi6220
- ARM SCPI power domain support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXnm1XAAoJEIwa5zzehBx35lcP/ApuQarIXeZCQZtjlUBV9McW
o3o7FhKFHePmEPeoYCvVeK5D8NykTkQv3WpnCknoxPJzxGJF7jbPWQJcVnXfKOXD
kTcyIK15WL2HHtSE3lYyLfyUPz8AbJyRt0l0cxgcg6jvo+uzlWooNz1y78rLIYzg
UwRssj7OiHv4dsyYRHZIsjnB8gMWw8rYMk154gP2xy6MnNXXzzOVVnOiVqxSZBm+
EgIIcROMOqkkHuFlClMYKluIgrmgz1Ypjf+FuAg7dqXZd+TGRrmGXeI7SkGThfLu
nyvY3N18NViNu7xOUkI9zg7+ifyYM8Si9ylalSICSJdIAxZfiwFqFaLJvVWKU1rY
rBOBjKckQI0/X9WYusFNFHcijhIFV8/FgGAnVRRMPdvlCss7Zp03C9mR4AEhmKMX
rLG49x81hU1C+LftC59ml3iB8dhZrrRkbxNHjLFHVGWNrKMrmJKa8JhXGRAoNM+u
LRauiuJZatqvLfISNvpfcoW2EashVoU3f+uC8ymT3QCyME3wZm0t7T4tllxhMfBl
sOgJqNkTKDmPLofwm/dASiLML7ZF1WePScrFyOACnj9K4mUD+OaCnowtWoQPu0eI
aNmT84oosJ2S9F/iUDPtFHXdzQ+1QPPfSiQ9FXMoauciVq/2F+pqq68yYgqoxFOG
vmkmG2YM4Wyq43u0BONR
=O8+y
-----END PGP SIGNATURE-----
Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver updates from Olof Johansson:
"Driver updates for ARM SoCs.
A slew of changes this release cycle. The reset driver tree, that we
merge through arm-soc for historical reasons, is also sizable this
time around.
Among the changes:
- clps711x: Treewide changes to compatible strings, merged here for simplicity.
- Qualcomm: SCM firmware driver cleanups, move to platform driver
- ux500: Major cleanups, removal of old mach-specific infrastructure.
- Atmel external bus memory driver
- Move of brcmstb platform to the rest of bcm
- PMC driver updates for tegra, various fixes and improvements
- Samsung platform driver updates to support 64-bit Exynos platforms
- Reset controller cleanups moving to devm_reset_controller_register() APIs
- Reset controller driver for Amlogic Meson
- Reset controller driver for Hisilicon hi6220
- ARM SCPI power domain support"
* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (100 commits)
ARM: ux500: consolidate base platform files
ARM: ux500: move soc_id driver to drivers/soc
ARM: ux500: call ux500_setup_id later
ARM: ux500: consolidate soc_device code in id.c
ARM: ux500: remove cpu_is_u* helpers
ARM: ux500: use CLK_OF_DECLARE()
ARM: ux500: move l2x0 init to .init_irq
mfd: db8500 stop passing around platform data
ASoC: ab8500-codec: remove platform data based probe
ARM: ux500: move ab8500_regulator_plat_data into driver
ARM: ux500: remove unused regulator data
soc: raspberrypi-power: add CONFIG_OF dependency
firmware: scpi: add CONFIG_OF dependency
video: clps711x-fb: Changing the compatibility string to match with the smallest supported chip
input: clps711x-keypad: Changing the compatibility string to match with the smallest supported chip
pwm: clps711x: Changing the compatibility string to match with the smallest supported chip
serial: clps711x: Changing the compatibility string to match with the smallest supported chip
irqchip: clps711x: Changing the compatibility string to match with the smallest supported chip
clocksource: clps711x: Changing the compatibility string to match with the smallest supported chip
clk: clps711x: Changing the compatibility string to match with the smallest supported chip
...
Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control
one or more PWMs attached to the Embedded Controller. Because the EC
allows us to modify the duty cycle (as a percentage, where U16_MAX is
100%) but not the period, we assign the period a fixed value of
EC_PWM_MAX_DUTY and reject all attempts to change it.
This driver supports only device tree at the moment, because that
provides a very flexible way of describing the relationship between PWMs
and their consumer devices (e.g., backlight). On a non-DT system, we'll
probably want to use the non-GENERIC addressing (i.e., we'll need to
make special device instances that will use EC_PWM_TYPE_KB_LIGHT or
EC_PWM_TYPE_DISPLAY_LIGHT), as well as the relatively inflexible
pwm_lookup infrastructure for matching devices. Defer that work for now.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When disabling a PWM channel, the PWM clock was being stopped
immediately after writing to PWM_DIS. As a result, the disabling
of the PWM channel did not complete properly, and the PWM output
might be left at the wrong level.
Fix this by waiting for the channel to be effectively disabled
(by checking the PWM_SR register) before disabling the clock.
Signed-off-by: Guillermo Rodriguez <guille.rodriguez@gmail.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Tegra186 has multiple PWM controllers with only one output instead of
one controller with four outputs in earlier SoC generations.
Add support for Tegra186 and detect the number of PWM outputs using
device tree match data.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
duty_ns * (1 << PWM_DUTY_WIDTH) could overflow in integer calculation
when the PWM rate is low. Hence do all calculation on unsigned long long
to avoid overflow.
Signed-off-by: Hyong Bin Kim <hyongbink@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
To get 100 % duty cycle (always high), pulse width needs to be set to
256.
Signed-off-by: Victor(Weiguo) Pan <wpan@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add reset control of the PWM controller to reset it before
accessing the PWM register.
Signed-off-by: Rohith Seelaboyina <rseelaboyina@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The former is much longer to type and is ambiguous because the value
stored in the field is not the (physical) base address of the memory-
mapped I/O registers, but the virtual address of those registers as
mapped through the MMU.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This macro is used to initialize the ->npwm field of the PWM chip. Use a
literal instead and make all other places rely on ->npwm.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM_PIN_LEVEL bit is leave unset by the kernel PWM driver.
Prior to commit 08ee77b5a5,
the PWM_PIN_LEVEL bit was always clear when the PWM was disable
and a 0 logic level was apply to the output.
According to the LPC32x0 User Manual [1],
the default value for bit 30 (PWM_PIN_LEVEL) is 0.
This change initialize the pin level to 0 (default value) and
update the register value accordingly.
[1] http://www.nxp.com/documents/user_manual/UM10326.pdf
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This adds a driver for the PWM block found in chips of the STMPE 24xx
series of multi-purpose I2C expanders. (I think STMPE means ST
Microelectronics Multi-Purpose Expander.) This PWM was designed in
accordance with Nokia specifications and is kind of weird and usually
just switched between max and zero duty cycle. However it is indeed a
PWM so it needs to live in the PWM subsystem.
This PWM is mostly used for white LED backlight.
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement the ->apply() function to add support for atomic update.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The current logic will disable the PWM clk even if the PWM was left
enabled by the bootloader (because it's controlling a critical device
like a regulator for example).
Keep the PWM clk enabled if the PWM is enabled to avoid any glitches.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement the ->get_state() function to expose initial state.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The current implementation always round down the duty and period values,
while it would be better to round them to the closest integer.
These changes are needed in preparation of atomic update support to
prevent a period/duty cycle drift when executing several times the
'pwm_get_state() / modify / pwm_apply_state()' sequence.
Say you have an expected period of 3.333 us and a clk rate of
112.666667 MHz -- the clock frequency doesn't divide evenly, so the
period (stashed in nanoseconds) shrinks when we convert to the register
value and back, as follows:
pwm_apply_state(): register = period * 112666667 / 1000000000;
pwm_get_state(): period = register * 1000000000 / 112666667;
or in other words:
period = period * 112666667 / 1000000000 * 1000000000 / 112666667;
which yields a sequence like:
3333 -> 3328
3328 -> 3319
3319 -> 3310
3310 -> 3301
3301 -> 3292
3292 -> ... (etc) ...
With this patch, we'd see instead:
period = div_round_closest(period * 112666667, 1000000000) *
1000000000 / 112666667;
which yields a stable sequence:
3333 -> 3337
3337 -> 3337
3337 -> ... (etc) ...
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add support for the PWM controller present in Broadcom's iProc family of
SoCs. It has been tested on the Northstar+ bcm958625HR board.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
[thierry.reding@gmail.com: bunch of coding style fixes, cleanups]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is no need to check each time if the clk_rate defined or not when we call
pwm_lpss_config(). Move the check to ->probe() instead.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Intel Edison has 4 PWM channels on the die with the same IP as in
Broxton. Enable it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
If duty_ns is large enough multiplying it by 255 overflows and results
wrong duty cycle value being programmed. For example with 10ms duty when
period is 20ms (50%) we get
255 * 10000000 / 20000000 = -87
because 255 * 10000000 overlows int. Whereas correct value should be
255 * 10000000 / 20000000 = 127
Fix this by using unsigned long long as type for on_time_div and changing
integer literals to use proper type annotation.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The base_unit calculation applies an offset of 0x2 which adds
significant error for lower frequencies and doesn't appear to be
warranted - rounding the division result gives a correct value.
Also, the upper limit check for base_unit is off-by-one; the upper
nibble of base_unit is invalid if >=128 according to the Table 88
in the Z8000 Processor Series Datasheet Volume 1 (Rev. 2).
Verified on UP Board (Cherry Trail) and Minnowboard Max (Bay Trail).
Signed-off-by: Dan O'Donovan <dan@emutex.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWMSS local clock gating registers have no real purpose on OMAP ARM
devices. These registers were left over registers from DSP IP where the
PRCM doesn't exist. There is a silicon bug where gating and ungating clocks
don't function properly. TRMs will be update to indicate that these
registers shouldn't be touched.
Therefore, all code that accesses the PWMSS_CLKCONFIG or PWMSS_CLKSTATUS
will be removed by this patch with zero loss of functionality by the ECAP
and EPWM drivers.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When using the old eCAP and ePWM bindings for AM335x and AM437x the clock
can be retrieved from the PWMSS parent. Newer bindings will insure that
this clock is provided via device tree.
Therefore, update this driver to support the newer and older bindings. In
the case of the older binding being used give a warning.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
[thierry.reding@gmail.com: rewrite slightly for readability]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
booting.
This driver has been unusable with multiarch because of the hardware
timer access. With the recent PWM changes, we can finally fix the
driver for multiarch and device tree support. And naturally there
is no rush for these for the -rc cycle, these can wait for the
merge window.
The PWM changes have been acked by Thierry. For the media changes
I did not get an ack from Mauro but he was Cc'd in the discussion
and these changes do not conflict with other media changes.
After this series we can drop the remaining omap3 legacy booting
board files finally.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXe1v2AAoJEBvUPslcq6VzLvsQALIWLcgyqUKNgPV6EOxAsxeO
azvjPPZgI0oTl5+voS6dzSg5mXhQt3rVlaXxJXxCdxYgOf67zYjugrJqf5Sm4stF
BEtzPGLRTwR8miJbHNB8eGfcBGU3q+hx19dT+U7EAsPQqItlFfxVTh5ZzS0TOZc2
9bQGO6MYIWNEk6V0TRxNUfRt+4fQN17zRdIpKL8NCJOsoBn9ZpztB76GeHUnd34t
pYeaMFPdVUqBCQOmE9EA3dmOB7q37JgtsM312zpn72OgzpTTttza1Vo6HAh7dTWM
Pmphin+H54zmsrB3wvI0h4G2WmuZjNNEHBTbLV4fgTjDer4o84RHJUGOgQmmPnni
q9nyuV0y1gudk8ihlq7hxnickPS+NCSk8aQgAfspY+8rhxYWstJdJ66gUl+bUPlQ
qaOvNACaEMVuRdeqnuTLm/mhQdVLz5VuUzSZkAWosVVuCVY9ONLt/t/Mxbylqf9P
CfKiDBEUp+DQ8Ly4L0odD7n4fOWOq6XOx3RR6C4IJqkLyb6VL5O8POKNsHuMvb1q
ptWyN1aWHrdYvd4PD0QB6hakY+C2P9BSAMb0t9ZscAX1nGvkGY27TRzHD8rkhHZD
WKy5J4gzr8VDLnQom9MwoXcoqrWKTGY5QCqw1hdUrqNlVnRJTu2jYc5NrYxOK0mD
TUC5drgK5e2mjmgUv95q
=frvc
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.8/ir-rx51-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers
Merge "omap ir-rx51 driver fixes for multiarch for v4.8 merge window"
from Tony Lindgren:
Fix a long time regression for ir-rx51 driver for n900 device tree
booting.
This driver has been unusable with multiarch because of the hardware
timer access. With the recent PWM changes, we can finally fix the
driver for multiarch and device tree support. And naturally there
is no rush for these for the -rc cycle, these can wait for the
merge window.
The PWM changes have been acked by Thierry. For the media changes
I did not get an ack from Mauro but he was Cc'd in the discussion
and these changes do not conflict with other media changes.
After this series we can drop the remaining omap3 legacy booting
board files finally.
* tag 'omap-for-v4.8/ir-rx51-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ir-rx51: use hrtimer instead of dmtimer
ir-rx51: add DT support to driver
ir-rx51: use PWM framework instead of OMAP dmtimer
pwm: omap-dmtimer: Allow for setting dmtimer clock source
ir-rx51: Fix build after multiarch changes broke it
This patch changes the compatibility string to match with the smallest
supported chip (EP7209). Since the DT-support for this CPU is not yet
announced, this change is safe.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
OMAP GP timers can have different input clocks that allow different PWM
frequencies. However, there is no other way of setting the clock source but
through clocks or clock-names properties of the timer itself. This limits
PWM functionality to only the frequencies allowed by the particular clock
source. Allowing setting the clock source by PWM rather than by timer
allows different PWMs to have different ranges by not hard-wiring the clock
source to the timer.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
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>
Allow a user to read PWM capture results from sysfs. To start a capture
and read the result, simply read the file:
$ cat $PWMCHIP/capture
The output format is "<period> <duty cycle>".
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Supply a PWM capture callback op in order to pass back information
obtained by running analysis on a PWM signal. This would normally (at
least during testing) be called from the sysfs routines with a view to
printing out PWM capture data which has been encoded into a string.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[thierry.reding@gmail.com: make capture data unsigned int for symmetry]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
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>
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
...
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Andy Shevchenko