- 03 Apr, 2020 3 commits
-
-
Sven Van Asbroeck authored
This driver allows pwms to be requested as gpios via gpiolib. Obviously, it should not be allowed to request a GPIO when its corresponding PWM is already requested (and vice versa). So it requires some exclusion code. Given that the PWMm and GPIO cores are not synchronized with respect to each other, this exclusion code will also require proper synchronization. Such a mechanism was in place, but was inadvertently removed by Uwe's clean-up in commit e926b12c ("pwm: Clear chip_data in pwm_put()"). Upon revisiting the synchronization mechanism, we found that theoretically, it could allow two threads to successfully request conflicting PWMs/GPIOs. Replace with a bitmap which tracks PWMs in-use, plus a mutex. As long as PWM and GPIO's respective request/free functions modify the in-use bitmap while holding the mutex, proper synchronization will be guaranteed. Reported-by:
YueHaibing <yuehaibing@huawei.com> Fixes: e926b12c ("pwm: Clear chip_data in pwm_put()") Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: YueHaibing <yuehaibing@huawei.com> Link: https://lkml.org/lkml/2019/5/31/963Signed-off-by:
Sven Van Asbroeck <TheSven73@gmail.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> [cg: Tested on an i.MX6Q board with two NXP PCA9685 chips] Tested-by:
Clemens Gruber <clemens.gruber@pqgruber.com> Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com> # cg's rebase Link: https://lore.kernel.org/lkml/20200330160238.GD2817345@ulmo/Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Jason Yan authored
Fix the following gcc warning: drivers/pwm/core.c:467:6: warning: symbol 'pwm_apply_state_debug' was not declared. Should it be static? Reported-by:Hulk Robot <hulkci@huawei.com> Signed-off-by:
Jason Yan <yanaijie@huawei.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Colin Ian King authored
The variable fin_freq is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
-
- 30 Mar, 2020 31 commits
-
-
Paul Cercueil authored
The TCU channels 0 and 1 were previously reserved for system tasks, and thus unavailable for PWM. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Tested-by:
Mathieu Malaterre <malat@debian.org> Tested-by:
Artur Rojek <contact@artur-rojek.eu> Signed-off-by:
-
Paul Cercueil authored
The TCU registers are shared between a handful of drivers, accessing them through the same regmap. While this driver is devicetree-compatible, it is never (as of now) probed from devicetree, so this change does not introduce a ABI problem with current devicetree files. Signed-off-by:
-
Paul Cercueil authored
The previous algorithm hardcoded details about how the TCU clocks work. The new algorithm will use clk_round_rate to find the perfect clock rate for the PWM channel. This code relies on the fact that clk_round_rate() will always round down, which is not a valid assumption given by the clk API, but only happens to be true with the clk drivers used for Ingenic SoCs. Right now, there is no alternative as the clk API does not have a round-down function (and won't have one for a while), but if it ever comes to light, a round-down function should be used instead. Signed-off-by:
-
Paul Cercueil authored
The ingenic-timer "TCU" driver provides us with clocks, that can be (un)gated, reparented or reclocked from devicetree, instead of having these settings hardcoded in this driver. The new code now uses a clk pointer per PWM (instead of a clk per pwm-chip before). So the pointer is stored in per-pwm data now. The calls to arch-specific timer code is replaced with standard clock API calls to start and stop each channel's clock. While this driver is devicetree-compatible, it is never (as of now) probed from devicetree, so this change does not introduce a ABI problem with current devicetree files. Signed-off-by:
-
Pascal Roeleven authored
'needs_delay' does now always evaluate to true, so remove all occurrences. Signed-off-by:
Pascal Roeleven <dev@pascalroeleven.nl> Signed-off-by:
-
Lokesh Vutla authored
Implement .apply callback and drop the legacy callbacks(enable, disable, config, set_polarity). In .apply() check for the current hardware status before changing the PWM configuration. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Lokesh Vutla authored
Only the Timer control register(TCLR) cannot be updated when the timer is running. Registers like Counter register (TCRR), loader register (TLDR) and match register (TMAR) can be updated while the counter is running. Since TCLR is not updated in pwm_omap_dmtimer_config(), do not stop the timer for period/duty_cycle update. Tested-by:
-
Lokesh Vutla authored
To configure DM timer in PWM mode the following needs to be set in OMAP_TIMER_CTRL_REG using set_pwm callback: - Set toggle mode on PORTIMERPWM output pin - Set trigger on overflow and match on PORTIMERPWM output pin. - Set auto reload This is a one time configuration and needs to be set before the start of the DM timer. But the current driver tries to set the same configuration for every period/duty cycle update, which is not needed. So move the PWM setup before enabling timer and do not update it in pwm_omap_dmtimer_config(). Tested-by:
-
Lokesh Vutla authored
Update the description with a brief about how PWM is generated using OMAP DM timer and add limitations for the PWM generations. Also add a link to the reference manual. Suggested-by:
-
Lokesh Vutla authored
pwm_omap_dmtimer.h is used only: - to typedef struct omap_dm_timer to pwm_omap_dmtimer - for macro PWM_OMAP_DMTIMER_TRIGGER_OVERFLOW_AND_COMPARE Rest of the file is pretty mush unsed. So reuse omap_dm_timer and OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE in pwm-omap-dmtimer.c and delete the header file. Acked-by:
-
Geert Uytterhoeven authored
During device probe, the message TPU PWM -1 registered is printed. While the "-1" looks suspicious, it is perfectly normal for a device instantiated from DT. Remove the message, as there are no non-DT users left, and other drivers don't print such messages either. Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
-
Geert Uytterhoeven authored
Runtime PM should be enabled before calling pwmchip_add(), as PWM users can appear immediately after the PWM chip has been added. Likewise, Runtime PM should always be disabled after the removal of the PWM chip, even if the latter failed. Fixes: 99b82abb ("pwm: Add Renesas TPU PWM driver") Signed-off-by:
-
Geert Uytterhoeven authored
Runtime PM should be enabled before calling pwmchip_add(), as PWM users can appear immediately after the PWM chip has been added. Likewise, Runtime PM should be disabled after the removal of the PWM chip. Fixes: ed6c1476 ("pwm: Add support for R-Car PWM Timer") Signed-off-by:
-
Geert Uytterhoeven authored
All R-Car Gen2 SoCs have a Renesas Timer Pulse Unit. Document support for the missing variants. Signed-off-by:
-
Krzysztof Kozlowski authored
Fix indentation of return block. Smatch warning: drivers/pwm/pwm-meson.c:139 meson_pwm_request() warn: inconsistent indenting Reported-by:kbuild test robot <lkp@intel.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Fixes: 211ed630 ("pwm: Add support for Meson PWM Controller") Signed-off-by:
-
Rishi Gupta authored
GPIO core recently added macro to uniformly specify direction of a GPIO line, so use it. Signed-off-by:
Rishi Gupta <gupt21@gmail.com> Acked-by:
-
Rishi Gupta authored
The __maybe_unused attribute is preferred over CONFIG_PM to prevent potential build time issues. This commit replaces CONFIG_PM with this attribute. Signed-off-by:
-
Sandipan Patra authored
Tegra194 has multiple PWM controllers with each having only one output. Also the maxmimum frequency is higher than earlier SoCs. Add support for Tegra194 and specify the number of PWM outputs and maximum supported frequency using device tree match data. Signed-off-by:
Sandipan Patra <spatra@nvidia.com> Acked-by:
Laxman Dewangan <ldewangan@nvidia.com> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Some of the PWM drivers can be compile tested to increase build coverage. The Meson PWM driver requires COMMON_CLK dependency. Signed-off-by:
-
Matthias Schiffer authored
duty_cycle was only set, never read. Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by:
-
Anson Huang authored
There is nothing in use from of_address.h, remove it. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Acked-by:
-
Anson Huang authored
There is nothing in use from of_device.h, remove it. Signed-off-by:
-
Anson Huang authored
There is nothing in use from log2.h/of_address.h, remove them. Signed-off-by:
-
Uwe Kleine-König authored
There are some expectations which the callbacks provided by lowlevel drivers should fulfill. Implement checks that help driver authors to get these semantics right. As these have some overhead the checks can be disabled using a Kconfig setting. Signed-off-by:
-
Uwe Kleine-König authored
Up to now the .probe() function didn't enable clocks and relied on the core to call the .get_state() callback to have the clock running. The latter enabled the needed clocks and kept them running if the PWM wass enabled. This only works correctly if the .get_state() callback is called exactly once and this single call happens before unused clocks are disabled by the clk core. The former wasn't true for a short period while commit 01ccf903 ("pwm: Let pwm_get_state() return the last implemented state") applied and not reverted yet and might become wrong in the future. The latter isn't true any more since commit cfc4c189 ("pwm: Read initial hardware state at request time") which results in a running PWM being stopped at boot time if for example the consumer lives in a kernel module that is only loaded after the clk core disabled unused clocks. So ensure .probe() is left with the clocks on if the PWM is running and .get_state() disables everything it enabled. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback is not supposed to modify hardware state. This is in the responsibility of the PWM consumer. After the PWM was disabled the clocks are off (apart from a bug that is fixed in the next patch), so unbinding the driver either stops the PWM (which it should not) or disables already disabled clocks yielding warnings from the clk core. So just drop the call to disable the clocks. (Which BTW was also in the wrong order because the call makes the PWM unfunctional and so should have come only after pwmchip_remove()). Fixes: 9f4c8f96 ("pwm: imx: Add ipg clock operation") Signed-off-by:
-
Uwe Kleine-König authored
pwm_imx27_clk_prepare_enable() took a pointer to a struct pwm_chip just to convert it to a struct pwm_imx27_chip pointer while all callers already have the latter. Ditto for pwm_imx27_clk_disable_unprepare(). Signed-off-by:
-
Uwe Kleine-König authored
pwm_imx27_apply() enables the clocks if the previous PWM state was disabled. Given that the clocks are supposed to be left on iff the PWM is running, the decision to disable the clocks at the end of the function must not depend on the previous state. Without this fix the enable count of the two affected clocks increases by one whenever ->apply() changes from one disabled state to another. Fixes: bd88d319 ("pwm: imx27: Unconditionally write state to hardware") Signed-off-by:
-
Florian Fainelli authored
The newer 2711 and 7211 chips have two PWM controllers and failure to dynamically allocate the PWM base would prevent the second PWM controller instance being probed for succeeding with an -EEXIST error from alloc_pwms(). Fixes: e5a06dc5 ("pwm: Add BCM2835 PWM driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by:
-
Dafna Hirschfeld authored
Convert the binding file google,cros-ec-pwm.txt to YAML format. This was tested and verified on ARM64 with: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by:
-
Thierry Reding authored
Merge branch 'timers/drivers/timer-ti-dm' of https://git.linaro.org/people/dlezcano/linux into for-next
-
- 16 Mar, 2020 6 commits
-
-
Lokesh Vutla authored
dm timer ops set_load() api allows to configure the load value and to set the auto reload feature. But auto reload feature is independent of load value and should be part of configuring pwm. This way pwm can be disabled by disabling auto reload feature using set_pwm() so that the current pwm cycle will be completed. Else pwm disabling causes the cycle to be stopped abruptly. Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200305082715.15861-7-lokeshvutla@ti.com
-
Lokesh Vutla authored
omap_dm_timer_ops provide support to configure the pwm but there is no support to get the current status. For configuring pwm it is advised to check the current hw status instead of relying on pwm framework. So implement a new timer ops to get the current status of pwm. Signed-off-by:
-
Lokesh Vutla authored
Write to trigger register(OMAP_TIMER_TRIGGER_REG) will load the value in Load register(OMAP_TIMER_LOAD_REG) into Counter register (OMAP_TIMER_COUNTER_REG). omap_dm_timer_set_load() writes into trigger register every time load register is updated. When timer is configured in pwm mode, this causes disruption in current pwm cycle, which is not expected especially when pwm is used as PPS signal for synchronized PTP clocks. So do not write into trigger register on updating the period. Tested-by:
-
Lokesh Vutla authored
omap_dm_timer_enable() restores the entire context(including counter) based on 2 conditions: - If get_context_loss_count is populated and context is lost. - If get_context_loss_count is not populated update unconditionally. Case2 has a side effect of updating the counter register even though context is not lost. When timer is configured in pwm mode, this is causing undesired behaviour in the pwm period. Instead of using get_context_loss_count call back, implement cpu_pm notifier with context save and restore support. And delete the get_context_loss_count callback all together. Suggested-by:
-
Tony Lindgren authored
Let's add runtime_suspend and resume functions and atomic enabled flag. This way we can use these when converting to use cpuidle for saving and restoring device context. And we need to maintain the driver state in the driver as documented in "9. Autosuspend, or automatically-delayed suspends" in the Documentation/power/runtime_pm.rst document related to using driver private lock and races with runtime_suspend(). Signed-off-by:
-
Lokesh Vutla authored
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
