- 06 Dec, 2022 31 commits
-
-
Uwe Kleine-König authored
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses. Reviewed-by:
Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-11-u.kleine-koenig@pengutronix.deSigned-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses. Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Acked-by:
-
Uwe Kleine-König authored
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses. Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by:
-
Uwe Kleine-König authored
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses. Acked-by:
-
Uwe Kleine-König authored
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses. Reviewed-by:
Tzung-Bi Shih <tzungbi@kernel.org> Acked-by:
-
Uwe Kleine-König authored
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses. Acked-by:
-
Uwe Kleine-König authored
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses. Acked-by:
Pavel Machek <pavel@ucw.cz> Acked-by:
-
Uwe Kleine-König authored
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses. Acked-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
-
Uwe Kleine-König authored
Record and report an error code for the events. This allows to report about failed calls without ambiguity and so gives a more complete picture. Acked-by:
-
Uwe Kleine-König authored
.get_state() might fail in some cases. To make it possible that a driver signals such a failure change the prototype of .get_state() to return an error code. This patch was created using coccinelle and the following semantic patch: @p1@ identifier getstatefunc; identifier driver; @@ struct pwm_ops driver = { ..., .get_state = getstatefunc ,... }; @p2@ identifier p1.getstatefunc; identifier chip, pwm, state; @@ -void +int getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state) { ... - return; + return 0; ... } plus the actual change of the prototype in include/linux/pwm.h (plus some manual fixing of indentions and empty lines). So for now all drivers return success unconditionally. They are adapted in the following patches to make the changes easier reviewable. Reviewed-by:Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Reviewed-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by:
-
Doug Brown authored
The PXA168, which is part of the MMP platform, also uses this driver. Signed-off-by:
Doug Brown <doug@schmorgal.com> Acked-by:
-
Doug Brown authored
Add a pointer to the location of reference manuals for some of the supported chips, and add a limitations section explaining the hardware's PWM disable behavior. Suggested-by:
-
Doug Brown authored
Switch to abrupt shutdown mode in order to stop the clock as soon as possible when PWM is disabled. This minimizes the possibility of the clock being re-enabled while it is still in the process of turning off, which will result in the clock ending up erroneously disabled. Signed-off-by:
-
Doug Brown authored
Now that pxa_pwm_apply always enables the clock first, there is no need for pxa_pwm_config to do any clock enabling/disabling. Signed-off-by:
-
Doug Brown authored
When disabling PWM, the duty cycle needs to be set to 0. This prevents the previous duty cycle from showing up momentarily when the clock is re-enabled next time. Because the clock has to be running in order to configure the duty cycle, unconditionally enable it early in pxa_pwm_apply and account for the correct enable count at the end. Suggested-by:
-
Doug Brown authored
These functions are only acting as wrappers for clk_prepare_enable and clk_disable_unprepare now, so remove them to simplify the driver. Suggested-by:
-
Daniel Golle authored
Add support for PWM on MT7986 which has 2 PWM channels, one of them is typically used for a temperature controlled fan. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Reviewed-by:
Sam Shih <sam.shih@mediatek.com> Link: https://lore.kernel.org/r/Y1K5ym1EL8kwzQEt@makrotopia.orgSigned-off-by:
-
Uwe Kleine-König authored
Found using coccinelle and the following semantic patch: @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, bits) + regmap_set_bits(map, reg, bits) @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, 0) + regmap_clear_bits(map, reg, bits) Tested-by:
Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20221115111347.3705732-6-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Found using coccinelle and the following semantic patch: @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, bits) + regmap_set_bits(map, reg, bits) @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, 0) + regmap_clear_bits(map, reg, bits) Tested-by:
-
Uwe Kleine-König authored
Found using coccinelle and the following semantic patch: @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, bits) + regmap_set_bits(map, reg, bits) @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, 0) + regmap_clear_bits(map, reg, bits) Link: https://lore.kernel.org/r/20221115111347.3705732-4-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Found using coccinelle and the following semantic patch: @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, bits) + regmap_set_bits(map, reg, bits) @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, 0) + regmap_clear_bits(map, reg, bits) Link: https://lore.kernel.org/r/20221115111347.3705732-3-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Found using coccinelle and the following semantic patch: @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, bits) + regmap_set_bits(map, reg, bits) @@ expression map, reg, bits; @@ - regmap_update_bits(map, reg, bits, 0) + regmap_clear_bits(map, reg, bits) Link: https://lore.kernel.org/r/20221115111347.3705732-2-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Andy Shevchenko authored
The debugfs_create_file() already has a check and adds S_IFREG automatically. Remove unneeded flag. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
Uwe Kleine-König authored
list_add() just overwrites the members of the element to add (here: chip->list) without any checks, even in the DEBUG_LIST case. So save the effort to initialize the list. Reviewed-by:
-
Uwe Kleine-König authored
alloc_pwms() only identified a free range of IDs and this range was marked as used only later by pwmchip_add(). Instead let alloc_pwms() already do the marking (which makes the function actually allocating the range and so justifies the function name). This way access to the allocated_pwms bitfield is limited to two functions only. Reviewed-by:
-
Uwe Kleine-König authored
This simplifies error handling as the need for goto error handling goes away and at the end of the function the code can be simplified as this code isn't used in the error case any more. Now memory allocation and the call to of_pwmchip_add() are done without holding the lock. Both don't access the data structures protected by &pwm_lock. Reviewed-by:
-
Uwe Kleine-König authored
To simplify validation of the used locking, document for the global pwm mutex what it actually protects against concurrent access. Also note for two functions modifying these that pwm_lock is held by the caller. Reviewed-by:
-
Daniel Golle authored
According to MT7622 Reference Manual for Development Board v1.0 the PWM unit found in the MT7622 SoC also comes with the PWM_CK_26M_SEL register at offset 0x210 just like other modern MediaTek ARM64 SoCs. And also MT7622 sets that register to 0x00000001 on reset which is described as 'Select 26M fix CLK as BCLK' in the datasheet. Hence set has_ck_26m_sel to true also for MT7622 which results in the driver writing 0 to the PWM_CK_26M_SEL register which is described as 'Select bus CLK as BCLK'. Fixes: 0c0ead76 ("pwm: mediatek: Always use bus clock") Signed-off-by:
-
Uwe Kleine-König authored
lpc18xx_pwm_probe() only ensures clk_rate <= NSEC_PER_SEC, the following reasoning is right even under this slightly lesser condition. Fixes: 8933d30c ("pwm: lpc18xx: Fix period handling") Acked-by:
Vladimir Zapolskiy <vz@mleia.com> Link: https://lore.kernel.org/r/20221108153013.132514-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
xinlei lee authored
In the original mtk_disp_pwm_get_state() function wrongly uses bit 0 of CON0 to judge if the PWM is enabled. However that is indicated by a bit (at a machine dependent position) in the DISP_PWM_EN register. Fix this accordingly. Fixes: 3f2b1673 ("pwm: mtk-disp: Implement atomic API .get_state()") Signed-off-by:
xinlei lee <xinlei.lee@mediatek.com> Reviewed-by:
-
Uwe Kleine-König authored
As was documented in commit 0f02f491 ("pwm: sifive: Reduce time the controller lock is held") a caller of pwm_sifive_update_clock() must hold the mutex. So fix pwm_sifive_clock_notifier() to grab the lock. While this necessity was only documented later, the race exists since the driver was introduced. Fixes: 9e37a53e ("pwm: sifive: Add a driver for SiFive SoC PWM") Reported-by:
Emil Renner Berthing <emil.renner.berthing@canonical.com> Reviewed-by:
-
- 29 Nov, 2022 3 commits
-
-
Paul Cercueil authored
Simplify a bit the code by using regmap_set_bits() and regmap_clear_bits() instead of regmap_update_bits() when possible. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by:
-
Paul Cercueil authored
The MACH_INGENIC Kconfig option will be selected when building a kernel targeting Ingenic SoCs, but also when compiling a generic MIPS kernel that happens to support Ingenic SoCs. Therefore, if MACH_INGENIC is not set, we know that we're not even trying to build a generic kernel that supports these SoCs, and we can hide the options to compile the SoC-specific drivers. Signed-off-by:
-
Paul Cercueil authored
Ingenic SoCs all require CONFIG_OF, so there is no case where we want to use this driver without CONFIG_OF. Signed-off-by:
-
- 23 Nov, 2022 2 commits
-
-
Geert Uytterhoeven authored
Document support for the 16-Bit Timer Pulse Unit (TPU) in the Renesas R-Car V4H (R8A779G0) SoC. Based on a patch in the BSP by CongDang. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
-
Geert Uytterhoeven authored
Document support for the PWM timers in the Renesas R-Car V4H (R8A779G0) SoC. Based on a patch in the BSP by CongDang. Signed-off-by:
-
- 11 Nov, 2022 1 commit
-
-
Steven Price authored
The value of NSEC_PER_SEC << PWM_DUTY_WIDTH doesn't fix within a 32 bit integer causing a build warning/error (and the value truncated): drivers/pwm/pwm-tegra.c: In function ‘tegra_pwm_config’: drivers/pwm/pwm-tegra.c:148:53: error: result of ‘1000000000 << 8’ requires 39 bits to represent, but ‘long int’ only has 32 bits [-Werror=shift-overflow=] 148 | required_clk_rate = DIV_ROUND_UP_ULL(NSEC_PER_SEC << PWM_DUTY_WIDTH, | ^~ Explicitly cast to a u64 to ensure the correct result. Fixes: cfcb68817fb3 ("pwm: tegra: Improve required rate calculation") Signed-off-by:Steven Price <steven.price@arm.com> Reviewed-by:
Jon Hunter <jonathanh@nvidia.com>
-
- 09 Nov, 2022 2 commits
-
-
Jon Hunter authored
When dynamically scaling the PWM clock, the function dev_pm_opp_set_rate() may set the PWM clock to a rate that is lower than what is required. The clock rate requested when calling dev_pm_opp_set_rate() is the minimum clock rate that is needed to drive the PWM to achieve the required period. Hence, if the actual clock rate is less than the requested clock rate, then the required period cannot be achieved and configuring the PWM fails. Fix this by calling clk_round_rate() to check if the clock rate that will be provided is sufficient and if not, double the required clock rate to ensure the required period can be attained. Fixes: 8c193f47 ("pwm: tegra: Optimize period calculation") Signed-off-by:
-
Jon Hunter authored
For the case where dev_pm_opp_set_rate() is called to set the PWM clock rate, the requested rate is calculated as ... required_clk_rate = (NSEC_PER_SEC / period_ns) << PWM_DUTY_WIDTH; The above calculation may lead to rounding errors because the NSEC_PER_SEC is divided by 'period_ns' before applying the PWM_DUTY_WIDTH multiplication factor. For example, if the period is 45334ns, the above calculation yields a rate of 5646848Hz instead of 5646976Hz. Fix this by applying the multiplication factor before dividing and using the DIV_ROUND_UP macro which yields the expected result of 5646976Hz. Fixes: 1d7796bd ("pwm: tegra: Support dynamic clock frequency configuration") Signed-off-by:
-
- 16 Oct, 2022 1 commit
-
-
Linus Torvalds authored
-
