| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
The normal implementations of these functions make use of mutexes. To
make it obvious that these functions might sleep also add annotations to
the dummy implementations in the !CONFIG_PWM case.
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>
|
|
There are no users and seems no will come of the devm_pwm_put().
Remove the function.
While at it, slightly update documentation.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
This potentially simplifies low-level PWM drivers.
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>
|
|
Given that lowlevel drivers usually cannot implement exactly what a
consumer requests with pwm_apply_state() there is some rounding
involved.
pwm_get_state() returns the setting that was requested most recently by
the consumer (opposed to what was actually implemented in hardware in
reply to the last request). Clarify this in the function kerneldoc.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
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>
|
|
This is only defined with CONFIG_PWM unset and was introduced together
with pwmchip_add_with_polarity() (which is only defined with CONFIG_PWM
enabled). I guess the series that introduced pwmchip_add_with_polarity()
had a different concept in earlier revisions and the !CONFIG_PWM part
was just not updated accordingly.
Given that there is no implementation for pwmchip_add_with_polarity()
without CONFIG_PWM, just drop pwmchip_add_inversed() instead of renaming
it to pwmchip_add_with_polarity().
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
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>
|
|
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Commit 71523d1812ac (pwm: Ensure pwm_apply_state() doesn't modify the
state argument) updated the kernel-doc for pwm_apply_state(), but not
for the ->apply callback in the pwm_ops struct.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
It is surprising for a PWM consumer when the variable holding the
requested state is modified by pwm_apply_state(). Consider for example a
driver doing:
#define PERIOD 5000000
#define DUTY_LITTLE 10
...
struct pwm_state state = {
.period = PERIOD,
.duty_cycle = DUTY_LITTLE,
.polarity = PWM_POLARITY_NORMAL,
.enabled = true,
};
pwm_apply_state(mypwm, &state);
...
state.duty_cycle = PERIOD / 2;
pwm_apply_state(mypwm, &state);
For sure the second call to pwm_apply_state() should still have
state.period = PERIOD and not something the hardware driver chose for a
reason that doesn't necessarily apply to the second call.
So declare the state argument as a pointer to a const type and adapt all
drivers' .apply callbacks.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
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 ()
{ <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}}
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 <nikolaus.voss@loewensteinmedical.de>
[thierry.reding@gmail.com: fix build failures for !ACPI]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Add a device link between the PWM consumer and the PWM provider. This
enforces the PWM user to get suspended before the PWM provider. It
allows proper synchronization of suspend/resume sequences: the PWM user
is responsible for properly stopping PWM, before the provider gets
suspended: see [1]. Add the device link in:
- of_pwm_get()
- pwm_get()
- devm_*pwm_get() variants
as it requires a reference to the device for the PWM consumer.
[1] https://lkml.org/lkml/2019/2/5/770
Suggested-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
This patch fixes deadlock warning if removing PWM device
when CONFIG_PROVE_LOCKING is enabled.
This issue can be reproceduced by the following steps on
the R-Car H3 Salvator-X board if the backlight is disabled:
# cd /sys/class/pwm/pwmchip0
# echo 0 > export
# ls
device export npwm power pwm0 subsystem uevent unexport
# cd device/driver
# ls
bind e6e31000.pwm uevent unbind
# echo e6e31000.pwm > unbind
[ 87.659974] ======================================================
[ 87.666149] WARNING: possible circular locking dependency detected
[ 87.672327] 5.0.0 #7 Not tainted
[ 87.675549] ------------------------------------------------------
[ 87.681723] bash/2986 is trying to acquire lock:
[ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
[ 87.694528]
[ 87.694528] but task is already holding lock:
[ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
[ 87.707405]
[ 87.707405] which lock already depends on the new lock.
[ 87.707405]
[ 87.715574]
[ 87.715574] the existing dependency chain (in reverse order) is:
[ 87.723048]
[ 87.723048] -> #1 (pwm_lock){+.+.}:
[ 87.728017] __mutex_lock+0x70/0x7e4
[ 87.732108] mutex_lock_nested+0x1c/0x24
[ 87.736547] pwm_request_from_chip.part.6+0x34/0x74
[ 87.741940] pwm_request_from_chip+0x20/0x40
[ 87.746725] export_store+0x6c/0x1f4
[ 87.750820] dev_attr_store+0x18/0x28
[ 87.754998] sysfs_kf_write+0x54/0x64
[ 87.759175] kernfs_fop_write+0xe4/0x1e8
[ 87.763615] __vfs_write+0x40/0x184
[ 87.767619] vfs_write+0xa8/0x19c
[ 87.771448] ksys_write+0x58/0xbc
[ 87.775278] __arm64_sys_write+0x18/0x20
[ 87.779721] el0_svc_common+0xd0/0x124
[ 87.783986] el0_svc_compat_handler+0x1c/0x24
[ 87.788858] el0_svc_compat+0x8/0x18
[ 87.792947]
[ 87.792947] -> #0 (kn->count#58){++++}:
[ 87.798260] lock_acquire+0xc4/0x22c
[ 87.802353] __kernfs_remove+0x258/0x2c4
[ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0
[ 87.811836] remove_files.isra.1+0x38/0x78
[ 87.816447] sysfs_remove_group+0x48/0x98
[ 87.820971] sysfs_remove_groups+0x34/0x4c
[ 87.825583] device_remove_attrs+0x6c/0x7c
[ 87.830197] device_del+0x11c/0x33c
[ 87.834201] device_unregister+0x14/0x2c
[ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c
[ 87.843509] pwmchip_remove+0xf4/0x13c
[ 87.847773] rcar_pwm_remove+0x28/0x34
[ 87.852039] platform_drv_remove+0x24/0x64
[ 87.856651] device_release_driver_internal+0x18c/0x21c
[ 87.862391] device_release_driver+0x14/0x1c
[ 87.867175] unbind_store+0xe0/0x124
[ 87.871265] drv_attr_store+0x20/0x30
[ 87.875442] sysfs_kf_write+0x54/0x64
[ 87.879618] kernfs_fop_write+0xe4/0x1e8
[ 87.884055] __vfs_write+0x40/0x184
[ 87.888057] vfs_write+0xa8/0x19c
[ 87.891887] ksys_write+0x58/0xbc
[ 87.895716] __arm64_sys_write+0x18/0x20
[ 87.900154] el0_svc_common+0xd0/0x124
[ 87.904417] el0_svc_compat_handler+0x1c/0x24
[ 87.909289] el0_svc_compat+0x8/0x18
[ 87.913378]
[ 87.913378] other info that might help us debug this:
[ 87.913378]
[ 87.921374] Possible unsafe locking scenario:
[ 87.921374]
[ 87.927286] CPU0 CPU1
[ 87.931808] ---- ----
[ 87.936331] lock(pwm_lock);
[ 87.939293] lock(kn->count#58);
[ 87.945120] lock(pwm_lock);
[ 87.950599] lock(kn->count#58);
[ 87.953908]
[ 87.953908] *** DEADLOCK ***
[ 87.953908]
[ 87.959821] 4 locks held by bash/2986:
[ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c
[ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8
[ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c
[ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
[ 87.995481]
[ 87.995481] stack backtrace:
[ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7
[ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT)
[ 88.012791] Call trace:
[ 88.015235] dump_backtrace+0x0/0x190
[ 88.018891] show_stack+0x14/0x1c
[ 88.022204] dump_stack+0xb0/0xec
[ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0
[ 88.030385] __lock_acquire+0x1318/0x1864
[ 88.034388] lock_acquire+0xc4/0x22c
[ 88.037958] __kernfs_remove+0x258/0x2c4
[ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0
[ 88.046398] remove_files.isra.1+0x38/0x78
[ 88.050487] sysfs_remove_group+0x48/0x98
[ 88.054490] sysfs_remove_groups+0x34/0x4c
[ 88.058580] device_remove_attrs+0x6c/0x7c
[ 88.062671] device_del+0x11c/0x33c
[ 88.066154] device_unregister+0x14/0x2c
[ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c
[ 88.074421] pwmchip_remove+0xf4/0x13c
[ 88.078163] rcar_pwm_remove+0x28/0x34
[ 88.081906] platform_drv_remove+0x24/0x64
[ 88.085996] device_release_driver_internal+0x18c/0x21c
[ 88.091215] device_release_driver+0x14/0x1c
[ 88.095478] unbind_store+0xe0/0x124
[ 88.099048] drv_attr_store+0x20/0x30
[ 88.102704] sysfs_kf_write+0x54/0x64
[ 88.106359] kernfs_fop_write+0xe4/0x1e8
[ 88.110275] __vfs_write+0x40/0x184
[ 88.113757] vfs_write+0xa8/0x19c
[ 88.117065] ksys_write+0x58/0xbc
[ 88.120374] __arm64_sys_write+0x18/0x20
[ 88.124291] el0_svc_common+0xd0/0x124
[ 88.128034] el0_svc_compat_handler+0x1c/0x24
[ 88.132384] el0_svc_compat+0x8/0x18
The sysfs unexport in pwmchip_remove() is completely asymmetric
to what we do in pwmchip_add_with_polarity() and commit 0733424c9ba9
("pwm: Unexport children before chip removal") is a strong indication
that this was wrong to begin with. We should just move
pwmchip_sysfs_unexport() where it belongs, which is right after
pwmchip_sysfs_unexport_children(). In that case, we do not need
separate functions anymore either.
We also really want to remove sysfs irrespective of whether or not
the chip will be removed as a result of pwmchip_remove(). We can only
assume that the driver will be gone after that, so we shouldn't leave
any dangling sysfs files around.
This warning disappears if we move pwmchip_sysfs_unexport() to
the top of pwmchip_remove(), pwmchip_sysfs_unexport_children().
That way it is also outside of the pwm_lock section, which indeed
doesn't seem to be needed.
Moving the pwmchip_sysfs_export() call outside of that section also
seems fine and it'd be perfectly symmetric with pwmchip_remove() again.
So, this patch fixes them.
Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
[shimoda: revise the commit log and code]
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Hoan Nguyen An <na-hoan@jinso.co.jp>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
In pwm_ops there are a few callbacks that are not supposed to be used by
new drivers. Group them at the end of the structure and add a comment.
Similarily for struct pwm_chip group the members that drivers shouldn't
care about at the end and mark them as internal with another comment.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
This callback was introduced in commit 62099abf67a2 ("pwm: Add debugfs
interface") in 2012 and up to now there is not a single user. So drop
this unused code.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[thierry.reding@gmail.com: remove kerneldoc for ->dbg_show()]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
The API to configure a PWM using pwm_enable(), pwm_disable(),
pwm_config() and pwm_set_polarity() is superseeded by atomically setting
the parameters using pwm_apply_state(). To get forward with deprecating
the former set of functions use the opportunity that there is no current
user of pwm_set_polarity() and remove it.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add a module name string to the pwm_lookup struct and if specified try
to load the module using request_module() if pwmchip_find_by_name() is
unable to find the PWM chip.
This is a last resort to work around drivers that can't - and can't be
made to - deal with deferred probe.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[thierry.reding@gmail.com: rename new macro, reword commit message]
[thierry.reding@gmail.com: add comment explaining use-case]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
All PWM devices have been marked as "might sleep" since v4.5, there is
no longer a need to differentiate on a per-chip basis.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
The last user of this function has been removed, so it is no longer
needed.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.
Signed-off-by: David Hsu <davidhsu@google.com>
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
|
|
|
|
Commit 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic
updates") introduced this double blank line by mistake.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
The PWM framework expects PWM users to configure the duty cycle in nano-
seconds, but many users want to express the duty cycle relatively to the
period value (i.e. duty_cycle = 33% of the period).
Add the pwm_{get,set}_relative_duty_cycle() helpers to ease this kind of
conversion.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
The pwm_init_state() helper prepares a new state object containing the
current PWM state except for the polarity and period fields which are
set to the reference values (those in struct pwm_args).
This is particularly useful for PWM users who want to apply a new duty-
cycle expressed relatively to the reference period without changing the
enable state.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Commit 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic
updates"), implemented pwm_disable() as a wrapper around
pwm_apply_state(), and then, commit ef2bf4997f7d ("pwm: Improve args
checking in pwm_apply_state()") added missing checks on the ->period
value in pwm_apply_state() to ensure we were not passing inappropriate
values to the ->config() or ->apply() methods.
The conjunction of these 2 commits led to a case where pwm_disable()
was no longer succeeding, thus preventing the polarity setting done
in pwm_apply_args().
Set a valid period in pwm_apply_args() to ensure polarity setting
won't be rejected.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Suggested-by: Brian Norris <briannorris@chromium.org>
Fixes: 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic updates")
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Supply a PWM capture callback op in order to pass back information
obtained by running analysis on a PWM signal. This would normally (at
least during testing) be called from the sysfs routines with a view to
printing out PWM capture data which has been encoded into a string.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[thierry.reding@gmail.com: make capture data unsigned int for symmetry]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
It seems like in the process of refactoring pwm_config() to utilize the
newly-introduced pwm_apply_state() API, some args/bounds checking was
dropped.
In particular, I noted that we are now allowing invalid period
selections, e.g.:
# echo 1 > /sys/class/pwm/pwmchip0/export
# cat /sys/class/pwm/pwmchip0/pwm1/period
100
# echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
[... driver may or may not reject the value, or trigger some logic bug ...]
It's better to see:
# echo 1 > /sys/class/pwm/pwmchip0/export
# cat /sys/class/pwm/pwmchip0/pwm1/period
100
# echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
-bash: echo: write error: Invalid argument
This patch reintroduces some bounds checks in both pwm_config() (for its
signed parameters; we don't want to convert negative values into large
unsigned values) and in pwm_apply_state() (which fix the above described
behavior, as well as other potential API misuses).
Fixes: 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic updates")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Add an ->apply() method to the pwm_ops struct to allow PWM drivers to
implement atomic updates. This method is preferred over the ->enable(),
->disable() and ->config() methods if available.
Add the pwm_apply_state() function to the PWM user API.
Note that the pwm_apply_state() does not guarantee the atomicity of the
update operation, it all depends on the availability and implementation
of the ->apply() method.
pwm_enable/disable/set_polarity/config() are now implemented as wrappers
around the pwm_apply_state() function.
pwm_adjust_config() is allowing smooth handover between the bootloader
and the kernel. This function tries to adapt the current PWM state to
the PWM arguments coming from a PWM lookup table or a DT definition
without changing the duty_cycle/period proportion.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: fix a couple of typos]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Add a ->get_state() function to the pwm_ops struct to let PWM drivers
initialize the PWM state attached to a PWM device.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Prepare the transition to PWM atomic update by moving the enabled and
disabled state into the pwm_state struct. This way we can easily update
the whole PWM state by copying the new state in the ->state field.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
The PWM state, represented by its period, duty_cycle and polarity is
currently directly stored in the PWM device. Declare a pwm_state
structure embedding those field so that we can later use this struct
to atomically update all the PWM parameters at once.
All pwm_get_xxx() helpers are now implemented as wrappers around
pwm_get_state().
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Before the introduction of pwm_args, the core was resetting the PWM
period and polarity states to the reference values (those provided
through the DT, a PWM lookup table or hardcoded in the driver).
Now that all PWM users are correctly using pwm_args to configure their
PWM device, we can safely remove the pwm_apply_args() call in pwm_get()
and of_pwm_get().
We can also get rid of the pwm_set_period() call in pwm_apply_args(),
because PWM users are now directly using pargs->period instead of
pwm_get_period(). By doing that we avoid messing with the current PWM
period.
The only remaining bit in pwm_apply_args() is the initial polarity
setting, and it should go away when all PWM users have been patched to
use the atomic API (with this API the polarity will be set along with
other PWM arguments when configuring the PWM).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
PWM devices are not protected against concurrent accesses. The lock in
struct pwm_device might let PWM users think it is, but it's actually
only protecting the enabled state.
Removing this lock should be fine as long as all PWM users are aware
that accesses to the PWM device have to be serialized, which seems to be
the case for all of them except the sysfs interface. Patch the sysfs
code by adding a lock to the pwm_export struct and making sure it's
taken for all relevant accesses to the exported PWM device.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Currently the PWM core mixes the current PWM state with the per-platform
reference config (specified through the PWM lookup table, DT definition
or directly hardcoded in PWM drivers).
Create a struct pwm_args to store this reference configuration, so that
PWM users can differentiate between the current and reference
configurations.
Patch all places where pwm->args should be initialized. We keep the
pwm_set_polarity/period() calls until all PWM users are patched to use
pwm_args instead of pwm_get_period/polarity().
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: reword kerneldoc comments]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
The pwm_enable() function didn't clear the enabled bit if a call to the
driver's ->enable() callback returned an error. The result was that the
state of the PWM core was wrong. Clearing the bit when enable returns
an error ensures the state is properly set.
Tested-by: Jonathan Richardson <jonathar@broadcom.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jonathan Richardson <jonathar@broadcom.com>
[thierry.reding@gmail.com: add missing kerneldoc for the lock]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Clean up kerneldoc in preparation for including the PWM documentation in
DocBook.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Remove useless tabs used for padding in structure definitions as well as
some blank lines.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Some drivers are directly accessing the ->polarity field in pwm_device.
Add a helper to retrieve the current polarity so that we can easily move
this field elsewhere (required to support atomic update).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
The PWM argument is not modified in PWM property accessors, make it a
const argument so that the accessors can be used from sysfs.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Some PWM drivers are testing the PWMF_ENABLED flag. Create a helper
function to hide the logic behind enabled test. This will allow us to
smoothly move from the current approach to an atomic PWM update
approach.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Add a new function to register a PWM chip with channels that have their
initial polarity as specified by an additional parameter. This benefits
drivers of controllers that by default operate with inversed polarity
by removing the need to modify the polarity during initialization.
Signed-off-by: Tim Kryger <tim.kryger@gmail.com>
Signed-off-by: Jonathan Richardson <jonathar@broadcom.com>
[thierry.reding@gmail.com: export pwmchip_add_with_polarity()]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
In case some drivers are unloading, they can remove lookup tables which
they had registered during their load time to avoid redundant entries if
loaded again.
CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Now that PWM_LOOKUP is not used anymore, modify it to initialize all the
members of struct pwm_lookup.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Add period and polarity members to struct pwm_lookup so that platforms
using the lookup table can be treated the same way as those using the
device tree.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Before we had the PWM framework we used to have a barebone PWM api. The
HAVE_PWM Kconfig symbol used to be selected by the PWM drivers to specify
the PWM API is present in the kernel. Since the last legacy driver is gone
the HAVE_PWM symbol can go aswell.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-pwm@vger.kernel.orig
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
