summaryrefslogtreecommitdiff
path: root/drivers/pwm
AgeCommit message (Collapse)AuthorFilesLines
2025-02-17pwm: opencores: Add PWM driver supportWilliam Qiu3-0/+251
Add driver for OpenCores PWM Controller. And add compatibility code which based on StarFive SoC. Co-developed-by: Hal Feng <hal.feng@starfivetech.com> Signed-off-by: Hal Feng <hal.feng@starfivetech.com> Signed-off-by: William Qiu <william.qiu@starfivetech.com> Tested-by: Maud Spierings <maud_spierings@hotmail.com> Link: https://lore.kernel.org/r/20250106103540.10079-1-william.qiu@starfivetech.com Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
2025-01-28Merge tag 'driver-core-6.14-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core and debugfs updates from Greg KH: "Here is the big set of driver core and debugfs updates for 6.14-rc1. Included in here is a bunch of driver core, PCI, OF, and platform rust bindings (all acked by the different subsystem maintainers), hence the merge conflict with the rust tree, and some driver core api updates to mark things as const, which will also require some fixups due to new stuff coming in through other trees in this merge window. There are also a bunch of debugfs updates from Al, and there is at least one user that does have a regression with these, but Al is working on tracking down the fix for it. In my use (and everyone else's linux-next use), it does not seem like a big issue at the moment. Here's a short list of the things in here: - driver core rust bindings for PCI, platform, OF, and some i/o functions. We are almost at the "write a real driver in rust" stage now, depending on what you want to do. - misc device rust bindings and a sample driver to show how to use them - debugfs cleanups in the fs as well as the users of the fs api for places where drivers got it wrong or were unnecessarily doing things in complex ways. - driver core const work, making more of the api take const * for different parameters to make the rust bindings easier overall. - other small fixes and updates All of these have been in linux-next with all of the aforementioned merge conflicts, and the one debugfs issue, which looks to be resolved "soon"" * tag 'driver-core-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (95 commits) rust: device: Use as_char_ptr() to avoid explicit cast rust: device: Replace CString with CStr in property_present() devcoredump: Constify 'struct bin_attribute' devcoredump: Define 'struct bin_attribute' through macro rust: device: Add property_present() saner replacement for debugfs_rename() orangefs-debugfs: don't mess with ->d_name octeontx2: don't mess with ->d_parent or ->d_parent->d_name arm_scmi: don't mess with ->d_parent->d_name slub: don't mess with ->d_name sof-client-ipc-flood-test: don't mess with ->d_name qat: don't mess with ->d_name xhci: don't mess with ->d_iname mtu3: don't mess wiht ->d_iname greybus/camera - stop messing with ->d_iname mediatek: stop messing with ->d_iname netdevsim: don't embed file_operations into your structs b43legacy: make use of debugfs_get_aux() b43: stop embedding struct file_operations into their objects carl9170: stop embedding file_operations into their objects ...
2025-01-28Merge tag 'pwm/for-6.14-rc1-fixes' of ↵Linus Torvalds2-3/+12
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux Pull pwm fixes from Uwe Kleine-König: "Two fixes. Conor Dooley found and fixed a problem in the pwm-microchip-core driver that existed since the driver's birth in v6.5-rc1. It's about a corner case that only happens if two pwm devices of the same chip are set to the same long period. The other problem is about the new pwm API that currently is only supported by two hardware drivers. The fix prevents a NULL pointer exception if one of the new functions is called for a pwm device with a driver that only provides the old callbacks" * tag 'pwm/for-6.14-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: Ensure callbacks exist before calling them pwm: microchip-core: fix incorrect comparison with max period
2025-01-23pwm: Ensure callbacks exist before calling themUwe Kleine-König1-2/+11
If one of the waveform functions is called for a chip that only supports .apply(), we want that an error code is returned and not a NULL pointer exception. Fixes: 6c5126c6406d ("pwm: Provide new consumer API functions for waveforms") Cc: stable@vger.kernel.org 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/20250123172709.391349-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-01-23pwm: microchip-core: fix incorrect comparison with max periodConor Dooley1-1/+1
In mchp_core_pwm_apply_locked(), if hw_period_steps is equal to its max, an error is reported and .apply fails. The max value is actually a permitted value however, and so this check can fail where multiple channels are enabled. For example, the first channel to be configured requests a period that sets hw_period_steps to the maximum value, and when a second channel is enabled the driver reads hw_period_steps back from the hardware and finds it to be the maximum possible value, triggering the warning on a permitted value. The value to be avoided is 255 (PERIOD_STEPS_MAX + 1), as that will produce undesired behaviour, so test for greater than, rather than equal to. Fixes: 2bf7ecf7b4ff ("pwm: add microchip soft ip corePWM driver") Cc: stable@vger.kernel.org Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250122-pastor-fancied-0b993da2d2d2@spud Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-01-22Merge tag 'pwm/for-6.14-rc1' of ↵Linus Torvalds4-17/+21
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux Pull pwm updates from Uwe Kleine-König: "This time there are very little changes for pwm. There is nothing new, just a few maintenance cleanups. The contributors this time around were Krzysztof Kozlowski, Mingwei Zheng, Philipp Stanner, and Stanislav Jakubek. Thanks!" * tag 'pwm/for-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: stm32: Add check for clk_enable() dt-bindings: pwm: Correct indentation and style in DTS example pwm: stm32-lp: Add check for clk_enable() dt-bindings: pwm: marvell,berlin-pwm: Convert from txt to yaml dt-bindings: pwm: sprd,ums512-pwm: convert to YAML pwm: Replace deprecated PCI functions
2025-01-17pwm: stm32: Add check for clk_enable()Mingwei Zheng1-2/+5
Add check for the return value of clk_enable() to catch the potential error. Fixes: 19f1016ea960 ("pwm: stm32: Fix enable count for clk in .probe()") Signed-off-by: Mingwei Zheng <zmw12306@gmail.com> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Link: https://lore.kernel.org/r/20241215224752.220318-1-zmw12306@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-01-13Merge 6.13-rc7 into driver-core-nextGreg Kroah-Hartman1-1/+1
We need the debugfs / driver-core fixes in here as well for testing and to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-03driver core: Constify API device_find_child() and adapt for various usagesZijun Hu1-1/+1
Constify the following API: struct device *device_find_child(struct device *dev, void *data, int (*match)(struct device *dev, void *data)); To : struct device *device_find_child(struct device *dev, const void *data, device_match_t match); typedef int (*device_match_t)(struct device *dev, const void *data); with the following reasons: - Protect caller's match data @*data which is for comparison and lookup and the API does not actually need to modify @*data. - Make the API's parameters (@match)() and @data have the same type as all of other device finding APIs (bus|class|driver)_find_device(). - All kinds of existing device match functions can be directly taken as the API's argument, they were exported by driver core. Constify the API and adapt for various existing usages. BTW, various subsystem changes are squashed into this commit to meet 'git bisect' requirement, and this commit has the minimal and simplest changes to complement squashing shortcoming, and that may bring extra code improvement. Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> # for drivers/pwm Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20241224-const_dfc_done-v5-4-6623037414d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-19Merge tag 'pwm/for-6.13-rc4-fixes' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux Pull pwm fix from Uwe Kleine-König: "Fix regression in pwm-stm32 driver when converting to new waveform support Fabrice Gasnier found and fixed a regression I introduced with v6.13-rc1 when converting the stm32 pwm driver to support the new waveform stuff. On some hardware variants this completely broke the driver" * tag 'pwm/for-6.13-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: stm32: Fix complementary output in round_waveform_tohw()
2024-12-18pwm: stm32-lp: Add check for clk_enable()Mingwei Zheng1-2/+6
Add check for the return value of clk_enable() to catch the potential error. We used APP-Miner to find it. Fixes: e70a540b4e02 ("pwm: Add STM32 LPTimer PWM driver") Signed-off-by: Mingwei Zheng <zmw12306@gmail.com> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Link: https://lore.kernel.org/r/20241206215318.3402860-1-zmw12306@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-12-18pwm: Replace deprecated PCI functionsPhilipp Stanner2-13/+10
pcim_iomap_table() and pcim_request_regions() have been deprecated in commit e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()") and commit d140f80f60358 ("PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()"). Replace these functions with pcim_iomap_region(). Additionally, pass the actual driver names to pcim_iomap_region() instead of the previous pci_name(), since the 'name' parameter should always reflect which driver owns a region. Signed-off-by: Philipp Stanner <pstanner@redhat.com> Link: https://lore.kernel.org/r/20241111090944.11293-2-pstanner@redhat.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-12-18pwm: stm32: Fix complementary output in round_waveform_tohw()Fabrice Gasnier1-1/+1
When the timer supports complementary output, the CCxNE bit must be set additionally to the CCxE bit. So to not overwrite the latter use |= instead of = to set the former. Fixes: deaba9cff809 ("pwm: stm32: Implementation of the waveform callbacks") Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20241217150021.2030213-1-fabrice.gasnier@foss.st.com [ukleinek: Slightly improve commit log] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2024-12-03module: Convert default symbol namespace to string literalMasahiro Yamada3-3/+3
Commit cdd30ebb1b9f ("module: Convert symbol namespace to string literal") only converted MODULE_IMPORT_NS() and EXPORT_SYMBOL_NS(), leaving DEFAULT_SYMBOL_NAMESPACE as a macro expansion. This commit converts DEFAULT_SYMBOL_NAMESPACE in the same way to avoid annoyance for the default namespace as well. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02module: Convert symbol namespace to string literalPeter Zijlstra3-3/+3
Clean up the existing export namespace code along the same lines of commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo) to __section("foo")") and for the same reason, it is not desired for the namespace argument to be a macro expansion itself. Scripted using git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file; do awk -i inplace ' /^#define EXPORT_SYMBOL_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /^#define MODULE_IMPORT_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /MODULE_IMPORT_NS/ { $0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g"); } /EXPORT_SYMBOL_NS/ { if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) { if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ && $0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ && $0 !~ /^my/) { getline line; gsub(/[[:space:]]*\\$/, ""); gsub(/[[:space:]]/, "", line); $0 = $0 " " line; } $0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/, "\\1(\\2, \"\\3\")", "g"); } } { print }' $file; done Requested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc Acked-by: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-07pwm: Assume a disabled PWM to emit a constant inactive outputUwe Kleine-König1-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>
2024-11-03pwm: core: export pwm_get_state_hw()David Lechner1-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>
2024-10-25pwm: core: use device_match_name() instead of strcmp(dev_name(...Andy Shevchenko1-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>
2024-10-25pwm: imx27: Use clk_bulk_*() API to simplify clock handlingFrank Li1-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>
2024-10-25pwm: imx27: Workaround of the pwm output bug when decrease the duty cycleClark Wang1-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>
2024-10-25pwm: axi-pwmgen: Enable FORCE_ALIGN by defaultDavid Lechner1-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>
2024-10-25pwm: axi-pwmgen: Rename 0x10 registerDavid Lechner1-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>
2024-10-25Merge tag 'pwm/duty_offset-for-6.13-rc1' of ↵Uwe Kleine-König3-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.
2024-10-25pwm: axi-pwmgen: Create a dedicated function for getting driver data from a chipUwe Kleine-König1-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>
2024-10-25pwm: atmel-tcb: Use min() macroShen Lichuan1-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>
2024-10-25pwm: imx-tpm: Use correct MODULO value for EPWM modeErik Schumacher1-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>
2024-10-04pwm: stm32: Fix error checking for a regmap_read() callUwe Kleine-König1-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>
2024-09-28pwm: Reorder symbols in core.cUwe Kleine-König1-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>
2024-09-28pwm: stm32: Implementation of the waveform callbacksUwe Kleine-König1-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>
2024-09-28pwm: axi-pwmgen: Implementation of the waveform callbacksUwe Kleine-König1-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>
2024-09-28pwm: Add tracing for waveform callbacksUwe Kleine-König1-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>
2024-09-28pwm: Provide new consumer API functions for waveformsUwe Kleine-König1-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>
2024-09-28pwm: New abstraction for PWM waveformsUwe Kleine-König1-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>
2024-09-27pwm: Add more lockingUwe Kleine-König1-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>
2024-09-26Merge tag 'soc-ep93xx-dt-6.12' of ↵Linus Torvalds1-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 ...
2024-09-16pwm: stm32: Fix a typoAndrew Kreimer1-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>
2024-09-16pwm: Switch back to struct platform_driver::remove()Uwe Kleine-König14-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>
2024-09-16pwm: axi-pwmgen: use shared macro for version regDavid Lechner1-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>
2024-09-16pwm: atmel-hlcdc: Drop trailing commaLiao Chen1-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>
2024-09-16pwm: atmel-hlcdc: Enable module autoloadingLiao Chen1-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>
2024-09-16pwm: omap-dmtimer: Use of_property_read_bool()Rob Herring (Arm)1-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>
2024-09-16pwm: adp5585: Set OSC_EN bit to 1 when PWM state is enabledLiu Ying1-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>
2024-09-16Merge tag 'ib-mfd-gpio-pwm-v6.12' of ↵Uwe Kleine-König3-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
2024-09-16pwm: lp3943: Fix an incorrect type in lp3943_pwm_parse_dt()Jiapeng Chong1-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>
2024-09-12pwm: ep93xx: drop legacy pinctrlNikita Shubin1-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>
2024-09-12pwm: ep93xx: add DT support for Cirrus EP93xxNikita Shubin1-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>
2024-09-05pwm: Simplify pwm_capture()Uwe Kleine-König1-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>
2024-09-05pwm: lp3943: Use of_property_count_u32_elems() to get property lengthRob Herring (Arm)1-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>
2024-09-05pwm: Don't export pwm_capture()Uwe Kleine-König1-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>
2024-09-05pwm: stm32: Use the right CCxNP bit in stm32_pwm_enable()Uwe Kleine-König1-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>
generated by cgit v1.2.3 (git 2.39.0) at 2025-05-03 10:01:59 +0300