- 10 Jul, 2024 31 commits
-
-
Uwe Kleine-König authored
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.comSigned-off-by:
Uwe Kleine-König <ukleinek@kernel.org>
-
Uwe Kleine-König authored
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 authored
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 authored
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:
Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/20240628063524.92907-2-u.kleine-koenig@baylibre.comSigned-off-by:
-
Uwe Kleine-König authored
With the compiler caring for unlocking the mutex several functions can be simplified. Benefit from that. Signed-off-by:
-
Uwe Kleine-König authored
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 authored
With the compiler caring for unlocking the mutex several functions can be simplified. Benefit from that. Signed-off-by:
-
Uwe Kleine-König authored
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:
-
Shenwei Wang authored
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.comSigned-off-by:
-
Raag Jadav authored
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] c5eb1190 ("PCI / PM: Allow runtime PM without callback functions") [2] fa885b06 ("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.comSigned-off-by:
-
Raag Jadav authored
Use devm_pm_runtime_enable() helper to enable runtime PM and drop redundant platform ->remove() callback. Reviewed-by:
-
Uwe Kleine-König authored
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 authored
Merge tag 'ib-mfd-counter-v5.11' of https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into HEAD Immutable branch between MFD and Counter due for the v5.11 merge window
-
Frank Li authored
The driver "drivers/pwm/pwm-imx27.c" never use interrupt. Generally pwm hardware generate a waveform according to register timing setting. Needn't interrupt handle at all. So remove it from "required" list. Signed-off-by:
Frank Li <Frank.Li@nxp.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240605220839.1398872-1-Frank.Li@nxp.comSigned-off-by:
-
Junyi Zhao authored
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.comSigned-off-by:
-
Vincent Whitchurch authored
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:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Andy Shevchenko <andy@kernel.org> Signed-off-by:
Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20240604-pwm-gpio-v7-2-6b67cf60db92@linaro.orgSigned-off-by:
-
Nicola Di Lieto authored
Add bindings for PWM modulated by GPIO. Signed-off-by:
Nicola Di Lieto <nicola.dilieto@gmail.com> Co-developed-by:
-
Uwe Kleine-König authored
This function is not supposed to be used any more since commit c748a6d7 ("pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()") that is included in v6.8-rc1. Two kernel releases should be enough for everyone to adapt, so drop the old function that was introduced as a compatibility stub for the transition. Signed-off-by:
-
Sean Young authored
pwm_apply_state() is deprecated since commit c748a6d7 ("pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()"). Signed-off-by:
Sean Young <sean@mess.org> Acked-by:
-
Uwe Kleine-König authored
When .get_state() is called is an implementation detail that implementors and users shouldn't care about and rely on. Additionally it's wrong, because with PWM_DEBUG enabled it is called more often. Just drop the wrong statement. Signed-off-by:
-
Uwe Kleine-König authored
The last user of this function outside of core.c is gone, so it can be made static. Signed-off-by:
Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20240607084416.897777-8-u.kleine-koenig@baylibre.comSigned-off-by:
-
Uwe Kleine-König authored
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 authored
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 authored
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:
-
Jeff Johnson authored
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.comSigned-off-by:
-
Uwe Kleine-König authored
Instead of using regmap_update_bits() and passing val=0, better use regmap_clear_bits(). Signed-off-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.comSigned-off-by:
-
Uwe Kleine-König authored
Similar to commit 7d919999 ("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:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20240606164047.534741-5-u.kleine-koenig@baylibre.comSigned-off-by:
-
Drew Fustini authored
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.htmlCo-developed-by:
Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by:
David Lechner <dlechner@baylibre.com> Signed-off-by:
Drew Fustini <dfustini@baylibre.com> Acked-by:
-
Drew Fustini authored
Add Analog Devices AXI PWM generator. Link: https://analogdevicesinc.github.io/hdl/library/axi_pwm_gen/index.htmlSigned-off-by:
Michael Hennerich <michael.hennerich@analog.com> Acked-by:
-
Frank Li authored
Convert dt-bindings pwm-fsl-ftm.txt to yaml format. Additional change during convert: - "big-endian" is not required property. - Add "sleep" to pinctrl-names. - Change pinctrl-NNN to pinctrl-0 and pinctrl-1. - Remove label "pwm0" in example. Signed-off-by:
-
Uwe Kleine-König authored
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: 9421bade ("pwm: atmel: add Timer Counter Block PWM driver") Signed-off-by:
-
- 05 Jul, 2024 2 commits
-
-
Conor Dooley authored
When commit 89650a1e ("dt-bindings: pwm: Convert PWM bindings to json-schema") converted the pwm provider section of the text binding to dt-schema it also updated all references to pwm.txt in pwm provider bindings to pwm.yaml. Most pwm provider bindings had a reference to pwm.txt as it contains a description of what the cells in #pwm-cells are, albeit in the consumer section of the document. Only information in the provider section of the document was moved to the yaml binding, and it contains no information about the cell format, making all references to it for the cell format unhelpful. Fixes: 89650a1e ("dt-bindings: pwm: Convert PWM bindings to json-schema") Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240517-patient-stingily-30611f73e792@spudSigned-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
-
Uwe Kleine-König authored
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: 7edf7369 ("pwm: Add driver for STM32 plaftorm") Signed-off-by:
-
- 26 Jun, 2024 4 commits
-
-
Uwe Kleine-König authored
This macro is misleading as TIM_DIER_CC_IE(1) == TIM_DIER_CC2IE . The only user was updated to use TIM_DIER_CCxIE() instead which doesn't suffer from this mismatch, so TIM_DIER_CC_IE can be dropped. Signed-off-by:
Lee Jones <lee@kernel.org>
-
Uwe Kleine-König authored
These two defines have the same purpose and this change doesn't introduce any differences in drivers/counter/stm32-timer-cnt.o. The only difference between the two is that TIM_DIER_CC_IE(1) == TIM_DIER_CC2IE while TIM_DIER_CCxIE(1) == TIM_DIER_CC1IE . That makes it necessary to have an explicit "+ 1" in the user code, but IMHO this is a good thing as this is the code locatation that "knows" that for software channel 1 you have to use TIM_DIER_CC2IE (because software guys start counting at 0, while the relevant hardware designer started at 1). Signed-off-by:
William Breathitt Gray <wbg@kernel.org> Link: https://lore.kernel.org/r/126bd153a03f39e42645573eecf44ffab5354fc7.1718791090.git.u.kleine-koenig@baylibre.comSigned-off-by:
-
Uwe Kleine-König authored
There are some registers that belong together and are numbered from 1 to 4. Introduce a macro definition for these that takes the channel number as parameter and define the previously available constants using the new ones. This allows to simplify some users that up to now use constructs like TIM_CCER_CC1NE << (ch * 4) which is an ugly mix of using a predefined value and still knowing internal details about it. Note that there are several decrements by 1 involved. These are necessary because software guys start counting at 0 while the hardware designer started at 1 (and having TIM_CCER_CCxE(1) be TIM_CCER_CC2E isn't a sane option). The compiler is expected to optimize these out nicely. Signed-off-by:
-
Uwe Kleine-König authored
Use tabs consistently for indention and properly align register names, values and comments. This improves readability (at least for my eyes). Signed-off-by:
-
- 22 Jun, 2024 2 commits
-
-
Uwe Kleine-König authored
"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: d44d6356 ("pwm: stm32: Fix for settings using period > UINT32_MAX") Signed-off-by:
-
Uwe Kleine-König authored
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: 8002fbee ("pwm: stm32: Calculate prescaler with a division instead of a loop") Signed-off-by:
-
- 21 Jun, 2024 1 commit
-
-
Uwe Kleine-König authored
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: 7edf7369 ("pwm: Add driver for STM32 plaftorm") Cc: stable@vger.kernel.org Reviewed-by:
-
