- Nov 05, 2021
-
-
The pwm_ prefix suggests that pwm_busy_wait() is a function provided by the pwm core. Use the otherwise consistently used driver prefix for this function, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
When duty-cycle is at full level (100%), the TCNTn and TCMPn registers needs to be flushed in order to disable the signal. The PWM manual does not say anything about this, but states that only clearing the TCON auto-reload bit should be needed, and this seems to be true when the PWM duty-cycle is not at full level. This can be observed on an Axis ARTPEC-8, by running: echo <period> > pwm/period echo <period> > pwm/duty_cycle echo 1 > pwm/enable echo 0 > pwm/enable Since the TCNTn and TCMPn registers are activated when enabling the PWM (setting TCON auto-reload bit), and are not touched when disabling the PWM, the double buffered auto-reload function seems to be still active. Lowering duty-cycle, and restoring it again in between the enabling and disabling, makes the disable work since it triggers a reload of the TCNTn and TCMPn registers. Fix this by securing a reload of the TCNTn and TCMPn registers when disabling the PWM and having a full duty-cycle. Signed-off-by:
Mårten Lindahl <marten.lindahl@axis.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
zhaoxiao <long870912@gmail.com> Reviewed-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Describe better which driver applies to which SoC, to make configuring kernel for Samsung SoC easier. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
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>
-
Since commit 52eaba4c ("pwm: atmel: Rework tracking updates pending in hardware") the driver doesn't make use of mutexes any more, so the header defining these doesn't need to be included. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
- Oct 27, 2021
-
-
The existing pxa driver and the upcoming addition of PWM support in the TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and thereby a need for a of_xlate function with the period as its single argument. Introduce a common helper function in the core that can be used as of_xlate by such drivers and migrate the pxa driver to use this. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by:
Steev Klimaszewski <steev@kali.org> Tested-By:
Steev Klimaszewski <steev@kali.org> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211025170925.3096444-1-bjorn.andersson@linaro.org
-
- Sep 02, 2021
-
-
Switch the driver to support the .get_state() method. Signed-off-by:
Jitao Shi <jitao.shi@mediatek.com> [thierry.reding@gmail.com: add missing linux/bitfield.h include] Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Current calculation for period and high_width may have 64-bit overflow. state->period and rate are u64. rate * state->period will overflow. clk_div = div_u64(rate * state->period, NSEC_PER_SEC) period = div64_u64(rate * state->period, div); high_width = div64_u64(rate * state->duty_cycle, div); This patch is to resolve it by using mul_u64_u64_div_u64(). Signed-off-by:
Jitao Shi <jitao.shi@mediatek.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Switch the driver to support the .apply() method. Signed-off-by:
Jitao Shi <jitao.shi@mediatek.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
The clks "main" and "mm" are prepared in .probe() (and unprepared in .remove()). This results in the clocks being on during suspend which results in unnecessarily increased power consumption. Remove the clock operations from .probe() and .remove(). Add the clk_prepare_enable() in .enable() and the clk_disable_unprepare() in .disable(). Signed-off-by:
Jitao Shi <jitao.shi@mediatek.com> [thierry.reding@gmail.com: squashed in fixup patch] 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>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of sun4i_pwm_remove() and considers the device removed anyhow. So returning early results in a resource leak. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of pwm_sifive_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of pwm_samsung_remove() and considers the device removed anyhow. So returning early results in a resource leak. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of tpu_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of rcar_pwm_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of pca9685_pwm_remove() and considers the device removed anyhow. So returning early results in a resource leak. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of pwm_omap_dmtimer_remove() and considers the device removed anyhow. So returning early results in a resource leak. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of mtk_disp_pwm_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of pwm_imx_tpm_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of pwm_imx_tpm_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of cros_ec_pwm_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of brcmstb_pwm_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of atmel_tcb_pwm_remove() and considers the device removed anyhow. So returning early results in a resource leak. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of atmel_hlcdc_pwm_remove() and considers the device removed anyhow. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
With devm_pwmchip_add() there is no need to explicitly call pwmchip_remove(), so this call can be dropped from the remove callback. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-