summaryrefslogtreecommitdiff
path: root/drivers/pwm/pwm-berlin.c
AgeCommit message (Collapse)AuthorFilesLines
2024-02-15pwm: berlin: Make use of devm_pwmchip_alloc() functionUwe Kleine-König1-8/+5
This prepares the pwm-berlin 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/52866502c96a80d1c30be003dc1f5a89a4d230cc.1707900770.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-02-15pwm: berlin: Prepare removing pwm_chip from driver dataUwe Kleine-König1-9/+13
This prepares the driver for further changes that will drop struct pwm_chip chip from struct berlin_pwm_chip. Use the pwm_chip as driver data instead of the berlin_pwm_chip to get access to the pwm_chip in berlin_pwm_suspend() and berlin_pwm_resume() without using bpc->chip. Link: https://lore.kernel.org/r/d2a0c5b664ef1bfd4719c645c069717d63fb4e65.1707900770.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2023-12-20pwm: berlin: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsUwe Kleine-König1-5/+3
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-10-13pwm: berlin: Simplify using devm functionsUwe Kleine-König1-21/+4
With devm_clk_get_enabled() the call to clk_disable_unprepare() can be dropped from the error path and the remove callback. With devm_pwmchip_add() pwmchip_remove() can be dropped. Then the remove callback is empty and can go away, too. Link: https://lore.kernel.org/r/20230718175545.3946935-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>
2023-10-13pwm: berlin: Put per-channel config into driver dataUwe Kleine-König1-31/+6
Instead of allocating extra data in .request() provide the needed memory in struct berlin_pwm_chip. This reduces the number of allocations. A side effect is that on suspend and resume the state for all four channels is always saved and restored. This is easier (and probably quicker) than looking up the matching pwm_device and checking its PWMF_REQUESTED bit. Link: https://lore.kernel.org/r/20230705080650.2353391-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-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-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: berlin: 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>
2021-07-08pwm: berlin: Ensure configuring period and duty_cycle isn't wrongly skippedUwe Kleine-König1-6/+3
As the last call to berlin_pwm_apply() might have exited early if state->enabled was false, the values for period and duty_cycle stored in pwm->state might not have been written to hardware and it must be ensured that they are configured before enabling the PWM. Fixes: 30dffb42fcd4 ("pwm: berlin: Implement .apply() callback") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-06-30pwm: berlin: Don't check the return code of pwmchip_remove()Uwe Kleine-König1-3/+3
pwmchip_remove() always returns 0. Don't use the value to make it possible to eventually change the function to return void. This is a good thing as pwmchip_remove() is usually called from a remove function (mostly for platform devices) and their return value is ignored by the device core anyhow. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-06-30pwm: berlin: Implement .apply() callbackUwe Kleine-König1-5/+38
To eventually get rid of all legacy drivers convert this driver to the modern world implementing .apply(). This just pushes down a slightly optimized variant of how legacy drivers are handled in the core. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-06-30pwm: berlin: use consistent naming for variablesUwe Kleine-König1-58/+58
A struct berlin_pwm_chip * is now always called "bpc" (instead of "pwm" which is usually used for struct pwm_device * or "chip" which is usually used for struct pwm_chip *). The struct pwm_device * variables were named "pwm_dev" or "pwm"; they are now always called "pwm". 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-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>
2020-12-17pwm: berlin: 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-09pwm: Clear chip_data in pwm_put()Uwe Kleine-König1-1/+0
After a PWM is disposed by its user the per chip data becomes invalid. Clear the data in common code instead of the device drivers to get consistent behaviour. Before this patch only three of nine drivers cleaned up here. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2018-07-09pwm: berlin: Don't use broken prescaler valuesThomas Hebb1-20/+25
The Berlin PWM driver is currently broken on at least BG2CD. The symptoms manifest as a very non-linear and erratic mapping from the duty cycle configured in software to the duty cycle produced by hardware. The cause of the bug is software's configuration of the prescaler, and in particular its usage of the six prescaler values between the minimum value of 1 and the maximum value of 4096. As it turns out, these six values do not actually slow down the PWM clock; rather, they emulate slowing down the clock by internally multiplying the value of TCNT. This would be a fine trick, if not for the fact that the internal, scaled TCNT value has no extra bits beyond the 16 already exposed to software in the register. What this means is that, for a prescaler of 4, the software must ensure that the top two bits of TCNT are not set, because hardware will chop them off; for a prescaler of 8, the top three bits must not be set, and so forth. Software does not currently ensure this, resulting in a TCNT several orders of magnitude lower than intended any time one of those six prescalers are selected. Because hardware chops off the high bits in its internal shift, the middle six prescalers don't actually allow *anything* that the first doesn't. In fact, they are strictly worse than the first, since the internal shift of TCNT prevents software from setting the low bits, decreasing the resolution, without providing any extra high bits. By skipping the useless prescalers entirely, this patch both fixes the driver's behavior and increases its performance (since, when the 4096 prescaler is selected, it now does only a single shift rather than the seven successive divisions it did before). Tested on BG2CD. Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2017-01-04pwm: Remove .can_sleep from struct pwm_chipThierry Reding1-1/+0
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>
2016-09-06pwm: berlin: Add suspend/resume supportJisheng Zhang1-0/+84
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>
2015-10-06pwm: Add support for the Berlin PWM controllerAntoine Ténart1-0/+219
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>