| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
To not trigger the warnings provided by CONFIG_PWM_DEBUG
- use up-rounding in .get_state()
- don't divide by the result of a division
- don't use the rounded counter value for the period length to calculate
the counter value for the duty cycle
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The way state->enabled is computed is rather convoluted and hard to
read - both branches of the if() actually do the exact same thing. So
remove the if(), and further simplify "<boolean condition> ? true :
false" to "<boolean condition>".
Signed-off-by: Rasmus Villemoes <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Even in failed case of pm_runtime_get_sync(), the usage_count is
incremented. In order to keep the usage_count with correct value call
appropriate pm_runtime_put().
Signed-off-by: Navid Emamdoost <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Added support for dynamic clock freq configuration in PWM kernel driver.
Earlier the PWM driver used to cache boot time clock rate by PWM clock
parent during probe. Hence dynamically changing PWM frequency was not
possible for all the possible ranges. With this change, dynamic
calculation is enabled and it is able to set the requested period from
sysfs knob provided the value is supported by clock source.
Changes mainly have 2 parts:
- Tegra186 and later chips [1]
- Tegra210 and prior chips [2]
For [1] - Changes implemented to set pwm period dynamically and also
checks added to allow only if requested period(ns) is below or
equals to higher range.
For [2] - Only checks if the requested period(ns) is below or equals to
higher range defined by max clock limit. The limitation in
Tegra210 or prior chips are due to the reason of having only
one PWM controller supporting multiple channels. But later
chips have multiple PWM controller instances each having
single channel support.
Signed-off-by: Sandipan Patra <[email protected]>
Reviewed-by: Jon Hunter <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The PWM hardware in the JZ4725B works the same as in the JZ4740, but has
only six channels available.
Signed-off-by: Paul Cercueil <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The PWM in Ingenic SoCs starts in inactive state until the internal
timer reaches the duty value, then becomes active until the timer
reaches the period value. In theory, we should then use (period - duty)
as the real duty value, as a high duty value would otherwise result in
the PWM pin being inactive most of the time.
This is the reason why the duty value was inverted in the driver until
now, but it still had the problem that it would not start with the
active part.
To address this remaining issue, the common trick is to invert the
duty, and invert the polarity when the PWM is enabled.
Since the duty was already inverted, and we invert it again, we now
program the hardware for the requested duty, and simply invert the
polarity when the PWM is enabled.
Signed-off-by: Paul Cercueil <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Calculating the hardware value for the duty from the hardware value of
the period resulted in a precision loss versus calculating it from the
clock rate directly.
(Also remove a cast that doesn't really need to be here)
Fixes: f6b8a5700057 ("pwm: Add Ingenic JZ4740 support")
Cc: <[email protected]>
Suggested-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Paul Cercueil <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Depending on MACH_INGENIC prevent us from creating a generic kernel that
works on more than one MIPS board. Instead, we just depend on MIPS being
set.
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Paul Cercueil <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Before commit cfc4c189bc70 ("pwm: Read initial hardware state at request
time"), a driver's get_state callback would get called once per PWM from
pwmchip_add().
pwm-lpss' runtime-pm code was relying on this, getting a runtime-pm ref for
PWMs which are enabled at probe time from within its get_state callback,
before enabling runtime-pm.
The change to calling get_state at request time causes a number of
problems:
1. PWMs enabled at probe time may get runtime suspended before they are
requested, causing e.g. a LCD backlight controlled by the PWM to turn off.
2. When the request happens when the PWM has been runtime suspended, the
ctrl register will read all 1 / 0xffffffff, causing get_state to store
bogus values in the pwm_state.
3. get_state was using an async pm_runtime_get() call, because it assumed
that runtime-pm has not been enabled yet. If shortly after the request an
apply call is made, then the pwm_lpss_is_updating() check may trigger
because the resume triggered by the pm_runtime_get() call is not complete
yet, so the ctrl register still reads all 1 / 0xffffffff.
This commit fixes these issues by moving the initial pm_runtime_get() call
for PWMs which are enabled at probe time to the pwm_lpss_probe() function;
and by making get_state take a runtime-pm ref before reading the ctrl reg.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1828927
Fixes: cfc4c189bc70 ("pwm: Read initial hardware state at request time")
Cc: [email protected]
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Allwinner A64 is capable of a direct clock output on PWM (see A64 User
Manual chapter 3.10). Add support for this in the sun4i PWM driver.
Signed-off-by: Peter Vasil <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
This patch adds support for the Azoteq IQS620A, capable of generating
a 1-kHz PWM output with duty cycle between ~0.4% and 100% (inclusive).
Signed-off-by: Jeff LaBundy <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'.
Fixes: 3ad1f3a33286 ("pwm: Implement some checks for lowlevel drivers")
Signed-off-by: Christophe JAILLET <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 e926b12c611c ("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 <[email protected]>
Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()")
Cc: Mika Westerberg <[email protected]>
Cc: Uwe Kleine-König <[email protected]>
Cc: YueHaibing <[email protected]>
Link: https://lkml.org/lkml/2019/5/31/963
Signed-off-by: Sven Van Asbroeck <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
[cg: Tested on an i.MX6Q board with two NXP PCA9685 chips]
Tested-by: Clemens Gruber <[email protected]>
Reviewed-by: Sven Van Asbroeck <[email protected]> # cg's rebase
Link: https://lore.kernel.org/lkml/20200330160238.GD2817345@ulmo/
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jason Yan <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The TCU channels 0 and 1 were previously reserved for system tasks, and
thus unavailable for PWM.
Signed-off-by: Paul Cercueil <[email protected]>
Tested-by: Mathieu Malaterre <[email protected]>
Tested-by: Artur Rojek <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Tested-by: Mathieu Malaterre <[email protected]>
Tested-by: Artur Rojek <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Tested-by: Mathieu Malaterre <[email protected]>
Tested-by: Artur Rojek <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: Paul Cercueil <[email protected]>
Tested-by: Mathieu Malaterre <[email protected]>
Tested-by: Artur Rojek <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
'needs_delay' does now always evaluate to true, so remove all
occurrences.
Signed-off-by: Pascal Roeleven <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Tested-by: Tony Lindgren <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: Tony Lindgren <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: Tony Lindgren <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: Uwe Kleine-König <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: Tony Lindgren <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: 99b82abb0a35b073 ("pwm: Add Renesas TPU PWM driver")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: ed6c1476bf7f16d5 ("pwm: Add support for R-Car PWM Timer")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Fix indentation of return block. Smatch warning:
drivers/pwm/pwm-meson.c:139 meson_pwm_request() warn: inconsistent indenting
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Fixes: 211ed630753d ("pwm: Add support for Meson PWM Controller")
Signed-off-by: Thierry Reding <[email protected]>
|
|
GPIO core recently added macro to uniformly specify direction of a GPIO
line, so use it.
Signed-off-by: Rishi Gupta <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: Rishi Gupta <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Acked-by: Laxman Dewangan <[email protected]>
Acked-by: Rob Herring <[email protected]>
Acked-by: Jon Hunter <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
Some of the PWM drivers can be compile tested to increase build
coverage.
The Meson PWM driver requires COMMON_CLK dependency.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Florian Fainelli <[email protected]> # For Broadcoam
Reviewed-by: Martin Blumenstingl <[email protected]> # For Meson
Acked-by: Claudiu Beznea <[email protected]> # For Atmel
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
duty_cycle was only set, never read.
Signed-off-by: Matthias Schiffer <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
There is nothing in use from of_address.h, remove it.
Signed-off-by: Anson Huang <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
There is nothing in use from of_device.h, remove it.
Signed-off-by: Anson Huang <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
There is nothing in use from log2.h/of_address.h, remove them.
Signed-off-by: Anson Huang <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 01ccf903edd6
("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 cfc4c189bc70 ("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 <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: 9f4c8f9607c3 ("pwm: imx: Add ipg clock operation")
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: bd88d319abe9 ("pwm: imx27: Unconditionally write state to hardware")
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: e5a06dc5ac1f ("pwm: Add BCM2835 PWM driver")
Signed-off-by: Florian Fainelli <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Nicolas Saenz Julienne <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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: Lokesh Vutla <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/pwm/pwm-pca9685.c: In function ‘pca9685_pwm_gpio_free’:
drivers/pwm/pwm-pca9685.c:162:21: warning: variable ‘pwm’ set but not used [-Wunused-but-set-variable]
It is never used, and so can be removed. In that case, hold and release
the lock 'pca->lock' can be removed since nothing will be done between
them.
Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()")
Signed-off-by: yu kuai <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
GCC can't always determine that the duty, period and prescaler values
are initialized when returning from sun4i_pwm_calculate(), so help out a
little by initializing them to 0.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Don't use AOE (automatic output enable) by default. In case of break
events, PWM is automatically re-enabled on next PWM cycle otherwise.
Signed-off-by: Fabrice Gasnier <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The variable pval is only used in a single block in the function
sun4i_pwm_calculate(). So declare it in a more local scope to simplify
the function for humans and compilers.
While at it also simplify assignment to pval.
While the diffstat for this patch is negative for this patch I still
thing the advantage of having a narrower scope is beneficial.
In my compiler / .config setup (gcc 8.2.1, arm/imx_v6_v7_defconfig +
COMPILE_TEST + PWM_SUN4I) this change doesn't result in any binary
changes.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
BCM7211 is supported using ARCH_BRCMSTB and uses this PWM controller
driver, make it possible to build it.
Signed-off-by: Florian Fainelli <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
For defer probe error, no need to output error message which
will cause confusion.
Signed-off-by: Anson Huang <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|