aboutsummaryrefslogtreecommitdiff
path: root/drivers/pwm/pwm-sifive.c
AgeCommit message (Collapse)AuthorFilesLines
2023-03-30pwm: sifive: 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 <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2023-01-30pwm: sifive: Always let the first pwm_apply_state succeedEmil Renner Berthing1-1/+7
Commit 2cfe9bbec56ea579135cdd92409fff371841904f added support for the RGB and green PWM controlled LEDs on the HiFive Unmatched board managed by the leds-pwm-multicolor and leds-pwm drivers respectively. All three colours of the RGB LED and the green LED run from different lines of the same PWM, but with the same period so this works fine when the LED drivers are loaded one after the other. Unfortunately it does expose a race in the PWM driver when both LED drivers are loaded at roughly the same time. Here is an example: | Thread A | Thread B | | led_pwm_mc_probe | led_pwm_probe | | devm_fwnode_pwm_get | | | pwm_sifive_request | | | ddata->user_count++ | | | | devm_fwnode_pwm_get | | | pwm_sifive_request | | | ddata->user_count++ | | ... | ... | | pwm_state_apply | pwm_state_apply | | pwm_sifive_apply | pwm_sifive_apply | Now both calls to pwm_sifive_apply will see that ddata->approx_period, initially 0, is different from the requested period and the clock needs to be updated. But since ddata->user_count >= 2 both calls will fail with -EBUSY, which will then cause both LED drivers to fail to probe. Fix it by letting the first call to pwm_sifive_apply update the clock even when ddata->user_count != 1. Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM") Signed-off-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-12-06pwm: Make .get_state() callback return an error codeUwe Kleine-König1-2/+4
.get_state() might fail in some cases. To make it possible that a driver signals such a failure change the prototype of .get_state() to return an error code. This patch was created using coccinelle and the following semantic patch: @p1@ identifier getstatefunc; identifier driver; @@ struct pwm_ops driver = { ..., .get_state = getstatefunc ,... }; @p2@ identifier p1.getstatefunc; identifier chip, pwm, state; @@ -void +int getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state) { ... - return; + return 0; ... } plus the actual change of the prototype in include/linux/pwm.h (plus some manual fixing of indentions and empty lines). So for now all drivers return success unconditionally. They are adapted in the following patches to make the changes easier reviewable. Reviewed-by: Heiko Stuebner <[email protected]> Reviewed-by: Baolin Wang <[email protected]> Reviewed-by: Tzung-Bi Shih <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Nobuhiro Iwamatsu <[email protected]> Reviewed-by: Andre Przywara <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Acked-by: Douglas Anderson <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Acked-by: Pavel Machek <[email protected]> Acked-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-12-06pwm: sifive: Call pwm_sifive_update_clock() while mutex is heldUwe Kleine-König1-1/+4
As was documented in commit 0f02f491b786 ("pwm: sifive: Reduce time the controller lock is held") a caller of pwm_sifive_update_clock() must hold the mutex. So fix pwm_sifive_clock_notifier() to grab the lock. While this necessity was only documented later, the race exists since the driver was introduced. Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM") Reported-by: Emil Renner Berthing <[email protected]> Reviewed-by: Emil Renner Berthing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Shut down hardware only after pwmchip_remove() completedUwe Kleine-König1-2/+3
The PWMs are expected to be functional until pwmchip_remove() is called. So disable the clks only afterwards. Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM") Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Ensure the clk is enabled exactly once per running PWMUwe Kleine-König1-9/+37
.apply() assumes the clk to be for a given PWM iff the PWM is enabled. So make sure this is the case when .probe() completes. And in .remove() disable the according number of times. This fixes a clk enable/disable imbalance, if some PWMs are already running at probe time. Fixes: 9e37a53eb051 (pwm: sifive: Add a driver for SiFive SoC PWM) Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Simplify clk handlingUwe Kleine-König1-13/+13
The clk is necessary for both register access and (enabled) operation of the PWM. Instead of clk_enable() update_hw() if pwm_got_enabled(): clk_enable() elif pwm_got_disabled(): clk_disable() clk_disable() which is some cases only calls clk_enable() to immediately afterwards call clk_disable again, do: if (!prev_state.enabled) clk_enable() # clk enabled exactly once update_hw() if (!next_state.enabled) clk_disable() which is much easier. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Enable clk only after period check in .apply()Uwe Kleine-König1-10/+8
For the period check and the initial calculations of register values there is no hardware access needed. So delay enabling the clk a bit to simplify the code flow a bit. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Reduce time the controller lock is heldUwe Kleine-König1-3/+5
The lock is only to serialize access and update to user_count and approx_period between different PWMs served by the same pwm_chip. So the lock needs only to be taken during the check if the (chip global) period can and/or needs to be changed. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Fold pwm_sifive_enable() into its only callerUwe Kleine-König1-20/+8
There is only a single caller of pwm_sifive_enable() which only enables or disables the clk. Put this implementation directly into pwm_sifive_apply() which allows further simplification in the next change. There is no change in behaviour. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-07-29pwm: sifive: Simplify offset calculation for PWMCMP registersUwe Kleine-König1-7/+3
Instead of explicitly using PWM_SIFIVE_PWMCMP0 + pwm->hwpwm * PWM_SIFIVE_SIZE_PWMCMP for each access to one of the PWMCMP registers, introduce a macro that takes the hwpwm id as parameter. For the register definition using a plain 4 instead of the cpp constant PWM_SIFIVE_SIZE_PWMCMP is easier to read, so define the offset macro without the constant. The latter can then be dropped as there are no users left. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2022-05-20pwm: sifive: Simplify if-if to if-elseWan Jiabing1-3/+2
Use if and else instead of if(A) and if (!A). Signed-off-by: Wan Jiabing <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2021-09-02pwm: sifive: Don't check the return code of pwmchip_remove()Uwe Kleine-König1-3/+3
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of pwm_sifive_remove(). Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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 <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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 <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2020-12-17pwm: sifive: Convert to devm_platform_ioremap_resource()Yangtao Li1-3/+1
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by: Yangtao Li <[email protected]> Reviewed-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2020-09-24pwm: sifive: Simplify with dev_err_probe()Krzysztof Kozlowski1-5/+3
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Palmer Dabbelt <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2020-06-17pwm: sifive: Use 64-bit division macroGuru Das Srinagesh1-1/+1
Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to handle a 64-bit divisor. Signed-off-by: Guru Das Srinagesh <[email protected]> Acked-by: Palmer Dabbelt <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2019-09-21pwm: Ensure pwm_apply_state() doesn't modify the state argumentUwe Kleine-König1-1/+1
It is surprising for a PWM consumer when the variable holding the requested state is modified by pwm_apply_state(). Consider for example a driver doing: #define PERIOD 5000000 #define DUTY_LITTLE 10 ... struct pwm_state state = { .period = PERIOD, .duty_cycle = DUTY_LITTLE, .polarity = PWM_POLARITY_NORMAL, .enabled = true, }; pwm_apply_state(mypwm, &state); ... state.duty_cycle = PERIOD / 2; pwm_apply_state(mypwm, &state); For sure the second call to pwm_apply_state() should still have state.period = PERIOD and not something the hardware driver chose for a reason that doesn't necessarily apply to the second call. So declare the state argument as a pointer to a const type and adapt all drivers' .apply callbacks. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2019-09-21pwm: sifive: Remove redundant error messageDing Xiang1-3/+1
devm_ioremap_resource() already outputs an error message, so remove the extra error message on failure. Signed-off-by: Ding Xiang <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2019-06-25pwm: sifive: Add a driver for SiFive SoC PWMYash Shah1-0/+339
Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC. Signed-off-by: Wesley W. Terpstra <[email protected]> [Atish: Various fixes and code cleanup] Signed-off-by: Atish Patra <[email protected]> Signed-off-by: Yash Shah <[email protected]> Reviewed-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.