- 06 Dec, 2022 30 commits
-
-
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: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-10-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: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-9-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. Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-8-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: Tzung-Bi Shih <tzungbi@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-7-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. Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-6-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. Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-5-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. Acked-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-4-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
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: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-3-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() 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: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> 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: Douglas Anderson <dianders@chromium.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-2-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>
-
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221113233639.24244-7-doug@schmorgal.comSigned-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Doug Brown <doug@schmorgal.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221113233639.24244-6-doug@schmorgal.comSigned-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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 <doug@schmorgal.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221113233639.24244-5-doug@schmorgal.comSigned-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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 <doug@schmorgal.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221113233639.24244-4-doug@schmorgal.comSigned-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Doug Brown <doug@schmorgal.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221113233639.24244-3-doug@schmorgal.comSigned-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Doug Brown <doug@schmorgal.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221113233639.24244-2-doug@schmorgal.comSigned-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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-5-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
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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 <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221117165812.27757-1-andriy.shevchenko@linux.intel.comSigned-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
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221117211143.3817381-5-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
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221117211143.3817381-4-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
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221117211143.3817381-3-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
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221117211143.3817381-2-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>
-
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: Daniel Golle <daniel@makrotopia.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/Y1iF2slvSblf6bYK@makrotopia.orgSigned-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
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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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 <u.kleine-koenig@pengutronix.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/1666172538-11652-1-git-send-email-xinlei.lee@mediatek.comSigned-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
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: Emil Renner Berthing <emil.renner.berthing@canonical.com> Link: https://lore.kernel.org/r/20221018061656.1428111-1-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>
-
- 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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 <paul@crapouillou.net> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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: Paul Cercueil <paul@crapouillou.net> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
- 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: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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: 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
- 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 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 <jonathanh@nvidia.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
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: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
- 16 Oct, 2022 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/crng/randomLinus Torvalds authored
Pull more random number generator updates from Jason Donenfeld: "This time with some large scale treewide cleanups. The intent of this pull is to clean up the way callers fetch random integers. The current rules for doing this right are: - If you want a secure or an insecure random u64, use get_random_u64() - If you want a secure or an insecure random u32, use get_random_u32() The old function prandom_u32() has been deprecated for a while now and is just a wrapper around get_random_u32(). Same for get_random_int(). - If you want a secure or an insecure random u16, use get_random_u16() - If you want a secure or an insecure random u8, use get_random_u8() - If you want secure or insecure random bytes, use get_random_bytes(). The old function prandom_bytes() has been deprecated for a while now and has long been a wrapper around get_random_bytes() - If you want a non-uniform random u32, u16, or u8 bounded by a certain open interval maximum, use prandom_u32_max() I say "non-uniform", because it doesn't do any rejection sampling or divisions. Hence, it stays within the prandom_*() namespace, not the get_random_*() namespace. I'm currently investigating a "uniform" function for 6.2. We'll see what comes of that. By applying these rules uniformly, we get several benefits: - By using prandom_u32_max() with an upper-bound that the compiler can prove at compile-time is ≤65536 or ≤256, internally get_random_u16() or get_random_u8() is used, which wastes fewer batched random bytes, and hence has higher throughput. - By using prandom_u32_max() instead of %, when the upper-bound is not a constant, division is still avoided, because prandom_u32_max() uses a faster multiplication-based trick instead. - By using get_random_u16() or get_random_u8() in cases where the return value is intended to indeed be a u16 or a u8, we waste fewer batched random bytes, and hence have higher throughput. This series was originally done by hand while I was on an airplane without Internet. Later, Kees and I worked on retroactively figuring out what could be done with Coccinelle and what had to be done manually, and then we split things up based on that. So while this touches a lot of files, the actual amount of code that's hand fiddled is comfortably small" * tag 'random-6.1-rc1-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: prandom: remove unused functions treewide: use get_random_bytes() when possible treewide: use get_random_u32() when possible treewide: use get_random_{u8,u16}() when possible, part 2 treewide: use get_random_{u8,u16}() when possible, part 1 treewide: use prandom_u32_max() when possible, part 2 treewide: use prandom_u32_max() when possible, part 1
-