kernel/linux.git/drivers/pwm, branch linux-5.3.y

pwm: bcm-iproc: Prevent unloading the driver module while in use

2019-12-04T21:34:02+00:00

[ Upstream commit 24906a41eecb73d51974ade0847c21e429beec60 ] The owner member of struct pwm_ops must be set to THIS_MODULE to increase the reference count of the module such that the module cannot be removed while its code is in use. Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Uwe Kleine-König Reviewed-by: Florian Fainelli Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

pwm: stm32-lp: Add check in case requested period cannot be achieved

2019-10-11T16:36:37+00:00

[ Upstream commit c91e3234c6035baf5a79763cb4fcd5d23ce75c2b ] LPTimer can use a 32KHz clock for counting. It depends on clock tree configuration. In such a case, PWM output frequency range is limited. Although unlikely, nothing prevents user from requesting a PWM frequency above counting clock (32KHz for instance): - This causes (prd - 1) = 0xffff to be written in ARR register later in the apply() routine. This results in badly configured PWM period (and also duty_cycle). Add a check to report an error is such a case. Signed-off-by: Fabrice Gasnier Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

pwm: Fallback to the static lookup-list when acpi_pwm_get fails

2019-08-08T11:17:38+00:00

Commit 4a6ef8e37c4d ("pwm: Add support referencing PWMs from ACPI") made pwm_get unconditionally return the acpi_pwm_get return value if the device passed to pwm_get has an ACPI fwnode. But even if the passed in device has an ACPI fwnode, it does not necessarily have the necessary ACPI package defining its pwm bindings, especially since the binding / API of this ACPI package has only been introduced very recently. Up until now X86/ACPI devices which use a separate pwm controller for controlling their LCD screen's backlight brightness have been relying on the static lookup-list to get their pwm. pwm_get unconditionally returning the acpi_pwm_get return value breaks this, breaking backlight control on these devices. This commit fixes this by making pwm_get fall back to the static lookup-list if acpi_pwm_get returns -ENOENT. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96571 Reported-by: youling257@gmail.com Fixes: 4a6ef8e37c4d ("pwm: Add support referencing PWMs from ACPI") Cc: Nikolaus Voss Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Nikolaus Voss Signed-off-by: Thierry Reding

Merge tag 'pwm/for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

2019-07-09T15:57:45+00:00

Pull pwm updates from Thierry Reding: "This set of changes contains a new driver for SiFive SoCs as well as enhancements to the core (device links are used to track dependencies between PWM providers and consumers, support for PWM controllers via ACPI, sysfs will now suspend/resume PWMs that it has claimed) and various existing drivers" * tag 'pwm/for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (37 commits) pwm: fsl-ftm: Make sure to unlock mutex on failure pwm: fsl-ftm: Use write protection for prescaler & polarity pwm: fsl-ftm: More relaxed permissions for updating period pwm: atmel-hlcdc: Add compatible for SAM9X60 HLCDC's PWM pwm: bcm2835: Improve precision of PWM leds: pwm: Support ACPI via firmware-node framework pwm: Add support referencing PWMs from ACPI pwm: rcar: Remove suspend/resume support pwm: sysfs: Add suspend/resume support pwm: Add power management descriptions pwm: meson: Add documentation to the driver pwm: meson: Add support PWM_POLARITY_INVERSED when disabling pwm: meson: Don't cache struct pwm_state internally pwm: meson: Read the full hardware state in meson_pwm_get_state() pwm: meson: Simplify the calculation of the pre-divider and count pwm: meson: Move pwm_set_chip_data() to meson_pwm_request() pwm: meson: Add the per-channel register offsets and bits in a struct pwm: meson: Add the meson_pwm_channel data to struct meson_pwm pwm: meson: Pass struct pwm_device to meson_pwm_calc() pwm: meson: Don't duplicate the polarity internally ...

pwm: fsl-ftm: Make sure to unlock mutex on failure

2019-06-26T09:39:25+00:00

Upon failure to enable clocks while trying to enable the PWM, make sure to unlock the mutex that was taken to avoid a deadlock during subsequent operations. Reported-by: kbuild test robot Reported-by: Julia Lawall Cc: Patrick Havelange Signed-off-by: Thierry Reding

pwm: fsl-ftm: Use write protection for prescaler & polarity

2019-06-26T09:39:18+00:00

Modifying the prescaler or polarity value must be done with the write protection disabled. Currently this is working by chance as the write protection is in a disabled state by default. This patch makes sure that we enable/disable the write protection when needed. Signed-off-by: Patrick Havelange Signed-off-by: Thierry Reding

pwm: fsl-ftm: More relaxed permissions for updating period

2019-06-26T09:39:16+00:00

The Flextimer has only one period for several channels. The PWM subsystem doesn't allow to model something like that. The current implementation simply disallows changing the period once it has been set, having as a side effect that you need to enable and disable the PWM if you want to change the period. The driver should allow as much freedom as possible for configuring the period and duty cycle. Therefore, this patch reworks the code to allow the following: - period and duty_cycle can be set at will when the PWM is disabled; - when enabling a PWM, verify that the period is either not set yet, or the same as the other already enabled PWM(s), and fail if not; - allow to change the period on the fly when the PWM is the only one enabled. It also allows to have different periods configured for different PWMs. Only one period can be used at a time, thus the first PWM to be enabled will set that period, only other PWMs with that same period can be enabled at the same time. To use another PWM with another period, the enabled PWMs must be disabled first. Example scenario : echo 5000000 > pwm0/period #OK echo 1000000 > pwm0/duty_cycle #OK echo 1000000 > pwm1/period #OK echo 1000000 > pwm1/duty_cycle #OK echo 1 > pwm0/enable #OK echo 1 > pwm1/enable #FAIL (pwm0/period != pwm1/period) echo 0 > pwm0/enable #OK echo 1 > pwm1/enable #OK echo 1000000 > pwm0/period #OK echo 2000000 > pwm0/period #OK echo 1 > pwm0/enable #FAIL (pwm0/period != pwm1/period) echo 2000000 > pwm1/period #OK (pwm1 still running, changed on the fly) echo 1 > pwm0/enable #OK (now pwm0/period == pwm1/period) echo 3000000 > pwm1/period #FAIL (other PWMs running) echo 0 > pwm0/enable #OK echo 3000000 > pwm1/period #OK (only this PWM running) Adapting the code to satisfy these constraints turned up a number of additional issues with the current implementation: - the prescaler value 0 was not used (when it could have been); - when setting the period was not possible, the internal state was inconsistent; - the maximal value for configuring the period was never used; Since all of these interact with each other, rather than trying to fix each individual issue, this patch reworks how the period and duty cycle are set entirely, with the following additional improvements: - implement the new apply() method instead of the individual methods; - return the exact used period/duty_cycle values; - more coherent argument types for period, duty_cycle; Signed-off-by: Patrick Havelange Signed-off-by: Thierry Reding

pwm: atmel-hlcdc: Add compatible for SAM9X60 HLCDC's PWM

2019-06-26T09:39:13+00:00

Add compatible string for SAM9X60 HLCDC's PWM. Signed-off-by: Claudiu Beznea Signed-off-by: Thierry Reding

pwm: bcm2835: Improve precision of PWM

2019-06-26T09:39:12+00:00

If sending IR with carrier of 455kHz using the pwm-ir-tx driver, the carrier ends up being 476kHz. The clock is set to bcm2835-pwm with a rate of 10MHz. A carrier of 455kHz has a period of 2198ns, but the arithmetic truncates this to 2100ns rather than 2200ns. So, use DIV_ROUND_CLOSEST() to reduce rounding errors, and we have a much more accurate carrier of 454.5kHz. Reported-by: Andreas Christ Signed-off-by: Sean Young Acked-by: Stefan Wahren Signed-off-by: Thierry Reding

pwm: Add support referencing PWMs from ACPI

2019-06-26T09:39:11+00:00

In analogy to referencing a GPIO using the "gpios" property from ACPI, support referencing a PWM using the "pwms" property. ACPI entries must look like Package () {"pwms", Package () { , , [, ]}} In contrast to the DT implementation, only _one_ PWM entry in the "pwms" property is supported. As a consequence "pwm-names"-property and con_id lookup aren't supported. Support for ACPI is added via the firmware-node framework which is an abstraction layer on top of ACPI/DT. To keep this patch clean, DT and ACPI paths are kept separate. The firmware-node framework could be used to unify both paths in a future patch. To support leds-pwm driver, an additional method devm_fwnode_pwm_get() which supports both ACPI and DT configuration is exported. Signed-off-by: Nikolaus Voss [thierry.reding@gmail.com: fix build failures for !ACPI] Signed-off-by: Thierry Reding