summaryrefslogtreecommitdiff
path: root/drivers/pwm/pwm-lpc18xx-sct.c
AgeCommit message (Collapse)AuthorFilesLines
2024-02-19pwm: lpc18xx-sct: Make use of devm_pwmchip_alloc() functionUwe Kleine-König1-9/+5
This prepares the pwm-lpc18xx-sct driver to further changes of the pwm core outlined in the commit introducing devm_pwmchip_alloc(). There is no intended semantical change and the driver should behave as before. Link: https://lore.kernel.org/r/d480891340e927705843cd09e5777d4daaa6c9cc.1707900770.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-02-19pwm: lpc18xx-sct: Prepare removing pwm_chip from driver dataUwe Kleine-König1-7/+10
This prepares the driver for further changes that will drop struct pwm_chip chip from struct lpc18xx_pwm_chip. Use the pwm_chip as driver data instead of the lpc18xx_pwm_chip to get access to the pwm_chip in lpc18xx_pwm_remove() without using lpc18xx_pwm->chip. Link: https://lore.kernel.org/r/b7bf8c421ff754ec3e985ec6235f4ddd6e5e27a4.1707900770.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-02-19pwm: lpc18xx-sct: Make use of pwmchip_parent() accessorUwe Kleine-König1-3/+3
struct pwm_chip::dev is about to change. To not have to touch this driver in the same commit as struct pwm_chip::dev, use the accessor function provided for exactly this purpose. Link: https://lore.kernel.org/r/e4fb330c8dbf8fecd365afe3f8b33f8c7952eb38.1707900770.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-02-19pwm: lpc18xx-sct: Drop hardly used member from driver private dataUwe Kleine-König1-4/+1
The device pointer is only used once in lpc18xx_pwm_request(). There the pwm_chip is available, too, which has a pointer to the same structure. Replace the usage accordingly and drop the then write-only member variable. Link: https://lore.kernel.org/r/427a719a24dd7ff5ebbac3e260a1773c094c7489.1707900770.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2023-12-20pwm: lpc18xx-sct: Don't modify the cached period of other PWM outputsUwe Kleine-König1-3/+1
Even though the hardware only supports a single period for all PWM outputs, modifying the other (disabled) outputs's period is strange and wrong. Only the pwm core is supposed to update these values. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: Stop referencing pwm->chipThierry Reding1-1/+1
Drivers have access to the chip via a function argument already, so there is no need to reference it via the PWM device. Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-10-13pwm: Manage owner assignment implicitly for driversUwe Kleine-König1-1/+0
Instead of requiring each driver to care for assigning the owner member of struct pwm_ops, handle that implicitly using a macro. Note that the owner member has to be moved to struct pwm_chip, as the ops structure usually lives in read-only memory and so cannot be modified. The upside is that new low level drivers cannot forget the assignment and save one line each. The pwm-crc driver didn't assign .owner, that's not a problem in practice though as the driver cannot be compiled as a module. Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # Intel LPSS Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> # pwm-{bcm,brcm}*.c Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> # sun4i Acked-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> # pwm-visconti Acked-by: Heiko Stuebner <heiko@sntech.de> # pwm-rockchip Acked-by: Michael Walle <michael@walle.cc> # pwm-sl28cpld Acked-by: Neil Armstrong <neil.armstrong@linaro.org> # pwm-meson Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230804142707.412137-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: lpc18xx-sct: Simplify using devm_clk_get_enabled()Uwe Kleine-König1-25/+8
With devm_clk_get_enabled() the call to clk_disable_unprepare() can be dropped from the error path and the remove callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-24pwm: Explicitly include correct DT includesRob Herring1-0/+1
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-03-30pwm: lpc18xx-sct: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2022-12-06pwm: lpc18xx-sct: Fix a comment to match codeUwe Kleine-König1-1/+1
lpc18xx_pwm_probe() only ensures clk_rate <= NSEC_PER_SEC, the following reasoning is right even under this slightly lesser condition. Fixes: 8933d30c5f46 ("pwm: lpc18xx: Fix period handling") Acked-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://lore.kernel.org/r/20221108153013.132514-1-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2022-07-29pwm: lpc18xx: Fix period handlingUwe Kleine-König1-16/+31
The calculation: val = (u64)NSEC_PER_SEC * LPC18XX_PWM_TIMER_MAX; do_div(val, lpc18xx_pwm->clk_rate); lpc18xx_pwm->max_period_ns = val; is bogus because with NSEC_PER_SEC = 1000000000, LPC18XX_PWM_TIMER_MAX = 0xffffffff and clk_rate < NSEC_PER_SEC this overflows the (on lpc18xx (i.e. ARM32) 32 bit wide) unsigned int .max_period_ns. This results (dependant of the actual clk rate) in an arbitrary limitation of the maximal period. E.g. for clkrate = 333333333 (Hz) we get max_period_ns = 9 instead of 12884901897. So make .max_period_ns an u64 and pass period and duty as u64 to not discard relevant digits. And also make use of mul_u64_u64_div_u64() which prevents all overflows assuming clk_rate < NSEC_PER_SEC. Fixes: 841e6f90bb78 ("pwm: NXP LPC18xx PWM/SCT driver") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2022-07-29pwm: lpc18xx: Convert to use dev_err_probe()Uwe Kleine-König1-11/+9
This has various upsides: - It emits the symbolic name of the error code - It is silent in the EPROBE_DEFER case and properly sets the defer reason - It reduces the number of code lines slightly Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2022-05-20pwm: lpc18xx: Implement .apply() callbackUwe Kleine-König1-13/+30
To eventually get rid of all legacy drivers convert this driver to the modern world implementing .apply(). This pushes a variant of pwm_apply_legacy into the driver that was slightly simplified because the .set_polarity callback was a noop. There is no change in behavior. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2022-02-02pwm: lpc18xx-sct: Simplify driver by not using pwm_[gs]et_chip_data()Uwe Kleine-König1-17/+6
The per-channel data is available directly in the driver data struct. So use it without making use of pwm_[gs]et_chip_data(). The relevant change introduced by this patch to lpc18xx_pwm_disable() at the assembler level (for an arm lpc18xx_defconfig build) is: push {r3, r4, r5, lr} mov r4, r0 mov r0, r1 mov r5, r1 bl 0 <pwm_get_chip_data> ldr r3, [r0, #0] changes to ldr r3, [r1, #8] push {r4, lr} add.w r3, r0, r3, lsl #2 ldr r3, [r3, #92] ; 0x5c So this reduces stack usage, has an improved runtime behavior because of better pipeline usage, doesn't branch to an external function and the generated code is a bit smaller occupying less memory. The codesize of lpc18xx_pwm_probe() is reduced by 32 bytes. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2022-02-02pwm: lpc18xx-sct: Reduce number of devm memory allocationsUwe Kleine-König1-7/+5
Each devm allocations has an overhead of 24 bytes to store the related struct devres_node additionally to the fragmentation of the allocator. So allocating 16 struct lpc18xx_pwm_data (which only hold a single int) adds quite some overhead. Instead put the per-channel data into the driver data struct and allocate it in one go. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2022-02-02pwm: lpc18xx-sct: Initialize driver data and hardware before pwmchip_add()Uwe Kleine-König1-11/+9
When a driver calls pwmchip_add() it has to be prepared to immediately get its callbacks called. So move allocation of driver data and hardware initialization before the call to pwmchip_add(). This fixes a potential NULL pointer exception and a race condition on register writes. Fixes: 841e6f90bb78 ("pwm: NXP LPC18xx PWM/SCT driver") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-05-25pwm: Simplify all drivers with explicit of_pwm_n_cells = 3Uwe Kleine-König1-2/+0
With the previous commit there is no need for the lowlevel driver any more to specify it it uses two or three cells. So simplify accordingly. The only non-trival change affects the pwm-rockchip driver: It used to only support three cells if the hardware supports polarity. Now the default number depends on the device tree which has to match hardware anyhow (and if it doesn't the error is just a bit delayed as a PWM handle with an inverted setting is catched when pwm_apply_state() is called). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: lpc18xx-sct: Free resources only after pwmchip_remove()Uwe Kleine-König1-1/+3
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clock. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: Always allocate PWM chip base ID dynamicallyUwe Kleine-König1-1/+0
Since commit 5e5da1e9fbee ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") all drivers use dynamic ID allocation explicitly. New drivers are supposed to do the same, so remove support for driver specified base IDs and drop all assignments in the low-level drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-02-22pwm: lpc18xx-sct: remove unneeded semicolonYang Li1-1/+1
Eliminate the following coccicheck warning: ./drivers/pwm/pwm-lpc18xx-sct.c:292:2-3: Unneeded semicolon Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: lpc18xx-sct: Convert to devm_platform_ioremap_resource()Yangtao Li1-3/+1
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 178Thomas Gleixner1-4/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 24 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Steve Winslow <swinslow@gmail.com> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190528170026.162703968@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-16pwm: lpc18xx-sct: Don't reconfigure PWM in .request and .freeUwe Kleine-König1-3/+0
Regarding the .request case: The consumer might be interested in taking over the configured state from the boot loader. So the initially configured state should be retained. For the free case the PWM consumer is responsible for disabling the PWM before calling pwm_put() and there are three subcases to consider: a) The PWM is already off. Then there is no gain in disabling the PWM once more. b) The PWM is still running and there is a good reason for that. (Not sure this is a valid case, I cannot imagine such a good reason.) Then it is counterproductive to disable the PWM. c) The PWM is still running because the consumer failed to disable the PWM. Then the consumer needs fixing and there is little incentive to paper over the problem in the backend driver. This aligns the lpc18xx-sct driver to the other PWM drivers that also don't reconfigure the hardware in .request and .free. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-09-08pwm: lpc-18xx: use pwm_set_chip_dataoliver@schinagl.nl1-4/+8
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>
2016-05-17pwm: Use pwm_get/set_xxx() helpers where appropriateBoris Brezillon1-1/+1
Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx field. Doing that will ease adaptation of the PWM framework to support atomic update. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-03-23pwm: lpc18xx-sct: Test clock rate to avoid division by 0Wolfram Sang1-0/+5
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>
2015-09-09pwm: NXP LPC18xx PWM/SCT driverAriel D'Alessandro1-0/+465
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>