summaryrefslogtreecommitdiff
path: root/drivers/pwm
AgeCommit message (Collapse)AuthorFilesLines
2024-07-11pwm: axi-pwmgen: add .max_register to regmapTrevor Gamblin1-0/+1
This was missed in the basic driver and is useful for debug, so add it. Example regmap output before the patch: |root@zed-tg:~# cat /sys/kernel/debug/regmap/44a60000.pwm/registers |0: 00020100 And with it: |root@zed-tg:~# cat /sys/kernel/debug/regmap/44a60000.pwm/registers |00: 00020100 |04: 00000000 |08: 00000000 |0c: 601a3471 |10: 00000000 |14: 00000002 |18: 00000001 |1c: 00000000 |... Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com> Link: https://lore.kernel.org/r/20240711125743.3956935-1-tgamblin@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: atmel-tcb: Make private data variable naming consistentUwe Kleine-König1-45/+45
Currently the variables of type struct atmel_tcb_pwm_device are named "tcbpwm", and variables of type atmel_tcb_pwm_chip are either named "tcbpwm" (too!) or "tcbpwmc". Rename the chips with device name to "tcbpwmc" to get a consistent naming. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20240709092221.47025-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: atmel-tcb: Simplify checking the companion outputUwe Kleine-König1-8/+3
The two outputs provided by the supported hardware share some settings, so access to the other PWM is required when one of them is configured. Instead of an explicit if to deterimine the other PWM just use hwpwm ^ 1. Further atcbpwm is never NULL, so drop the corresponding check. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20240709101806.52394-4-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: Allow pwm state transitions from an invalid stateUwe Kleine-König1-2/+37
While driving a PWM via the sysfs API it's hard to determine the right order of writes to the pseudo files "period" and "duty_cycle": If you want to go from duty_cycle/period = 50/100 to 150/300 you have to write period first (because 150/100 is invalid). If however you start at 400/500 the duty_cycle must be configured first. The rule that works is: If you increase period write period first, otherwise write duty_cycle first. A complication however is that it's usually sensible to configure the polarity before both period and duty_cycle. This can only be done if the current state's duty_cycle and period configuration isn't bogus though. It is still worse (but I think only theoretic) if you have a PWM that only supports inverted polarity and you start with period = 0 and polarity = normal. Then you can change neither period (because polarity = normal is refused) nor polarity (because there is still period = 0). To simplify the corner cases for userspace, let invalid target states pass if the current state is invalid already. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240628103519.105020-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: xilinx: Simplify using devm_ functionsUwe Kleine-König1-21/+6
There are devm variants for clk_prepare_enable() and pwmchip_add(); and clk_prepare_enable() can be done together with devm_clk_get(). This allows to simplify the error paths in .probe() and drop .remove() completely. With the remove callback gone, the last user of platform_get_drvdata() is gone and so the call to platform_set_drvdata() can be dropped, too. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/20240628063524.92907-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: Use guards for pwm_lookup_lock instead of explicity mutex_lock + ↵Uwe Kleine-König1-29/+22
mutex_unlock With the compiler caring for unlocking the mutex several functions can be simplified. Benefit from that. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/28807cb5d9dbce66860f74829c0f57cd9c01373e.1719520143.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: Use guards for export->lock instead of explicity mutex_lock + mutex_unlockUwe Kleine-König1-11/+8
With the compiler caring for unlocking the mutex several functions can be simplified. Benefit from that. There is just one caller left for mutex_lock(&export->lock). The code flow is too complicated there to convert it to the compiler assisted variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/210010f2e579a92476462726e18e0135f6854909.1719520143.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: Use guards for pwm_lock instead of explicity mutex_lock + mutex_unlockUwe Kleine-König1-37/+15
With the compiler caring for unlocking the mutex several functions can be simplified. Benefit from that. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/2102fe8189bdf1f02ff3785b551a69be27a65af4.1719520143.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: Register debugfs operations after the pwm classUwe Kleine-König1-1/+9
While the debugfs operations don't technically depend on an initialized class, they loop over the idr that only can get entries when the class is properly initialized. This also fixes the ugly (but harmless) corner case that the debugfs file stays around after the pwm class failed to initialize. While at it, add an appropriate error message when class initialization fails. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240626222529.2901200-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: imx-tpm: Enable pinctrl setting for sleep stateShenwei Wang1-2/+14
Apply the pinctrl setting of sleep state when system enters suspend state. Restore to the default pinctrl setting when system resumes. Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com> Link: https://lore.kernel.org/r/20240702164514.11007-1-shenwei.wang@nxp.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: lpss: drop redundant runtime PM handlesRaag Jadav1-22/+0
We no longer need empty runtime PM handles for PCI devices after commits [1] and [2]. Drop them and let PCI core take care of power state transitions. [1] c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions") [2] fa885b06ec7e ("PCI/PM: Allow runtime PM with no PM callbacks at all") Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20240605131533.20037-3-raag.jadav@intel.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: lpss: use devm_pm_runtime_enable() helperRaag Jadav1-9/+1
Use devm_pm_runtime_enable() helper to enable runtime PM and drop redundant platform ->remove() callback. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20240605131533.20037-2-raag.jadav@intel.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm-stm32: Make use of parametrised register definitionsUwe Kleine-König1-11/+11
There is no semantic change, but it is a nicer on the eyes of a reader, because TIM_CCR1 + 4 * ch encodes internal register knowledge, while TIM_CCRx(ch + 1) keeps that information completely in the header defining the registers. While I expected this to not result in any changes in the binary, gcc 13 (as provided by Debian in the gcc-13-arm-linux-gnueabihf 13.2.0-12cross1 package) compiles the new version with an allmodconfig to more compact code: $ source/scripts/bloat-o-meter drivers/pwm/pwm-stm32.o-pre drivers/pwm/pwm-stm32.o add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-488 (-488) Function old new delta stm32_pwm_get_state 968 936 -32 stm32_pwm_apply_locked 1920 1464 -456 Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/d7ef7a6158df4ba6687233b0e00d37796b069fb3.1718791090.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: meson: Add support for Amlogic S4 PWMJunyi Zhao1-0/+39
Add support for Amlogic S4 PWM. Signed-off-by: Junyi Zhao <junyi.zhao@amlogic.com> Signed-off-by: Kelvin Zhang <kelvin.zhang@amlogic.com> Reviewed-by: George Stark <gnstark@salutedevices.com> Link: https://lore.kernel.org/r/20240613-s4-pwm-v8-1-b5bd0a768282@amlogic.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: Add GPIO PWM driverVincent Whitchurch3-0/+253
Add a software PWM which toggles a GPIO from a high-resolution timer. This will naturally not be as accurate or as efficient as a hardware PWM, but it is useful in some cases. I have for example used it for evaluating LED brightness handling (via leds-pwm) on a board where the LED was just hooked up to a GPIO, and for a simple verification of the timer frequency on another platform. Since high-resolution timers are used, sleeping GPIO chips are not supported and are rejected in the probe function. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Co-developed-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Co-developed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20240604-pwm-gpio-v7-2-6b67cf60db92@linaro.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: Make pwm_request_from_chip() private to the coreUwe Kleine-König1-5/+3
The last user of this function outside of core.c is gone, so it can be made static. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20240607084416.897777-8-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: cros-ec: Simplify device tree xlationUwe Kleine-König1-20/+12
The cros-ec device tree binding only uses #pwm-cells = <1>, and so there is no period provided in the device tree. Up to now this was handled by hardcoding the period to the only supported value in the custom xlate callback. Apart from that, the default xlate callback (i.e. of_pwm_xlate_with_flags()) handles this just fine (and better, e.g. by checking args->args_count >= 1 before accessing args->args[0]). To simplify make use of of_pwm_xlate_with_flags(), drop the custom callback and provide the default period in .probe() already. Apart from simplifying the driver this also drops the last non-core user of pwm_request_from_chip() and so makes further simplifications possible. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20240607084416.897777-7-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: cros-ec: Don't care about consumers in .get_state()Uwe Kleine-König1-33/+1
The get_state() callback is never called (in a visible way) after there is a consumer for a pwm device. The core handles loosing the information about duty_cycle just fine. Simplify the driver accordingly. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20240607084416.897777-6-u.kleine-koenig@baylibre.com [Drop kdoc comment for channel to make W=1 builds happy] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: Make use of a symbol namespace for the coreUwe Kleine-König1-0/+2
Define all pwm core's symbols in the namespace "PWM". The necessary module import statement is just added to the main header, this way every file that knows about the public functions automatically has this namespace available. Thanks to Biju Das for pointing out a cut'n'paste failure in my initial patch. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240607160012.1206874-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: add missing MODULE_DESCRIPTION() macrosJeff Johnson8-0/+8
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-imx1.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-imx27.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-intel-lgm.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-mediatek.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-pxa.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-samsung.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-spear.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-visconti.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240610-md-drivers-pwm-v2-1-b337cfaa70ea@quicinc.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: axi-pwmgen: Make use of regmap_clear_bits()Uwe Kleine-König1-1/+1
Instead of using regmap_update_bits() and passing val=0, better use regmap_clear_bits(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Trevor Gamblin <tgamblin@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240606164047.534741-6-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: jz4740: Another few conversions to regmap_{set,clear}_bits()Uwe Kleine-König1-5/+4
Similar to commit 7d9199995412 ("pwm: jz4740: Use regmap_{set,clear}_bits") convert two more regmap_update_bits() calls to regmap_{set,clear}_bits() which were missed back then. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20240606164047.534741-5-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: Add driver for AXI PWM generatorDrew Fustini3-0/+255
Add support for the Analog Devices AXI PWM Generator. This device is an FPGA-implemented peripheral used as PWM signal generator and can be interfaced with AXI4. The register map of this peripheral makes it possible to configure the period and duty cycle of the output signal. Link: https://analogdevicesinc.github.io/hdl/library/axi_pwm_gen/index.html Co-developed-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Co-developed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Drew Fustini <dfustini@baylibre.com> Acked-by: Nuno Sa <nuno.sa@analog.com> Co-developed-by: Trevor Gamblin <tgamblin@baylibre.com> Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com> Link: https://lore.kernel.org/r/20240605203507.1934434-3-tgamblin@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-10pwm: atmel-tcb: Fix race condition and convert to guardsUwe Kleine-König1-7/+5
The hardware only supports a single period length for both PWM outputs. So atmel_tcb_pwm_config() checks the configuration of the other output if it's compatible with the currently requested setting. The register values are then actually updated in atmel_tcb_pwm_enable(). To make this race free the lock must be held during the whole process, so grab the lock in .apply() instead of individually in atmel_tcb_pwm_disable() and atmel_tcb_pwm_enable() which then also covers atmel_tcb_pwm_config(). To simplify handling, use the guard helper to let the compiler care for unlocking. Otherwise unlocking would be more difficult as there is more than one exit path in atmel_tcb_pwm_apply(). Fixes: 9421bade0765 ("pwm: atmel: add Timer Counter Block PWM driver") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20240709101806.52394-3-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-07-06pwm: stm32: Always do lazy disablingUwe Kleine-König1-2/+3
When the state changes from enabled to disabled, polarity, duty_cycle and period are not configured in hardware and TIM_CCER_CCxE is just cleared. However if the state changes from one disabled state to another, all parameters are written to hardware because the early exit from stm32_pwm_apply() is only taken if the pwm is currently enabled. This yields surprises like: Applying { .period = 1, .duty_cycle = 0, .enabled = false } succeeds if the pwm is initially on, but fails if it's already off because 1 is a too small period. Update the check for lazy disable to always exit early if the target state is disabled, no matter what is currently configured. Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240703110010.672654-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-06-22pwm: stm32: Fix error message to not describe the previous error pathUwe Kleine-König1-1/+2
"Failed to lock the clock" is an appropriate error message for clk_rate_exclusive_get() failing, but not for the clock running too fast for the driver's calculations. Adapt the error message accordingly. Fixes: d44d635635a7 ("pwm: stm32: Fix for settings using period > UINT32_MAX") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/285182163211203fc823a65b180761f46e828dcb.1718979150.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-06-22pwm: stm32: Fix calculation of prescalerUwe Kleine-König1-6/+12
A small prescaler is beneficial, as this improves the resolution of the duty_cycle configuration. However if the prescaler is too small, the maximal possible period becomes considerably smaller than the requested value. One situation where this goes wrong is the following: With a parent clock rate of 208877930 Hz and max_arr = 0xffff = 65535, a request for period = 941243 ns currently results in PSC = 1. The value for ARR is then calculated to ARR = 941243 * 208877930 / (1000000000 * 2) - 1 = 98301 This value is bigger than 65535 however and so doesn't fit into the respective register field. In this particular case the PWM was configured for a period of 313733.4806027616 ns (with ARR = 98301 & 0xffff). Even if ARR was configured to its maximal value, only period = 627495.6861167669 ns would be achievable. Fix the calculation accordingly and adapt the comment to match the new algorithm. With the calculation fixed the above case results in PSC = 2 and so an actual period of 941229.1667195285 ns. Fixes: 8002fbeef1e4 ("pwm: stm32: Calculate prescaler with a division instead of a loop") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/b4d96b79917617434a540df45f20cb5de4142f88.1718979150.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-06-21pwm: stm32: Refuse too small period requestsUwe Kleine-König1-0/+2
If period_ns is small, prd might well become 0. Catch that case because otherwise with regmap_write(priv->regmap, TIM_ARR, prd - 1); a few lines down quite a big period is configured. Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm") Cc: stable@vger.kernel.org Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/b86f62f099983646f97eeb6bfc0117bb2d0c340d.1718979150.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-05-10pwm: pca9685: Drop explicit initialization of struct ↵Uwe Kleine-König1-2/+2
i2c_device_id::driver_data to 0 The driver doesn't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. While add it, also remove the trailing commas after the sentinel entry. Link: https://lore.kernel.org/r/20240508130618.2148631-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: meson: Use mul_u64_u64_div_u64() for frequency calculatingGeorge Stark1-2/+2
While calculating frequency for the given period u64 numbers are multiplied before division what can lead to overflow in theory so use secure mul_u64_u64_div_u64() which handles overflow correctly. Fixes: 329db102a26d ("pwm: meson: make full use of common clock framework") Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: George Stark <gnstark@salutedevices.com> Link: https://lore.kernel.org/r/20240425171253.2752877-4-gnstark@salutedevices.com Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: meson: Add check for error from clk_round_rate()George Stark1-5/+6
clk_round_rate() can return not only zero if requested frequency can not be provided but also negative error code so add check for it too. Also change type of variable holding clk_round_rate() result from unsigned long to long. It's safe due to clk_round_rate() returns long. Fixes: 329db102a26d ("pwm: meson: make full use of common clock framework") Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Signed-off-by: George Stark <gnstark@salutedevices.com> Link: https://lore.kernel.org/r/20240425171253.2752877-3-gnstark@salutedevices.com Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: meson: Drop unneeded check in .get_state()George Stark1-3/+0
Drop checking state argument for NULL pointer in meson_pwm_get_state() due to it is called only from pwm core with always valid arguments. Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Signed-off-by: George Stark <gnstark@salutedevices.com> Link: https://lore.kernel.org/r/20240425171253.2752877-2-gnstark@salutedevices.com Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: meson: Add generic compatible for meson8 to sm1Jerome Brunet1-74/+121
Introduce a new compatible support in the Amlogic PWM driver. The PWM HW is actually the same for all SoCs supported so far. A specific compatible is needed only because the clock sources of the PWMs are hard-coded in the driver. It is better to have the clock source described in DT but this changes the bindings so a new compatible must be introduced. When all supported platform have migrated to the new compatible, support for the legacy ones may be removed from the driver. The addition of this new compatible makes the old ones obsolete, as described in the DT documentation. Adding a callback to setup the clock will also make it easier to add support for the new PWM HW found in a1, s4, c3 and t7 SoC families. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20240221151154.26452-6-jbrunet@baylibre.com Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: bcm2835: Drop open coded variant of devm_clk_rate_exclusive_get()Uwe Kleine-König1-13/+1
Since commit b0cde62e4c54 ("clk: Add a devm variant of clk_rate_exclusive_get()") the clk subsystem provides devm_clk_rate_exclusive_get(). Replace the open coded implementation by the new function. Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/8e1a5151a7bcd455996c873bb3d13ab86def3490.1710078146.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: bcm2835: Introduce a local variable for &pdev->devUwe Kleine-König1-9/+9
&pdev->dev is used several times in bcm2835_pwm_probe(). Introduce a local variable to simplify all usages. Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/3f302472e30e21c7ef5624a1d0a2890d9fdf3c7f.1710078146.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: stm32: Calculate prescaler with a division instead of a loopUwe Kleine-König1-13/+17
Instead of looping over increasing values for the prescaler and testing if it's big enough, calculate the value using a single division. Link: https://lore.kernel.org/r/498a44b313a6c0a84ccddd03cd67aadaaaf7daf2.1710711976.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: stm32: Fix for settings using period > UINT32_MAXUwe Kleine-König1-8/+20
stm32_pwm_config() took the duty_cycle and period values with the type int, however stm32_pwm_apply() passed u64 values there. Expand the function parameters to u64 to not discard relevant bits and adapt the calculations to the wider type. To ensure the calculations won't overflow, check in .probe() the input clk doesn't run faster than 1 GHz. Link: https://lore.kernel.org/r/06b4a650a608d0887d934c1b2b8919e0f78e4db2.1710711976.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: stm32: Improve precision of calculation in .apply()Uwe Kleine-König1-2/+3
While mathematically it's ok to calculate the number of cyles for the duty cycle as: duty_cycles = period_cycles * duty_ns / period_ns this doesn't always give the right result when doing integer math. This is best demonstrated using an example: With the input clock running at 208877930 Hz a request for duty_cycle = 383 ns and period = 49996 ns results in period_cycles = clkrate * period_ns / NSEC_PER_SEC = 10443.06098828 Now calculating duty_cycles with the above formula gives: duty_cycles = 10443.06098828 * 383 / 49996 = 80.00024719 However with period_cycle truncated to an integer results in: duty_cycles = 10443 * 383 / 49996 = 79.99977998239859 So while a value of (a little more than) 80 would be the right result, only 79 is used here. The problem here is that 14443 is a rounded result that should better not be used to do further math. So to fix that use the exact formular similar to how period_cycles is calculated. Link: https://lore.kernel.org/r/7628ecd8a7538aa5a7397f0fc4199a077168e8a6.1710711976.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: stm32: Add error messages in .probe()'s error pathsUwe Kleine-König1-3/+6
Giving an indication about the problem if probing a device fails is a nice move. Do that for the stm32 pwm driver. Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20240315145443.982807-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-30pwm: Don't check pointer for being non-NULL after useUwe Kleine-König1-1/+3
After assigning chip = pwm->chip; the compiler is free to assume that pwm is non-NULL and so can optimize out the check for pwm against NULL. While it's probably a programming error to pass a NULL pointer to pwm_put() this shouldn't be dropped without careful consideration and wasn't intended. So assign chip only after the NULL check. Reported-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/66a6f562-1fdd-4e45-995a-e7995432aa0c@baylibre.com Fixes: 4c56b1434b81 ("pwm: Add a struct device to struct pwm_chip") Link: https://lore.kernel.org/r/20240329101648.544155-2-u.kleine-koenig@pengutronix.de Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: Add a struct device to struct pwm_chipUwe Kleine-König1-42/+51
This replaces the formerly dynamically allocated struct device. This allows to additionally use it to track the lifetime of the struct pwm_chip. Otherwise the new struct device provides the same sysfs API as was provided by the dynamic device before. Link: https://lore.kernel.org/r/35c65ea7f6de789a568ff39d7b6b4ce80de4b7dc.1710670958.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: Ensure a struct pwm has the same lifetime as its pwm_chipUwe Kleine-König1-17/+10
It's required to not free the memory underlying a requested PWM while a consumer still has a reference to it. While currently a pwm_chip doesn't live long enough in all cases, linking the struct pwm to the pwm_chip results in the right lifetime as soon as the pwmchip is living long enough. This happens with the following commits. Note this is a breaking change for all pwm drivers that don't use pwmchip_alloc(). Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> # for struct_size() and __counted_by() Link: https://lore.kernel.org/r/7e9e958841f049026c0023b309cc9deecf0ab61d.1710670958.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: Move contents of sysfs.c into core.cUwe Kleine-König4-561/+534
With the upcoming restructuring having all in a single file simplifies things a bit. The relevant and somewhat visible changes are: - Some dropped prototypes from include/linux/pwm.h that were only necessary that core.c has a declaration of the symbols defined in sysfs.c. The respective functions are static now. - The pwm class now also exists if CONFIG_SYSFS isn't enabled. Having CONFIG_SYSFS is not very relevant today, but even without it the class and device stuff still provides lifetime tracking. - Both files had an initcall, these are merged into a single one now. Instead of a big #ifdef block for CONFIG_DEBUG_FS, a single if (IS_ENABLED(CONFIG_DEBUG_FS)) is used now. This increases compile coverage a bit and is a tad nicer on the eyes. Link: https://lore.kernel.org/r/9e2d39a5280d7dda5bfc6682a8aef510148635b2.1710670958.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: Give some sysfs related variables and functions better namesUwe Kleine-König1-78/+83
The code handling the sysfs API uses "child" and "parent" to refer to the devices corresponding to a struct pwm or a struct pwm_chip respectively. Other parts of the pwm core use "parent" to refer to the parent device of a struct pwm_chip. So rename "child" to "pwm_dev" and "parent" to "pwmchip_dev" which better explains the semantic. Also two functions are changed to match the new names: child_to_pwm_export() -> pwmexport_from_dev() child_to_pwm_device() -> pwm_from_dev() (which have the additional advantage to start with "pwm" which gives the right scope). Additionally introduce a wrapper for dev_get_drvdata() to convert a pwmchip_dev to the respective pwm_chip. Link: https://lore.kernel.org/r/9cc05aceeae2f06ecb850bccb15ba821e768c183.1710670958.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: sti: Prefer local variable over pointer dereferenceUwe Kleine-König1-10/+10
While the compiler probably optimizes out the pointer dereference, using the local variable holding the same value also benefits the human reader. So simplify accordingly. Also move a loop over all capture lines into the capture if block to group the operations related to capturing in .probe(). Link: https://lore.kernel.org/r/a7a81f3838f7ed7f4d6dbee3d646989cc265f676.1710068192.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: sti: Use devm_kcalloc() instead of calculating the size for devm_kzalloc()Uwe Kleine-König1-1/+2
Using a multiplication to calculate the size of an allocation isn't recommended in case the mulitplication overflows. While the chance this happens is low, preventing such an error is easy enough; so do that. Link: https://lore.kernel.org/r/17062aef42e6677629a056e25c6916d8b6eaedeb.1710068192.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: sti: Maintain all per-chip driver data in a single structUwe Kleine-König1-36/+22
Instead of (arbitrarily?) spliting the per-chip driver data into two structures, put everything into struct sti_pwm_chip. This reduces memory management overhead and a few pointer indirections. Link: https://lore.kernel.org/r/2788a421ec838ee8f63e76a78b04e1d48b49f959.1710068192.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: sti: Drop member from driver data that only carries a constantUwe Kleine-König1-12/+6
The .regfield member of struct sti_pwm_compat_data only holds a pointer to the global array sti_pwm_regfields. Replace the few usages by directly using this array and drop the member, saving a bit of memory and a few pointer dereferences. Link: https://lore.kernel.org/r/7ddb76ef49fd84a07713b46c65374cb51f3b4ac0.1710068192.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: sti: Improve error reporting using dev_err_probe()Uwe Kleine-König1-21/+20
This has the advantage of handling EPROBE_DEFER correctly and being more compact. This change also introduces an error message for a few error paths that lacked an error indicator before. Also sti_pwm_probe_dt() is renamed to sti_pwm_probe_regmap() to better fit what it actually does. Link: https://lore.kernel.org/r/8e540733ab882f2b8873712faf85c4f0cb48133a.1710068192.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2024-04-26pwm: sti: Simplify probe function using devm functionsUwe Kleine-König1-36/+3
Instead of of_clk_get_by_name() use devm_clk_get_prepared() which has several advantages: - Combines getting the clock and a call to clk_prepare(). The latter can be dropped from sti_pwm_probe() accordingly. - Cares for calling clk_put() which is missing in both probe's error path and the remove function. - Cares for calling clk_unprepare() which can be dropped from the error paths and the remove function. (Note that not all error path got this right.) With additionally using devm_pwmchip_add() instead of pwmchip_add() the remove callback can be dropped completely. With it the last user of platform_get_drvdata() goes away and so platform_set_drvdata() can be dropped from the probe function, too. Fixes: 378fe115d19d ("pwm: sti: Add new driver for ST's PWM IP") Link: https://lore.kernel.org/r/81f0e1d173652f435afda6719adaed1922fe059a.1710068192.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-27 03:27:14 +0300