summaryrefslogtreecommitdiff
path: root/drivers/pwm
AgeCommit message (Collapse)AuthorFilesLines
2021-05-05Merge tag 'pwm/for-5.13-rc1' of ↵Linus Torvalds58-349/+466
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This adds support for the PWM controller found on Toshiba Visconti SoCs and converts a couple of drivers to the atomic API. There's also a bunch of cleanups and minor fixes across the board" * tag 'pwm/for-5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (35 commits) pwm: Reword docs about pwm_apply_state() pwm: atmel: Improve duty cycle calculation in .apply() pwm: atmel: Fix duty cycle calculation in .get_state() pwm: visconti: Add Toshiba Visconti SoC PWM support dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller arm64: dts: rockchip: Remove clock-names from PWM nodes ARM: dts: rockchip: Remove clock-names from PWM nodes dt-bindings: pwm: rockchip: Add more compatible strings dt-bindings: pwm: Convert pwm-rockchip.txt to YAML pwm: mediatek: Remove unused function pwm: pca9685: Improve runtime PM behavior pwm: pca9685: Support hardware readout pwm: pca9685: Switch to atomic API pwm: lpss: Don't modify HW state in .remove callback pwm: sti: Free resources only after pwmchip_remove() pwm: sti: Don't modify HW state in .remove callback pwm: lpc3200: Don't modify HW state in .remove callback pwm: lpc18xx-sct: Free resources only after pwmchip_remove() pwm: bcm-kona: Don't modify HW state in .remove callback pwm: bcm2835: Free resources only after pwmchip_remove() ...
2021-04-28Merge tag 'mfd-next-5.13' of ↵Linus Torvalds3-0/+193
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "Core Framework: - Add support for Software Nodes to MFD Core - Remove support for Device Properties from MFD Core - Use standard APIs in MFD Core New Drivers: - Add support for ROHM BD9576MUF and BD9573MUF PMICs - Add support for Netronix Embedded Controller, PWM and RTC - Add support for Actions Semi ATC260x PMICs and OnKey New Device Support: - Add support for DG1 PCIe Graphics Card to Intel PMT - Add support for ROHM BD71815 PMIC to ROHM BD71828 - Add support for Tolino Shine 2 HD to Netronix Embedded Controller - Add support for AX10 BMC Secure Updates to Intel M10 BMC Removed Device Support: - Remove Arizona Extcon support from MFD - Remove ST-E AB8500 Power Supply code from MFD - Remove AB3100 altogether New Functionality: - Add support for SMBus and I2C modes to Dialog DA9063 - Switch to using Software Nodes in Intel (various) New/converted Device Tree bindings: - rohm bd71815-pmic, rohm bd9576-pmic, netronix ntxec, actions atc260x, ricoh rn5t618, qcom pm8xxx - Fix-ups: - Fix error handling/path; intel_pmt - Simplify code; rohm-bd718x7, ab8500-core, intel-m10-bmc - Trivial clean-ups (reordering, spelling); rohm-generic, rn5t618, max8997 - Use correct data-type; db8500-prcmu - Remove superfluous code; lp87565, intel_quark_i2c_gpi, lpc_sch, twl - Use generic APIs/defines; lm3533-core, intel_quark_i2c_gpio - Regmap related fix-ups; intel-m10-bmc, sec-core - Reorder resource freeing during remove; intel_quark_i2c_gpio - Make table indexing more robust; intel_quark_i2c_gpio - Fix reference imbalances; arizona-irq - Staticify and (un)constify things; arizona-spi, stmpe, ene-kb3930, intel-lpss-acpi, intel-lpss-pci, atc260x-i2c, intel_quark_i2c_gpio Bug Fixes: - Fix incorrect (register) values; intel-m10-bmc - Kconfig related fixes; ABX500_CORE - Do not clear the Auto Reload Register; stm32-timers" * tag 'mfd-next-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (84 commits) mfd: intel-m10-bmc: Add support for MAX10 BMC Secure Updates Revert "mfd: max8997: Add of_compatible to Extcon and Charger mfd_cell" mfd: twl: Remove unused inline function twl4030charger_usb_en() dt-bindings: mfd: Convert pm8xxx bindings to yaml dt-bindings: mfd: Add compatible for pmk8350 rtc i2c: designware: Get rid of legacy platform data mfd: intel_quark_i2c_gpio: Convert I²C to use software nodes mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000" mfd: arizona: Fix rumtime PM imbalance on error mfd: max8997: Replace 8998 with 8997 mfd: core: Use acpi_find_child_device() for child devices lookup mfd: intel_quark_i2c_gpio: Don't play dirty trick with const mfd: intel_quark_i2c_gpio: Enable MSI interrupt mfd: intel_quark_i2c_gpio: Reuse BAR definitions for MFD cell indexing mfd: ntxec: Support for EC in Tolino Shine 2 HD mfd: stm32-timers: Avoid clearing auto reload register mfd: intel_quark_i2c_gpio: Replace I²C speeds with descriptive definitions mfd: intel_quark_i2c_gpio: Remove unused struct device member mfd: intel_quark_i2c_gpio: Unregister resources in reversed order mfd: Kconfig: ABX500_CORE should depend on ARCH_U8500 ...
2021-04-23pwm: atmel: Improve duty cycle calculation in .apply()Uwe Kleine-König1-7/+16
In the calculation of the register value determining the duty cycle the requested period is used instead of the actually implemented period which results in suboptimal settings. The following example assumes an input clock of 133333333 Hz on one of the SoCs with 16 bit period. When the following state is to be applied: .period = 414727681 .duty_cycle = 652806 the following register values used to be calculated: PRES = 10 CPRD = 54000 CDTY = 53916 which yields an actual duty cycle of a bit more than 645120 ns. The setting PRES = 10 CPRD = 54000 CDTY = 53915 however yields a duty of 652800 ns which is between the current result and the requested value and so is a better approximation. The reason for this error is that for the calculation of CDTY the requested period was used instead of the actually implemented one. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-23pwm: atmel: Fix duty cycle calculation in .get_state()Uwe Kleine-König1-1/+1
The CDTY register contains the number of inactive cycles. .apply() does this correctly, however .get_state() got this wrong. Fixes: 651b510a74d4 ("pwm: atmel: Implement .get_state()") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-23pwm: visconti: Add Toshiba Visconti SoC PWM supportNobuhiro Iwamatsu3-0/+200
Add driver for the PWM controller on Toshiba Visconti ARM SoC. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [thierry.reding@gmail.com: fix up a couple of checkpatch warnings] Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-23pwm: mediatek: Remove unused functionJiapeng Chong1-6/+0
Fix the following clang warning: drivers/pwm/pwm-mediatek.c:110:19: warning: unused function 'pwm_mediatek_readl' [-Wunused-function]. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-23pwm: pca9685: Improve runtime PM behaviorClemens Gruber1-6/+19
The chip does not come out of POR in active state but in sleep state. To be sure (in case the bootloader woke it up) we force it to sleep in probe. If runtime PM is disabled, we instead wake the chip in .probe and put it to sleep in .remove. Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-23pwm: pca9685: Support hardware readoutClemens Gruber1-0/+36
Implement .get_state to read-out the current hardware state. The hardware readout may return slightly different values than those that were set in apply due to the limited range of possible prescale and counter register values. Also note that although the datasheet mentions 200 Hz as default frequency when using the internal 25 MHz oscillator, the calculated period from the default prescaler register setting of 30 is 5079040ns. Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-23pwm: pca9685: Switch to atomic APIClemens Gruber1-170/+91
The switch to the atomic API goes hand in hand with a few fixes to previously experienced issues: - The duty cycle is no longer lost after disable/enable (previously the OFF registers were cleared in disable and the user was required to call config to restore the duty cycle settings) - If one sets a period resulting in the same prescale register value, the sleep and write to the register is now skipped - Previously, only the full ON bit was toggled in GPIO mode (and full OFF cleared if set to high), which could result in both full OFF and full ON not being set and on=0, off=0, which is not allowed according to the datasheet - The OFF registers were reset to 0 in probe, which could lead to the forbidden on=0, off=0. Fixed by resetting to POR default (full OFF) Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: lpss: Don't modify HW state in .remove callbackUwe Kleine-König1-6/+0
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: sti: Free resources only after pwmchip_remove()Uwe Kleine-König1-1/+2
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clocks. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: sti: Don't modify HW state in .remove callbackUwe Kleine-König1-3/+0
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: lpc3200: Don't modify HW state in .remove callbackUwe Kleine-König1-4/+0
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: lpc18xx-sct: Free resources only after pwmchip_remove()Uwe Kleine-König1-1/+3
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clock. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: bcm-kona: Don't modify HW state in .remove callbackUwe Kleine-König1-5/+0
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing.) Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: bcm2835: Free resources only after pwmchip_remove()Uwe Kleine-König1-1/+3
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clock. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: bcm-iproc: Free resources only after pwmchip_remove()Uwe Kleine-König1-1/+3
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clock. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-04-09pwm: atmel: Free resources only after pwmchip_remove()Uwe Kleine-König1-1/+3
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clock. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: Add Raspberry Pi Firmware based PWM busNicolas Saenz Julienne3-0/+216
Adds support to control the PWM bus available in official Raspberry Pi PoE HAT. Only RPi's co-processor has access to it, so commands have to be sent through RPi's firmware mailbox interface. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: Drop function pwmchip_add_with_polarity()Uwe Kleine-König1-22/+3
pwmchip_add() only calls pwmchip_add_with_polarity() and nothing else. All other users of pwmchip_add_with_polarity() are gone. So drop pwmchip_add_with_polarity() and move the code instead to pwmchip_add(). The initial assignment to pwm->state.polarity is dropped. In every correct usage of the PWM API this value is overwritten later anyhow. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: atmel-hlcdc: Use pwmchip_add() instead of pwmchip_add_with_polarity()Uwe Kleine-König1-1/+1
The only side effect of this change is that pwm->state.polarity is initialized to PWM_POLARITY_NORMAL instead of PWM_POLARITY_INVERSED. However all other members of pwm->state are uninitialized and consumers are expected to provide the right polarity (either by setting it explicitly or by using a helper like pwm_init_state() that overwrites .polarity anyhow with a value independent of the initial value). Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: bcm-kona: Use pwmchip_add() instead of pwmchip_add_with_polarity()Uwe Kleine-König1-1/+1
The only side effect of this change is that pwm->state.polarity is initialized to PWM_POLARITY_NORMAL instead of PWM_POLARITY_INVERSED. However all other members of pwm->state are uninitialized and consumers are expected to provide the right polarity (either by setting it explicitly or by using a helper like pwm_init_state() that overwrites .polarity anyhow with a value independent of the initial value). The eventual goal is to remove pwmchip_add_with_polarity() and so simplify the data flow in the PWM core. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: cros-ec: Refuse requests with unsupported polarityUwe Kleine-König1-0/+3
The driver only supports normal polarity and so should refuse requests for inversed polarity. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: sprd: Refuse requests with unsupported polarityUwe Kleine-König1-0/+3
The driver only supports normal polarity and so should refuse requests for inversed polarity. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Chunyan Zhang <zhang.lyra@gmail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: atmel-tcb: Only free resources after pwm_chip_remove() returnedUwe Kleine-König1-4/+4
Otherwise the PWM stops working before the PWM core and its consumers are aware the device is going away. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: atmel-tcb: Implement .apply callbackUwe Kleine-König1-8/+25
This is just pushing down the core's compat code down into the driver using the legacy callback nearly unchanged. The call to .enable() was just dropped from .config() because .apply() calls it unconditionally. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: Return -EINVAL for old-style drivers without .set_polarity callbackUwe Kleine-König1-1/+1
Since commit 2b1c1a5d5148 ("pwm: Use -EINVAL for unsupported polarity") all drivers implementing the apply callback are unified to return -EINVAL if an unsupported polarity is requested. Do the same in the compat code for old-style drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: Always allocate PWM chip base ID dynamicallyUwe Kleine-König55-72/+7
Since commit 5e5da1e9fbee ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") all drivers use dynamic ID allocation explicitly. New drivers are supposed to do the same, so remove support for driver specified base IDs and drop all assignments in the low-level drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: imx-tpm: Use a single line for error messageFabio Estevam1-3/+1
There is no need to split the dev_err() call in three lines. Use a single line to improve readability. Signed-off-by: Fabio Estevam <festevam@gmail.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: ab8500: Implement .apply instead of .config, .enable and .disableUwe Kleine-König1-28/+25
To eventually get rid of all legacy drivers convert this driver to the modern world implementing .apply(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22pwm: bcm2835: Improve period and duty cycle calculationUwe Kleine-König1-8/+27
With an input clk rate bigger than 2000000000, scaler would have been zero which then would have resulted in a division by zero. Also the originally implemented algorithm divided by the result of a division. This nearly always looses precision. Consider a requested period of 1000000 ns. With an input clock frequency of 32786885 Hz the hardware was configured with an actual period of 983869.007 ns (PERIOD = 32258) while the hardware can provide 1000003.508 ns (PERIOD = 32787). And note if the input clock frequency was 32786886 Hz instead, the hardware was configured to 1016656.477 ns (PERIOD = 33333) while the optimal setting results in 1000003.477 ns (PERIOD = 32787). This patch implements proper range checking and only divides once for the calculation of period (and similar for duty_cycle). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Tested-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-10pwm: ntxec: Add driver for PWM function in Netronix ECJonathan Neuschäfer3-0/+193
The Netronix EC provides a PWM output which is used for the backlight on some ebook readers. This patches adds a driver for the PWM output. The .get_state callback is not implemented, because the PWM state can't be read back from the hardware. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2021-02-25Merge tag 'pwm/for-5.12-rc1' of ↵Linus Torvalds6-352/+65
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "The ZTE ZX platform is being removed, so the PWM driver is no longer needed and removed as well. Other than that this contains a small set of fixes and cleanups across a couple of drivers" * tag 'pwm/for-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: pwm: lpc18xx-sct: remove unneeded semicolon pwm: iqs620a: Correct a stale state variable pwm: iqs620a: Fix overflow and optimize calculations pwm: rockchip: Enable clock before calling clk_get_rate() pwm: rockchip: Eliminate potential race condition when probing pwm: rockchip: Replace "bus clk" with "PWM clk" pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare() pwm: rockchip: Enable APB clock during register access while probing pwm: Remove ZTE ZX driver
2021-02-22pwm: lpc18xx-sct: remove unneeded semicolonYang Li1-1/+1
Eliminate the following coccicheck warning: ./drivers/pwm/pwm-lpc18xx-sct.c:292:2-3: Unneeded semicolon Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-02-22pwm: iqs620a: Correct a stale state variableJeff LaBundy1-51/+37
If duty cycle is first set to a value that is sufficiently high to enable the output (e.g. 10000 ns) but then lowered to a value that is quantized to zero (e.g. 1000 ns), the output is disabled as the device cannot drive a constant zero (as expected). However if the device is later re-initialized due to watchdog bite, the output is re-enabled at the next-to-last duty cycle (10000 ns). This is because the iqs620_pwm->out_en flag unconditionally tracks state->enabled instead of what was actually written to the device. To solve this problem, use one state variable that encodes all 257 states of the output (duty_scale) with 0 representing tri-state, 1 representing the minimum available duty cycle and 256 representing 100% duty cycle. Signed-off-by: Jeff LaBundy <jeff@labundy.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-02-22pwm: iqs620a: Fix overflow and optimize calculationsUwe Kleine-König1-3/+5
If state->duty_cycle is 0x100000000000000, the previous calculation of duty_scale overflows and yields a duty cycle ratio of 0% instead of 100%. Fix this by clamping the requested duty cycle to the maximal possible duty cycle first. This way it is possible to use a native integer division instead of a (depending on the architecture) more expensive 64bit division. With this change in place duty_scale cannot be bigger than 256 which allows to simplify the calculation of duty_val. Fixes: 6f0841a8197b ("pwm: Add support for Azoteq IQS620A PWM generator") Tested-by: Jeff LaBundy <jeff@labundy.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: rockchip: Enable clock before calling clk_get_rate()Simon South1-0/+10
The documentation for clk_get_rate() in include/linux/clk.h states the function's result is valid only for a clock source that has been enabled. However, the Rockchip PWM driver uses this function in two places to query the rate of a clock without first ensuring it is enabled. Fix this by modifying rockchip_pwm_get_state() and rockchip_pwm_apply() so they enable a device's PWM clock before querying its rate (in the latter case, the querying is actually done in rockchip_pwm_config()) and disable the clock again before returning. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Simon South <simon@simonsouth.net> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: rockchip: Eliminate potential race condition when probingSimon South1-3/+6
Commit 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") introduced a potential race condition in rockchip_pwm_probe(): A consumer could enable an inactive PWM, or disable a running one, between rockchip_pwm_probe() registering the device via pwmchip_add() and checking whether it is enabled (to determine whether it was started by a bootloader). This could result in a device's PWM clock being either enabled once more than necessary, potentially causing it to continue running when no longer needed, or disabled once more than necessary, producing a warning from the kernel. Eliminate these possibilities by modifying rockchip_pwm_probe() so it checks whether a device is enabled before registering it rather than after. Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Reported-by: Trent Piepho <tpiepho@gmail.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: rockchip: Replace "bus clk" with "PWM clk"Simon South1-2/+2
Clarify the Rockchip PWM driver's error messages by referring to the clock that operates a PWM device as the "PWM" clock, matching its name in the device tree, rather than the "bus" clock (which is especially misleading in the case of devices that also use a separate clock for bus access). Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare()Simon South1-1/+0
If rockchip_pwm_probe() fails to register a PWM device it calls clk_unprepare() for the device's PWM clock, without having first disabled the clock and before jumping to an error handler that also unprepares it. This is likely to produce warnings from the kernel about the clock being unprepared when it is still enabled, and then being unprepared when it has already been unprepared. Prevent these warnings by removing this unnecessary call to clk_unprepare(). Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: rockchip: Enable APB clock during register access while probingSimon South1-3/+5
Commit 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") modified rockchip_pwm_probe() to access a PWM device's registers directly to check whether or not the device is enabled, but did not also change the function so it first enables the device's APB clock to be certain the device can respond. This risks hanging the kernel on systems with PWM devices that use more than a single clock. Avoid this by enabling the device's APB clock before accessing its registers (and disabling the clock when register access is complete). Fixes: 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") Reported-by: Thierry Reding <thierry.reding@gmail.com> Suggested-by: Trent Piepho <tpiepho@gmail.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: Remove ZTE ZX driverArnd Bergmann3-289/+0
The ZTE ZX platform is getting removed, so this driver is no longer needed. Cc: Jun Nie <jun.nie@linaro.org> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-19Merge tag 'pwm/for-5.11-rc1' of ↵Linus Torvalds47-371/+1181
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This is a fairly big release cycle from the PWM framework's point of view. There's a large patcheset here which converts drivers to use the new devm_platform_ioremap_resource() helper and a bunch of minor fixes to existing drivers. Some of the existing drivers also add support for more hardware, such as Atmel SAMA 5D2 and Mediatek MT8183. Finally there's a couple of new drivers for Intel Keem Bay and LGM SoCs as well as the DesignWare PWM controller" * tag 'pwm/for-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (66 commits) pwm: sun4i: Remove erroneous else branch pwm: sl28cpld: Set driver data before registering the PWM chip pwm: Remove unused function pwmchip_add_inversed() pwm: imx27: Fix overflow for bigger periods pwm: bcm2835: Support apply function for atomic configuration pwm: keembay: Fix build failure with -Os pwm: core: Use octal permission pwm: lpss: Make compilable with COMPILE_TEST pwm: Fix dependencies on HAS_IOMEM pwm: Use -EINVAL for unsupported polarity pwm: sti: Remove unnecessary blank line pwm: sti: Avoid conditional gotos pwm: Add PWM fan controller driver for LGM SoC Add DT bindings YAML schema for PWM fan controller of LGM SoC pwm: Add DesignWare PWM Controller Driver dt-bindings: pwm: mtk-disp: add MT8167 SoC binding pwm: mediatek: Add MT8183 SoC support pwm: mediatek: Always use bus clock dt-bindings: pwm: pwm-mediatek: Add documentation for MT8183 SoC pwm: Add PWM driver for Intel Keem Bay ...
2020-12-17pwm: sun4i: Remove erroneous else branchThierry Reding1-5/+1
Commit d3817a647059 ("pwm: sun4i: Remove redundant needs_delay") changed the logic of an else branch so that the PWM_EN and PWM_CLK_GATING bits are now cleared if the PWM is to be disabled, whereas previously the condition was always false, and hence the branch never got executed. This code is reported causing backlight issues on boards based on the Allwinner A20 SoC. Fix this by removing the else branch, which restores the behaviour prior to the offending commit. Note that the PWM_EN and PWM_CLK_GATING bits still get cleared later in sun4i_pwm_apply() if the PWM is to be disabled. Fixes: d3817a647059 ("pwm: sun4i: Remove redundant needs_delay") Reported-by: Taras Galchenko <tpgalchenko@gmail.com> Suggested-by: Taras Galchenko <tpgalchenko@gmail.com> Tested-by: Taras Galchenko <tpgalchenko@gmail.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: sl28cpld: Set driver data before registering the PWM chipThierry Reding1-2/+2
It is good practice to set the driver data before registering a device with a subsystem because the subsystem or the driver core may call back into the driver implementation. This is not currently an issue, but to prevent future changes from causing this to break unexpectedly, make sure that the driver data is set before the PWM chip registration. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: imx27: Fix overflow for bigger periodsUwe Kleine-König1-1/+2
The second parameter of do_div is an u32 and NSEC_PER_SEC * prescale overflows this for bigger periods. Assuming the usual pwm input clk rate of 66 MHz this happens starting at requested period > 606060 ns. Splitting the division into two operations doesn't loose any precision. It doesn't need to be feared that c / NSEC_PER_SEC doesn't fit into the unsigned long variable "duty_cycles" because in this case the assignment above to period_cycles would already have been overflowing as period >= duty_cycle and then the calculation is moot anyhow. Fixes: aef1a3799b5c ("pwm: imx27: Fix rounding behavior") Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Tested-by: Johannes Pointner <johannes.pointner@br-automation.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: bcm2835: Support apply function for atomic configurationLino Sanfilippo1-45/+24
Use the newer .apply function of pwm_ops instead of .config, .enable, .disable and .set_polarity. This guarantees atomic changes of the pwm controller configuration. It also reduces the size of the driver. Since now period is a 64 bit value, add an extra check to reject periods that exceed the possible max value for the 32 bit register. This has been tested on a Raspberry PI 4. Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: keembay: Fix build failure with -OsUwe Kleine-König1-1/+6
The driver used this construct: #define KMB_PWM_LEADIN_MASK GENMASK(30, 0) static inline void keembay_pwm_update_bits(struct keembay_pwm *priv, u32 mask, u32 val, u32 offset) { u32 buff = readl(priv->base + offset); buff = u32_replace_bits(buff, val, mask); writel(buff, priv->base + offset); } ... keembay_pwm_update_bits(priv, KMB_PWM_LEADIN_MASK, 0, KMB_PWM_LEADIN_OFFSET(pwm->hwpwm)); With CONFIG_CC_OPTIMIZE_FOR_SIZE the compiler (here: gcc 10.2.0) this triggers: In file included from /home/uwe/gsrc/linux/drivers/pwm/pwm-keembay.c:16: In function ‘field_multiplier’, inlined from ‘keembay_pwm_update_bits’ at /home/uwe/gsrc/linux/include/linux/bitfield.h:124:17: /home/uwe/gsrc/linux/include/linux/bitfield.h:119:3: error: call to ‘__bad_mask’ declared with attribute error: bad bitfield mask 119 | __bad_mask(); | ^~~~~~~~~~~~ In function ‘field_multiplier’, inlined from ‘keembay_pwm_update_bits’ at /home/uwe/gsrc/linux/include/linux/bitfield.h:154:1: /home/uwe/gsrc/linux/include/linux/bitfield.h:119:3: error: call to ‘__bad_mask’ declared with attribute error: bad bitfield mask 119 | __bad_mask(); | ^~~~~~~~~~~~ The compiler doesn't seem to be able to notice that with field being 0x3ffffff the expression if ((field | (field - 1)) & ((field | (field - 1)) + 1)) __bad_mask(); can be optimized away. So use __always_inline and document the problem in a comment to fix this. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: core: Use octal permissionSoham Biswas1-1/+1
Permission bits are easier readable in octal than with using the symbolic names. Fixes the following warning generated by checkpatch: WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'. #1341: FILE: drivers/pwm/core.c:1341: + debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL, Signed-off-by: Soham Biswas <sohambiswas41@gmail.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: lpss: Make compilable with COMPILE_TESTUwe Kleine-König1-3/+3
All used ACPI functions have dummy implementations, and there is no hard dependency on x86. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>