commit 7170d3beaf upstream.
Some PWM devices require sleeping, for example if the pwm device is
connected over I2C. However, many PWM devices could be used from atomic
context, e.g. memory mapped PWM. This is useful for, for example, the
pwm-ir-tx driver which requires precise timing. Sleeping causes havoc
with the generated IR signal.
Since not all PWM devices can support atomic context, we also add a
pwm_might_sleep() function to check if is not supported.
Signed-off-by: Sean Young <sean@mess.org>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
[ Upstream commit c748a6d77c ]
In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:
int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
int pwm_apply_atomic(struct pwm *, struct pwm_state *);
This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Stable-dep-of: 974afccd37 ("leds: pwm: Disable PWM when going to suspend")
Signed-off-by: Sasha Levin <sashal@kernel.org>
pwmchip_add() calls of_pwmchip_add() only after adding the chip to
pwm_chips and releasing pwm_lock. So the proper order in
pwmchip_remove() is to call of_pwmchip_remove() before taking the mutex
and removing the chip from pwm_chips. This way pwmchip_remove() releases
the resources in reverse order compared to pwmchip_add() requesting
them.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
core.c doens't use any of the symbols provided by linux/radix-tree.h
and compiles just fine without this include. So drop the #include.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
pwmchip_remove() returns void since some time but the documentation still
mentions the situations where it used to return an error code. Just remove
this old and now wrong text.
Fixes: 8083f58d08 ("pwm: Make pwmchip_remove() return void")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Most variables of type struct pwm_chip * are named "chip", there are
only three outliers called "pc". Change these three to "chip", too, for
consistency.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The radix tree's only use was to map PWM channels to the global number
space. With that number space gone, the radix tree is now unused, so it
can simply be removed.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since commit 5a7fbe452a ("backlight: pwm_bl: Drop support for legacy PWM
probing") the last user of pwm_request() and pwm_free() is gone. So remove
these functions that were deprecated over 10 years ago in commit
8138d2ddbc ("pwm: Add table-based lookup for static mappings").
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[thierry.reding@gmail.com: clean up a bit after removal]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Pull pwm updates from Thierry Reding:
"The Rockchip and Mediatek drivers gain support for more chips and the
LPSS driver undergoes some refactoring and receives some improvements.
Other than that there are various cleanups of the core"
* tag 'pwm/for-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: sysfs: Replace sprintf() with sysfs_emit()
pwm: core: Replace custom implementation of device_match_fwnode()
pwm: lpss: Add a comment to the bypass field
pwm: lpss: Make use of bits.h macros for all masks
pwm: lpss: Use DEFINE_RUNTIME_DEV_PM_OPS() and pm_ptr() macros
pwm: lpss: Use device_get_match_data() to get device data
pwm: lpss: Move resource mapping to the glue drivers
pwm: lpss: Move exported symbols to PWM_LPSS namespace
pwm: lpss: Deduplicate board info data structures
dt-bindings: pwm: Add compatible for Mediatek MT8188
dt-bindings: pwm: rockchip: Add rockchip,rk3128-pwm
dt-bindings: pwm: rockchip: Add description for rk3588
pwm: sysfs: Switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()
pwm: rockchip: Convert to use dev_err_probe()
Replace custom implementation of the device_match_fwnode(). This hides
the implementation details and makes future changes easier.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There are no drivers left providing the legacy callbacks. So drop
support for these.
If this commit breaks your out-of-tree pwm driver, look at e.g. commit
ec00cd5e63 ("pwm: renesas-tpu: Implement .apply() callback") for an
example of the needed conversion for your driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Pull pwm updates from Thierry Reding:
"This contains a number of nice cleanups and improvements for the core
and various drivers, as well as a minor tweak to the json-schema
device tree bindings"
* tag 'pwm/for-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
dt-bindings: pwm: Avoid selecting schema on node name match
pwm: img: Use only a single idiom to get a runtime PM reference
pwm: vt8500: Implement .apply() callback
pwm: img: Implement .apply() callback
pwm: twl: Implement .apply() callback
pwm: Restore initial state if a legacy callback fails
pwm: Prevent a glitch for legacy drivers
pwm: Move legacy driver handling into a dedicated function
It is not entirely accurate to go back to the initial state after e.g.
.enable() failed, as .config() still modified the hardware, but this same
inconsistency exists for drivers that implement .apply().
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
If a running PWM is reconfigured to disabled calling the ->config()
callback before disabling the hardware might result in a glitch where
the (maybe) new period and duty_cycle are visible on the output before
disabling the hardware.
So handle disabling before calling ->config(). Also exit early in this case
which is possible because period and duty_cycle don't matter for disabled PWMs.
In return however ->config has to be called even if state->period ==
pwm->state.period && state->duty_cycle != pwm->state.duty_cycle because setting
these might have been skipped in the previous call.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is no change in behaviour, only some code is moved from
pwm_apply_state to a separate function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
At least some implementations sleep. So mark pwm_apply_state() with a
might_sleep() to make callers aware. In the worst case this uncovers a
valid atomic user, then we revert this patch and at least gained some more
knowledge and then can work on a concept similar to
gpio_get_value/gpio_get_value_cansleep.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since some time pwmchip_remove() always returns 0 so the return value
isn't usefull. Now that all callers are converted to ignore its value
the function can be changed to return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The pointer pwm 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Historically we have two different approaches on how to check type of fwnode.
Unify them using the latest and greatest fwnode related APIs.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
When we traverse the list of the registered PWM controllers,
use fwnode to match. This will help for further cleanup.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the PWM core uses device links (commit b2c200e3f2 ("pwm: Add
consumer device link")) each consumer driver that requested the PWMs is
already gone. If they called pwm_put() (as they should) the
PWMF_REQUESTED bit is not set. If they failed (which is a bug) the
PWMF_REQUESTED bit might still be set, but the driver that cared is
gone, so nothing bad happens if the PWM chip goes away even if the
PWMF_REQUESTED is still present.
So the check can be dropped.
With this change pwmchip_remove() returns always 0, so lowlevel drivers
don't need to check the return code any more. Once all drivers dropped
this check this function can be changed to return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
If usage_power is set, the PWM driver is only required to maintain
the power output but has more freedom regarding signal form.
If supported, the signal can be optimized, for example to
improve EMI by phase shifting individual channels.
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This allows to simplify all drivers that use three pwm-cells.
The only ugly side effect is that if a driver specified of_pwm_n_cells = 2
it suddenly supports device trees that use #pwm-cells = <3>. This however
isn't a bad thing because the driver doesn't need explicit support for
three cells as the core handles all the details. Also there is no such
in-tree driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since the previous commit the latter function can do everything that the
former does. So simplify accordingly.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The two functions of_pwm_simple_xlate() and of_pwm_xlate_with_flags()
are quite similar. of_pwm_simple_xlate() only supports two-cell PWM
specifiers while of_pwm_xlate_with_flags() only supports PWM specifiers
with 3 or more cells. The latter can easily be modified to behave
identically to of_pwm_simple_xlate() for two-cell PWM specifiers. This
is implemented here and allows to drop of_pwm_simple_xlate() in the next
commit.
There is a small detail that is different now in the two-cell specifier
case in of_pwm_xlate_with_flags(): pwm->args.polarity is unconditionally
initialized to PWM_POLARITY_NORMAL in the latter. I didn't find a case
where this matters and doing that explicitly is the more robust
approach.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[thierry.reding@gmail.com: fix up checkpatch warnings]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
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>
Since commit 2b1c1a5d51 ("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>
Since commit 5e5da1e9fb ("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>
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>
Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.
Also use the right format specifiers in debug prints in both core.c,
pwm-stm32-lp.c as well as video/fbdev/ssd1307fb.c.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
