summaryrefslogtreecommitdiffstats
path: root/drivers/pwm
Commit message (Collapse)AuthorAgeFilesLines
* pwm: Assume a disabled PWM to emit a constant inactive outputUwe Kleine-König2024-11-071-3/+7
| | | | | | | | | | | | | | | | | | | Some PWM hardwares (e.g. MC33XS2410) cannot implement a zero duty cycle but can instead disable the hardware which also results in a constant inactive output. There are some checks (enabled with CONFIG_PWM_DEBUG) to help implementing a driver without violating the normal rounding rules. Make them less strict to let above described hardware pass without warning. Reported-by: Dimitri Fedrau <dima.fedrau@gmail.com> Link: https://lore.kernel.org/r/20241103205215.GA509903@debian Fixes: 3ad1f3a33286 ("pwm: Implement some checks for lowlevel drivers") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Dimitri Fedrau <dima.fedrau@gmail.com> Tested-by: Dimitri Fedrau <dima.fedrau@gmail.com> Link: https://lore.kernel.org/r/20241105153521.1001864-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* pwm: core: export pwm_get_state_hw()David Lechner2024-11-031-13/+27
| | | | | | | | | | | | | | | Export the pwm_get_state_hw() function. This is useful in cases where we want to know what the hardware is actually doing, rather than what what we requested it should do. Locking had to be rearranged to ensure that the chip is still operational before trying to access ops now that this can be called from outside the pwm core. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20241029-pwm-export-pwm_get_state_hw-v2-1-03ba063a3230@baylibre.com [ukleinek: Add dummy for !CONFIG_PWM] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* pwm: core: use device_match_name() instead of strcmp(dev_name(...Andy Shevchenko2024-10-251-3/+1
| | | | | | | | | | | | | Use the dedicated helper for comparing device names against strings. Note, the current code has a check for the dev_name() against NULL. With the current implementations of the device_add() and dev_set_name() it most likely a theoretical assumption that that might happen, while I don't see how. Hence, that check has simply been removed. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241025142704.405340-1-andriy.shevchenko@linux.intel.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* pwm: imx27: Use clk_bulk_*() API to simplify clock handlingFrank Li2024-10-251-41/+22
| | | | | | | | Simplify the clock handling logic by using the clk_bulk_*() API. Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20240910-pwm-v3-2-fbb047896618@nxp.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* pwm: imx27: Workaround of the pwm output bug when decrease the duty cycleClark Wang2024-10-251-2/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement workaround for ERR051198 (https://www.nxp.com/docs/en/errata/IMX8MN_0N14Y.pdf) PWM output may not function correctly if the FIFO is empty when a new SAR value is programmed. Description: When the PWM FIFO is empty, a new value programmed to the PWM Sample register (PWM_PWMSAR) will be directly applied even if the current timer period has not expired. If the new SAMPLE value programmed in the PWM_PWMSAR register is less than the previous value, and the PWM counter register (PWM_PWMCNR) that contains the current COUNT value is greater than the new programmed SAMPLE value, the current period will not flip the level. This may result in an output pulse with a duty cycle of 100%. Workaround: Program the current SAMPLE value in the PWM_PWMSAR register before updating the new duty cycle to the SAMPLE value in the PWM_PWMSAR register. This will ensure that the new SAMPLE value is modified during a non-empty FIFO, and can be successfully updated after the period expires. Write the old SAR value before updating the new duty cycle to SAR. This avoids writing the new value into an empty FIFO. This only resolves the issue when the PWM period is longer than 2us (or <500kHz) because write register is not quick enough when PWM period is very short. Reproduce steps: cd /sys/class/pwm/pwmchip1/pwm0 echo 2000000000 > period # It is easy to observe by using long period echo 1000000000 > duty_cycle echo 1 > enable echo 8000 > duty_cycle # One full high pulse will be seen by scope Fixes: 166091b1894d ("[ARM] MXC: add pwm driver for i.MX SoCs") Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241008194123.1943141-1-Frank.Li@nxp.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* pwm: axi-pwmgen: Enable FORCE_ALIGN by defaultDavid Lechner2024-10-251-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | Enable the FORCE_ALIGN flag by default in the AXI PWMGEN driver. This flag makes the behavior of the PWM output consistent with the description at the top of the driver file. * Limitations: * - The writes to registers for period and duty are shadowed until * LOAD_CONFIG is written to AXI_PWMGEN_REG_RSTN, at which point * they take effect. * - Writing LOAD_CONFIG also has the effect of re-synchronizing all * enabled channels, which could cause glitching on other channels. It * is therefore expected that channels are assigned harmonic periods * and all have a single user coordinating this. Without this flag, the PWM output does not change until the period of all PWM output channels has run out, which makes the PWM impossible to use in some cases because it takes too long to change the output. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20241009-pwm-axi-pwmgen-enable-force_align-v1-2-5d6ad8cbf5b4@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* pwm: axi-pwmgen: Rename 0x10 registerDavid Lechner2024-10-251-6/+6
| | | | | | | | | | | | | | | | | | | Rename the 0x10 register from REG_CONFIG to REG_RSTN. Also rename the associated bit macros accordingly. While touching this, move the bit macros close to the register address macro for better organization. According to [1], the name of the 0x10 register is REG_RSTN, and there is a different register named REG_CONFIG (0x18). So we should not be using REG_CONFIG for the 0x10 register to avoid confusion. [1]: http://analogdevicesinc.github.io/hdl/library/axi_pwm_gen/index.html Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20241009-pwm-axi-pwmgen-enable-force_align-v1-1-5d6ad8cbf5b4@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* Merge tag 'pwm/duty_offset-for-6.13-rc1' of ↵Uwe Kleine-König2024-10-253-416/+1201
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux pwm: Support for duty_offset Support a new abstraction for pwm configuration that allows to specify the time between start of period and the raising edge of the signal ("duty offset"). This is used in a patch series by Trevor Gamblin for triggering an ADC conversion and afterwards read out the result. See https://lore.kernel.org/linux-iio/20240909-ad7625_r1-v5-0-60a397768b25@baylibre.com/ for more details.
| * pwm: stm32: Fix error checking for a regmap_read() callUwe Kleine-König2024-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without first assigning ret, it always evaluates to zero because otherwise this code isn't reached. So assign the return code of regmap_read() to ret to make the following error path do something. This issue was spotted by Coverity. Reported-by: Kees Bakker <kees@ijzerbout.nl> Link: https://lore.kernel.org/linux-pwm/b0199625-9dbb-414b-8948-26ad86fd2740@ijzerbout.nl Fixes: deaba9cff809 ("pwm: stm32: Implementation of the waveform callbacks") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20241003114216.163715-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
| * pwm: Reorder symbols in core.cUwe Kleine-König2024-09-281-156/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This moves pwm_get() and friends above the functions handling registration of pwmchips. The motivation is that character device support needs pwm_get() and pwm_put() and so ideally is defined below these and when a pwmchip is registered this registers the character device. So the natural order is pwm_get() and friend pwm character device symbols pwm_chip functions . The advantage of having these in their natural order is that static functions don't need to be forward declared. Note that the diff that git produces for this change some functions are moved down instead. This is technically equivalent, but not how this change was created. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/193b3d933294da34e020650bff93b778de46b1c5.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
| * pwm: stm32: Implementation of the waveform callbacksUwe Kleine-König2024-09-281-221/+391
| | | | | | | | | | | | | | | | | | Convert the stm32 pwm driver to use the new callbacks for hardware programming. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/332d4f736d8360038d03f109c013441c655eea23.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
| * pwm: axi-pwmgen: Implementation of the waveform callbacksUwe Kleine-König2024-09-281-43/+105
| | | | | | | | | | | | | | | | | | | | Convert the axi-pwmgen driver to use the new callbacks for hardware programming. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Tested-by: Trevor Gamblin <tgamblin@baylibre.com> Link: https://lore.kernel.org/r/922277f07b1d1fb9c9cd915b1ec3fdeec888a916.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
| * pwm: Add tracing for waveform callbacksUwe Kleine-König2024-09-281-4/+20
| | | | | | | | | | | | | | | | | | | | This adds trace events for the recently introduced waveform callbacks. With the introduction of some helper macros consistency among the different events is ensured. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/1d71879b0de3bf01459c7a9d0f040d43eb5ace56.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
| * pwm: Provide new consumer API functions for waveformsUwe Kleine-König2024-09-281-0/+261
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide API functions for consumers to work with waveforms. Note that one relevant difference between pwm_get_state() and pwm_get_waveform*() is that the latter yields the actually configured hardware state, while the former yields the last state passed to pwm_apply*() and so doesn't account for hardware specific rounding. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Tested-by: Trevor Gamblin <tgamblin@baylibre.com> Link: https://lore.kernel.org/r/6c97d27682853f603e18e9196043886dd671845d.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
| * pwm: New abstraction for PWM waveformsUwe Kleine-König2024-09-281-21/+213
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up to now the configuration of a PWM setting is described exclusively by a struct pwm_state which contains information about period, duty_cycle, polarity and if the PWM is enabled. (There is another member usage_power which doesn't completely fit into pwm_state, I ignore it here for simplicity.) Instead of a polarity the new abstraction has a member duty_offset_ns that defines when the rising edge happens after the period start. This is more general, as with a pwm_state the rising edge can only happen at the period's start or such that the falling edge is at the end of the period (i.e. duty_offset_ns == 0 or duty_offset_ns == period_length_ns - duty_length_ns). A disabled PWM is modeled by .period_length_ns = 0. In my eyes this is a nice usage of that otherwise unusable setting, as it doesn't define anything about the future which matches the fact that consumers should consider the state of the output as undefined and it's just there to say "No further requirements about the output, you can save some power.". Further I renamed period and duty_cycle to period_length_ns and duty_length_ns. In the past there was confusion from time to time about duty_cycle being measured in nanoseconds because people expected a percentage of period instead. With "length_ns" as suffix the semantic should be more obvious to people unfamiliar with the pwm subsystem. period is renamed to period_length_ns for consistency. The API for consumers doesn't change yet, but lowlevel drivers can implement callbacks that work with pwm_waveforms instead of pwm_states. A new thing about these callbacks is that the calculation of hardware settings needed to implement a certain waveform is separated from actually writing these settings. The motivation for that is that this allows a consumer to query the hardware capabilities without actually modifying the hardware state. The rounding rules that are expected to be implemented in the round_waveform_tohw() are: First pick the biggest possible period not bigger than wf->period_length_ns. For that period pick the biggest possible duty setting not bigger than wf->duty_length_ns. Third pick the biggest possible offset not bigger than wf->duty_offset_ns. If the requested period is too small for the hardware, it's expected that a setting with the minimal period and duty_length_ns = duty_offset_ns = 0 is returned and this fact is signaled by a return value of 1. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Tested-by: Trevor Gamblin <tgamblin@baylibre.com> Link: https://lore.kernel.org/r/df0faa33bf9e7c9e2e5eab8d31bbf61e861bd401.1726819463.git.u.kleine-koenig@baylibre.com [ukleinek: Update pwm_check_rounding() to return bool instead of int.] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
| * pwm: Add more lockingUwe Kleine-König2024-09-271-8/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This ensures that a pwm_chip that has no corresponding driver isn't used and that a driver doesn't go away while a callback is still running. In the presence of device links this isn't necessary yet (so this is no fix) but for pwm character device support this is needed. To not serialize all pwm_apply_state() calls, this introduces a per chip lock. An additional complication is that for atomic chips a mutex cannot be used (as pwm_apply_atomic() must not sleep) and a spinlock cannot be held while calling an operation for a sleeping chip. So depending on the chip being atomic or not a spinlock or a mutex is used. An additional change implemented here is that on driver remove the .free() callback is called for each requested pwm_device. This is the right time because later (e.g. when the consumer calls pwm_put()) the free function is (maybe) not available any more. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/026aa891c8270a11723a1ba7e4256f456f7e1e86.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: axi-pwmgen: Create a dedicated function for getting driver data from a chipUwe Kleine-König2024-10-251-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compared to direct calls to pwmchip_get_drvdata() a dedicated function has two upsides: A better name and the right type. So the code becomes easier to read and the new function is harder to use wrongly. Another side effect (which is the secret motivation for this patch, but shhh) is that the driver becomes a bit easier to backport to kernel versions that don't have devm_pwmchip_alloc() yet. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com> Link: https://lore.kernel.org/r/20240923125418.16558-2-u.kleine-koenig@baylibre.com [ukleinek: added an * to the new function's prototype to make the compiler happy] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: atmel-tcb: Use min() macroShen Lichuan2024-10-251-2/+2
| | | | | | | | | | | | | | | | | | Use the min() macro to simplify the atmel_tcb_pwm_apply() function and improve its readability. Signed-off-by: Shen Lichuan <shenlichuan@vivo.com> Link: https://lore.kernel.org/r/20240827075749.67583-1-shenlichuan@vivo.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: imx-tpm: Use correct MODULO value for EPWM modeErik Schumacher2024-10-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The modulo register defines the period of the edge-aligned PWM mode (which is the only mode implemented). The reference manual states: "The EPWM period is determined by (MOD + 0001h) ..." So the value that is written to the MOD register must therefore be one less than the calculated period length. Return -EINVAL if the calculated length is already zero. A correct MODULO value is particularly relevant if the PWM has to output a high frequency due to a low period value. Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support") Cc: stable@vger.kernel.org Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com> Link: https://lore.kernel.org/r/1a3890966d68b9f800d457cbf095746627495e18.camel@iris-sensing.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | Merge tag 'soc-ep93xx-dt-6.12' of ↵Linus Torvalds2024-09-261-18/+8
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC update from Arnd Bergmann: "Convert ep93xx to devicetree This concludes a long journey towards replacing the old board files with devictree description on the Cirrus Logic EP93xx platform. Nikita Shubin has been working on this for a long time, for details see the last post on https://lore.kernel.org/lkml/20240909-ep93xx-v12-0-e86ab2423d4b@maquefel.me/" * tag 'soc-ep93xx-dt-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (47 commits) dt-bindings: gpio: ep9301: Add missing "#interrupt-cells" to examples MAINTAINERS: Update EP93XX ARM ARCHITECTURE maintainer soc: ep93xx: drop reference to removed EP93XX_SOC_COMMON config net: cirrus: use u8 for addr to calm down sparse dmaengine: cirrus: use snprintf() to calm down gcc 13.3.0 dmaengine: ep93xx: Fix a NULL vs IS_ERR() check in probe() pinctrl: ep93xx: Fix raster pins typo spi: ep93xx: update kerneldoc comments for ep93xx_spi clk: ep93xx: Fix off by one in ep93xx_div_recalc_rate() clk: ep93xx: add module license dmaengine: cirrus: remove platform code ASoC: cirrus: edb93xx: Delete driver ARM: ep93xx: soc: drop defines ARM: ep93xx: delete all boardfiles ata: pata_ep93xx: remove legacy pinctrl use pwm: ep93xx: drop legacy pinctrl ARM: ep93xx: DT for the Cirrus ep93xx SoC platforms ARM: dts: ep93xx: Add EDB9302 DT ARM: dts: ep93xx: add ts7250 board ARM: dts: add Cirrus EP93XX SoC .dtsi ...
| * pwm: ep93xx: drop legacy pinctrlNikita Shubin2024-09-121-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | Drop legacy gpio request/free since we are using pinctrl for this now. Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * pwm: ep93xx: add DT support for Cirrus EP93xxNikita Shubin2024-09-121-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add OF ID match table. Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Tested-by: Michael Peters <mpeters@embeddedTS.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Kris Bahnsen <kris@embeddedTS.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Acked-by: Damien Le Moal <dlemoal@kernel.org> Acked-by: Sebastian Reichel <sre@kernel.org> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* | pwm: stm32: Fix a typoAndrew Kreimer2024-09-161-1/+1
| | | | | | | | | | | | | | | | | | Fix a typo in comments. Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Kreimer <algonell@gmail.com> Link: https://lore.kernel.org/r/20240912124944.43284-1-algonell@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: Switch back to struct platform_driver::remove()Uwe Kleine-König2024-09-1614-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all pwm drivers to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240909073125.382040-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: axi-pwmgen: use shared macro for version regDavid Lechner2024-09-161-2/+1
| | | | | | | | | | | | | | | | | | | | The linux/fpga/adi-axi-common.h header already defines a macro for the version register offset. Use this macro in the axi-pwmgen driver instead of defining it again. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20240816-pwm-axi-pwmgen-use-shared-macro-v1-1-994153ebc3a7@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: atmel-hlcdc: Drop trailing commaLiao Chen2024-09-161-2/+2
| | | | | | | | | | | | | | | | | | Drop the trailing comma in the terminator entry for the ID table to make code robust against misrebases. Signed-off-by: Liao Chen <liaochen4@huawei.com> Link: https://lore.kernel.org/r/20240831075059.790861-3-liaochen4@huawei.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: atmel-hlcdc: Enable module autoloadingLiao Chen2024-09-161-0/+1
| | | | | | | | | | | | | | | | | | Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from of_device_id table. Signed-off-by: Liao Chen <liaochen4@huawei.com> Link: https://lore.kernel.org/r/20240831075059.790861-2-liaochen4@huawei.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: omap-dmtimer: Use of_property_read_bool()Rob Herring (Arm)2024-09-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Use of_property_read_bool() to read boolean properties rather than of_get_property(). This is part of a larger effort to remove callers of of_get_property() and similar functions. of_get_property() leaks the DT property data pointer which is a problem for dynamically allocated nodes which may be freed. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240731191312.1710417-25-robh@kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: adp5585: Set OSC_EN bit to 1 when PWM state is enabledLiu Ying2024-09-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | It turns out that OSC_EN bit in GERNERAL_CFG register has to be set to 1 when PWM state is enabled, otherwise PWM signal won't be generated. Fixes: e9b503879fd2 ("pwm: adp5585: Add Analog Devices ADP5585 support") Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20240826083337.1835405-1-victor.liu@nxp.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | Merge tag 'ib-mfd-gpio-pwm-v6.12' of ↵Uwe Kleine-König2024-09-163-0/+192
|\ \ | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Immutable branch between MFD, GPIO and PWM due for the v6.12 merge window
| * | pwm: adp5585: Add Analog Devices ADP5585 supportClark Wang2024-08-013-0/+192
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ADP5585 is a 10/11 input/output port expander with a built in keypad matrix decoder, programmable logic, reset generator, and PWM generator. This driver supports the PWM function using the platform device registered by the core MFD driver. The driver is derived from an initial implementation from NXP, available in commit 113113742208 ("MLK-25922-1 pwm: adp5585: add adp5585 PWM support") in their BSP kernel tree. It has been extensively rewritten. Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> Link: https://lore.kernel.org/r/20240722121100.2855-5-laurent.pinchart@ideasonboard.com Signed-off-by: Lee Jones <lee@kernel.org>
* | pwm: lp3943: Fix an incorrect type in lp3943_pwm_parse_dt()Jiapeng Chong2024-09-161-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The return value from the call to of_property_count_u32_elems() is int. However, the return value is being assigned to an u32 variable 'num_outputs', so making 'num_outputs' an int. ./drivers/pwm/pwm-lp3943.c:238:6-17: WARNING: Unsigned expression compared with zero: num_outputs <= 0. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9710 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Fixes: 75f0cb339b78 ("pwm: lp3943: Use of_property_count_u32_elems() to get property length") Link: https://lore.kernel.org/r/20240809080523.32717-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: Simplify pwm_capture()Uwe Kleine-König2024-09-051-4/+4
| | | | | | | | | | | | | | | | | | When pwm_capture() is called, pwm is valid, so the checks for pwm and pwm->chip->ops being NULL can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/ee7b3322c7b3e28defdfb886a70b8ba40d298416.1722261050.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: lp3943: Use of_property_count_u32_elems() to get property lengthRob Herring (Arm)2024-09-051-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace of_get_property() with the type specific of_property_count_u32_elems() to get the property length. This is part of a larger effort to remove callers of of_get_property() and similar functions. of_get_property() leaks the DT property data pointer which is a problem for dynamically allocated nodes which may be freed. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240731201407.1838385-8-robh@kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: Don't export pwm_capture()Uwe Kleine-König2024-09-051-3/+2
| | | | | | | | | | | | | | | | | | There is only a single caller of this function, and that's in drivers/pwm/core.c itself. So don't export the function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240712171821.1470833-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* | pwm: stm32: Use the right CCxNP bit in stm32_pwm_enable()Uwe Kleine-König2024-09-051-1/+1
|/ | | | | | | | | | | | The pwm devices for a pwm_chip are numbered starting at 0, the first hw channel however has the number 1. While introducing a parametrised macro to simplify register bit usage and making that offset explicit, one of the usages was converted wrongly. This is fixed here. Fixes: 7cea05ae1d4e ("pwm-stm32: Make use of parametrised register definitions") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240905090627.197536-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
* of: remove internal arguments from of_property_for_each_u32()Luca Ceresoli2024-07-251-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The of_property_for_each_u32() macro needs five parameters, two of which are primarily meant as internal variables for the macro itself (in the for() clause). Yet these two parameters are used by a few drivers, and this can be considered misuse or at least bad practice. Now that the kernel uses C11 to build, these two parameters can be avoided by declaring them internally, thus changing this pattern: struct property *prop; const __be32 *p; u32 val; of_property_for_each_u32(np, "xyz", prop, p, val) { ... } to this: u32 val; of_property_for_each_u32(np, "xyz", val) { ... } However two variables cannot be declared in the for clause even with C11, so declare one struct that contain the two variables we actually need. As the variables inside this struct are not meant to be used by users of this macro, give the struct instance the noticeable name "_it" so it is visible during code reviews, helping to avoid new code to use it directly. Most usages are trivially converted as they do not use those two parameters, as expected. The non-trivial cases are: - drivers/clk/clk.c, of_clk_get_parent_name(): easily doable anyway - drivers/clk/clk-si5351.c, si5351_dt_parse(): this is more complex as the checks had to be replicated in a different way, making code more verbose and somewhat uglier, but I refrained from a full rework to keep as much of the original code untouched having no hardware to test my changes All the changes have been build tested. The few for which I have the hardware have been runtime-tested too. Reviewed-by: Andre Przywara <andre.przywara@arm.com> # drivers/clk/sunxi/clk-simple-gates.c, drivers/clk/sunxi/clk-sun8i-bus-gates.c Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> # drivers/gpio/gpio-brcmstb.c Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> # drivers/irqchip/irq-atmel-aic-common.c Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # drivers/iio/adc/ti_am335x_adc.c Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> # drivers/pwm/pwm-samsung.c Acked-by: Richard Leitner <richard.leitner@linux.dev> # drivers/usb/misc/usb251xb.c Acked-by: Mark Brown <broonie@kernel.org> # sound/soc/codecs/arizona.c Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> # sound/soc/codecs/arizona.c Acked-by: Michael Ellerman <mpe@ellerman.id.au> # arch/powerpc/sysdev/xive/spapr.c Acked-by: Stephen Boyd <sboyd@kernel.org> # clk Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Acked-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20240724-of_property_for_each_u32-v3-1-bea82ce429e2@bootlin.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
* pwm: axi-pwmgen: add .max_register to regmapTrevor Gamblin2024-07-111-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>
* pwm: atmel-tcb: Make private data variable naming consistentUwe Kleine-König2024-07-101-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>
* pwm: atmel-tcb: Simplify checking the companion outputUwe Kleine-König2024-07-101-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>
* pwm: Allow pwm state transitions from an invalid stateUwe Kleine-König2024-07-101-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>
* pwm: xilinx: Simplify using devm_ functionsUwe Kleine-König2024-07-101-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>
* pwm: Use guards for pwm_lookup_lock instead of explicity mutex_lock + ↵Uwe Kleine-König2024-07-101-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>
* pwm: Use guards for export->lock instead of explicity mutex_lock + mutex_unlockUwe Kleine-König2024-07-101-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>
* pwm: Use guards for pwm_lock instead of explicity mutex_lock + mutex_unlockUwe Kleine-König2024-07-101-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>
* pwm: Register debugfs operations after the pwm classUwe Kleine-König2024-07-101-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>
* pwm: imx-tpm: Enable pinctrl setting for sleep stateShenwei Wang2024-07-101-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>
* pwm: lpss: drop redundant runtime PM handlesRaag Jadav2024-07-101-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>
* pwm: lpss: use devm_pm_runtime_enable() helperRaag Jadav2024-07-101-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>
* pwm-stm32: Make use of parametrised register definitionsUwe Kleine-König2024-07-101-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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-26 04:38:36 +0000