summaryrefslogtreecommitdiff
path: root/include/linux/pwm.h
Commit message (Collapse)AuthorAgeFilesLines
* pwm: Make it explicit that pwm_apply_state() might sleepUwe Kleine-König2021-11-051-0/+4
| | | | | | | | | | | 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>
* pwm: Add might_sleep() annotations for !CONFIG_PWM API functionsUwe Kleine-König2021-11-051-0/+9
| | | | | | | | | 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>
* pwm: Make pwmchip_remove() return voidUwe Kleine-König2021-09-021-1/+1
| | | | | | | | | 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>
* pwm: core: Remove unused devm_pwm_put()Andy Shevchenko2021-06-301-5/+0
| | | | | | | | | | | 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>
* pwm: Add a device-managed function to add PWM chipsUwe Kleine-König2021-06-281-0/+3
| | | | | | | 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>
* pwm: core: Support new usage_power setting in PWM stateClemens Gruber2021-06-041-0/+7
| | | | | | | | | | | 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>
* pwm: Clarify which state pwm_get_state() returnsUwe Kleine-König2021-04-091-0/+5
| | | | | | | | | | | | | 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>
* pwm: Drop function pwmchip_add_with_polarity()Uwe Kleine-König2021-03-221-2/+0
| | | | | | | | | | | | 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>
* pwm: Remove unused function pwmchip_add_inversed()Uwe Kleine-König2020-12-171-5/+0
| | | | | | | | | | | | | | | | 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>
* pwm: Convert period and duty cycle to u64Guru Das Srinagesh2020-06-171-6/+6
| | | | | | | | | | | | | | | 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>
* pwm: Implement some checks for lowlevel driversUwe Kleine-König2020-03-301-1/+3
| | | | | | | | | | 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>
* pwm: Update comment on struct pwm_ops::applyRasmus Villemoes2019-10-211-4/+1
| | | | | | | | | | | 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>
* pwm: Ensure pwm_apply_state() doesn't modify the state argumentUwe Kleine-König2019-09-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pwm: Add support referencing PWMs from ACPINikolaus Voss2019-06-261-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pwm: Add consumer device linkFabrice Gasnier2019-06-251-2/+4
| | | | | | | | | | | | | | | | | | | 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>
* pwm: Fix deadlock warning when removing PWM devicePhong Hoang2019-03-201-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pwm: Rearrange structures to group members by purposeUwe Kleine-König2019-01-101-15/+18
| | | | | | | | | | | 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>
* pwm: Drop per-chip dbg_show callbackUwe Kleine-König2019-01-101-4/+0
| | | | | | | | | | 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>
* pwm: Drop legacy wrapper for changing polarityUwe Kleine-König2018-12-121-42/+0
| | | | | | | | | | | 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>
* License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman2017-11-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pwm: Try to load modules during pwm_get()Hans de Goede2017-01-301-8/+15
| | | | | | | | | | | | | | 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>
* pwm: Remove .can_sleep from struct pwm_chipThierry Reding2017-01-041-3/+0
| | | | | | | 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>
* pwm: Remove pwm_can_sleep()Thierry Reding2017-01-041-7/+0
| | | | | | | The last user of this function has been removed, so it is no longer needed. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
* pwm: Unexport children before chip removalDavid Hsu2016-09-051-0/+5
| | | | | | | | | | 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>
* Merge branch 'for-4.8/capture' into for-nextThierry Reding2016-07-251-0/+24
|\
| * pwm: Add PWM capture supportLee Jones2016-06-101-0/+24
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'for-4.8/core' into for-nextThierry Reding2016-07-251-1/+88
|\ \
| * | pwm: Remove gratuitous blank lineThierry Reding2016-07-081-1/+0
| | | | | | | | | | | | | | | | | | | | | 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>
| * | pwm: Add relative duty cycle manipulation helpersBoris Brezillon2016-07-081-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | pwm: Add a helper to prepare a new PWM stateBoris Brezillon2016-07-081-0/+33
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | pwm: Fix pwm_apply_args()Boris Brezillon2016-06-231-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | pwm: Improve args checking in pwm_apply_state()Brian Norris2016-06-101-0/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pwm: Add core infrastructure to allow atomic updatesBoris Brezillon2016-05-171-85/+184
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* pwm: Add hardware readout infrastructureBoris Brezillon2016-05-171-0/+28
| | | | | | | | 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>
* pwm: Move the enabled/disabled info into pwm_stateBoris Brezillon2016-05-171-3/+8
| | | | | | | | | 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>
* pwm: Introduce the pwm_state conceptBoris Brezillon2016-05-171-12/+42
| | | | | | | | | | | | | 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>
* pwm: Keep PWM state in sync with hardware stateBoris Brezillon2016-05-171-1/+0
| | | | | | | | | | | | | | | | | | | | | | | 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: Get rid of pwm->lockBoris BREZILLON2016-05-171-2/+0
| | | | | | | | | | | | | | | 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>
* pwm: Introduce the pwm_args conceptBoris Brezillon2016-05-031-0/+33
| | | | | | | | | | | | | | | | | | 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>
* pwm: Set enable state properly on failed call to enableJonathan Richardson2015-11-101-0/+3
| | | | | | | | | | | | | 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>
* pwm: Clean up kerneldocThierry Reding2015-08-171-0/+14
| | | | | | | Clean up kerneldoc in preparation for including the PWM documentation in DocBook. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
* pwm: Remove useless whitespaceThierry Reding2015-08-171-39/+32
| | | | | | | Remove useless tabs used for padding in structure definitions as well as some blank lines. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
* pwm: Add pwm_get_polarity() helper functionBoris Brezillon2015-07-201-0/+5
| | | | | | | | | 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>
* pwm: Constify PWM device where possibleBoris Brezillon2015-07-201-2/+2
| | | | | | | | 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>
* pwm: Add the pwm_is_enabled() helperBoris Brezillon2015-07-201-0/+5
| | | | | | | | | | 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>
* pwm: Add pwmchip_add_with_polarity() APITim Kryger2015-06-121-0/+7
| | | | | | | | | | | | 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>
* pwm: Add support to remove registered consumer lookup tablesShobhit Kumar2015-05-061-0/+5
| | | | | | | | | | | | | 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>
* pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup membersAlexandre Belloni2014-05-211-1/+3
| | | | | | | | 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>
* pwm: add period and polarity to struct pwm_lookupAlexandre Belloni2014-05-211-0/+2
| | | | | | | | | 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>
* pwm: Remove obsolete HAVE_PWM Kconfig symbolSascha Hauer2014-02-101-1/+1
| | | | | | | | | | | | | | | | | | | 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>
View Lorry Controller Status