aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-01-20pwm: rockchip: Eliminate potential race condition when probingSimon South1-3/+6
Commit 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") introduced a potential race condition in rockchip_pwm_probe(): A consumer could enable an inactive PWM, or disable a running one, between rockchip_pwm_probe() registering the device via pwmchip_add() and checking whether it is enabled (to determine whether it was started by a bootloader). This could result in a device's PWM clock being either enabled once more than necessary, potentially causing it to continue running when no longer needed, or disabled once more than necessary, producing a warning from the kernel. Eliminate these possibilities by modifying rockchip_pwm_probe() so it checks whether a device is enabled before registering it rather than after. Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Reported-by: Trent Piepho <tpiepho@gmail.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: rockchip: Replace "bus clk" with "PWM clk"Simon South1-2/+2
Clarify the Rockchip PWM driver's error messages by referring to the clock that operates a PWM device as the "PWM" clock, matching its name in the device tree, rather than the "bus" clock (which is especially misleading in the case of devices that also use a separate clock for bus access). Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare()Simon South1-1/+0
If rockchip_pwm_probe() fails to register a PWM device it calls clk_unprepare() for the device's PWM clock, without having first disabled the clock and before jumping to an error handler that also unprepares it. This is likely to produce warnings from the kernel about the clock being unprepared when it is still enabled, and then being unprepared when it has already been unprepared. Prevent these warnings by removing this unnecessary call to clk_unprepare(). Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: rockchip: Enable APB clock during register access while probingSimon South1-3/+5
Commit 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") modified rockchip_pwm_probe() to access a PWM device's registers directly to check whether or not the device is enabled, but did not also change the function so it first enables the device's APB clock to be certain the device can respond. This risks hanging the kernel on systems with PWM devices that use more than a single clock. Avoid this by enabling the device's APB clock before accessing its registers (and disabling the clock when register access is complete). Fixes: 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") Reported-by: Thierry Reding <thierry.reding@gmail.com> Suggested-by: Trent Piepho <tpiepho@gmail.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2021-01-20pwm: Remove ZTE ZX driverArnd Bergmann4-311/+0
The ZTE ZX platform is getting removed, so this driver is no longer needed. Cc: Jun Nie <jun.nie@linaro.org> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: sun4i: Remove erroneous else branchThierry Reding1-5/+1
Commit d3817a647059 ("pwm: sun4i: Remove redundant needs_delay") changed the logic of an else branch so that the PWM_EN and PWM_CLK_GATING bits are now cleared if the PWM is to be disabled, whereas previously the condition was always false, and hence the branch never got executed. This code is reported causing backlight issues on boards based on the Allwinner A20 SoC. Fix this by removing the else branch, which restores the behaviour prior to the offending commit. Note that the PWM_EN and PWM_CLK_GATING bits still get cleared later in sun4i_pwm_apply() if the PWM is to be disabled. Fixes: d3817a647059 ("pwm: sun4i: Remove redundant needs_delay") Reported-by: Taras Galchenko <tpgalchenko@gmail.com> Suggested-by: Taras Galchenko <tpgalchenko@gmail.com> Tested-by: Taras Galchenko <tpgalchenko@gmail.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: sl28cpld: Set driver data before registering the PWM chipThierry Reding1-2/+2
It is good practice to set the driver data before registering a device with a subsystem because the subsystem or the driver core may call back into the driver implementation. This is not currently an issue, but to prevent future changes from causing this to break unexpectedly, make sure that the driver data is set before the PWM chip registration. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: Remove unused function pwmchip_add_inversed()Uwe Kleine-König1-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>
2020-12-17pwm: imx27: Fix overflow for bigger periodsUwe Kleine-König1-1/+2
The second parameter of do_div is an u32 and NSEC_PER_SEC * prescale overflows this for bigger periods. Assuming the usual pwm input clk rate of 66 MHz this happens starting at requested period > 606060 ns. Splitting the division into two operations doesn't loose any precision. It doesn't need to be feared that c / NSEC_PER_SEC doesn't fit into the unsigned long variable "duty_cycles" because in this case the assignment above to period_cycles would already have been overflowing as period >= duty_cycle and then the calculation is moot anyhow. Fixes: aef1a3799b5c ("pwm: imx27: Fix rounding behavior") Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Tested-by: Johannes Pointner <johannes.pointner@br-automation.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: bcm2835: Support apply function for atomic configurationLino Sanfilippo1-45/+24
Use the newer .apply function of pwm_ops instead of .config, .enable, .disable and .set_polarity. This guarantees atomic changes of the pwm controller configuration. It also reduces the size of the driver. Since now period is a 64 bit value, add an extra check to reject periods that exceed the possible max value for the 32 bit register. This has been tested on a Raspberry PI 4. Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: keembay: Fix build failure with -OsUwe Kleine-König1-1/+6
The driver used this construct: #define KMB_PWM_LEADIN_MASK GENMASK(30, 0) static inline void keembay_pwm_update_bits(struct keembay_pwm *priv, u32 mask, u32 val, u32 offset) { u32 buff = readl(priv->base + offset); buff = u32_replace_bits(buff, val, mask); writel(buff, priv->base + offset); } ... keembay_pwm_update_bits(priv, KMB_PWM_LEADIN_MASK, 0, KMB_PWM_LEADIN_OFFSET(pwm->hwpwm)); With CONFIG_CC_OPTIMIZE_FOR_SIZE the compiler (here: gcc 10.2.0) this triggers: In file included from /home/uwe/gsrc/linux/drivers/pwm/pwm-keembay.c:16: In function ‘field_multiplier’, inlined from ‘keembay_pwm_update_bits’ at /home/uwe/gsrc/linux/include/linux/bitfield.h:124:17: /home/uwe/gsrc/linux/include/linux/bitfield.h:119:3: error: call to ‘__bad_mask’ declared with attribute error: bad bitfield mask 119 | __bad_mask(); | ^~~~~~~~~~~~ In function ‘field_multiplier’, inlined from ‘keembay_pwm_update_bits’ at /home/uwe/gsrc/linux/include/linux/bitfield.h:154:1: /home/uwe/gsrc/linux/include/linux/bitfield.h:119:3: error: call to ‘__bad_mask’ declared with attribute error: bad bitfield mask 119 | __bad_mask(); | ^~~~~~~~~~~~ The compiler doesn't seem to be able to notice that with field being 0x3ffffff the expression if ((field | (field - 1)) & ((field | (field - 1)) + 1)) __bad_mask(); can be optimized away. So use __always_inline and document the problem in a comment to fix this. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: core: Use octal permissionSoham Biswas1-1/+1
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>
2020-12-17pwm: lpss: Make compilable with COMPILE_TESTUwe Kleine-König1-3/+3
All used ACPI functions have dummy implementations, and there is no hard dependency on x86. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: Fix dependencies on HAS_IOMEMUwe Kleine-König1-7/+28
Drivers making use of IO remapping must depend on HAS_IOMEM. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: Use -EINVAL for unsupported polarityThierry Reding3-3/+3
Instead of using a mix of -EOPNOTSUPP and -ENOTSUPP, use the more standard -EINVAL to signal that the specified polarity value was invalid. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: sti: Remove unnecessary blank lineThierry Reding1-1/+0
A single blank line is enough to separate logical code blocks. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: sti: Avoid conditional gotosThierry Reding1-26/+22
Using gotos for conditional code complicates this code significantly. Convert the code to simple conditional blocks to increase readability. Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2020-12-17pwm: Add PWM fan controller driver for LGM SoCRahul Tanwar3-0/+256
Intel Lightning Mountain(LGM) SoC contains a PWM fan controller. This PWM controller does not have any other consumer, it is a dedicated PWM controller for fan attached to the system. Add driver for this PWM fan controller. Signed-off-by: Rahul Tanwar <rahul.tanwar@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>