lwn.git/drivers/pwm/pwm-tegra.c, branch v6.0-rc6

pwm: tegra: Implement .apply() callback

2022-05-20T14:28:49+00:00

To eventually get rid of all legacy drivers convert this driver to the modern world implementing .apply(). This just pushed a variant of pwm_apply_legacy() into the driver that was slightly simplified because the driver doesn't provide a .set_polarity() callback. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: tegra: Optimize period calculation

2022-05-20T14:20:07+00:00

Dividing by the result of a division looses precision because the result is rounded twice. E.g. with clk_rate = 48000000 and period = 32760033 the following numbers result: rate = pc->clk_rate >> PWM_DUTY_WIDTH = 187500 hz = DIV_ROUND_CLOSEST_ULL(100ULL * NSEC_PER_SEC, period_ns) = 3052 rate = DIV_ROUND_CLOSEST_ULL(100ULL * rate, hz) = 6144 The exact result would be 6142.5061875 and (apart from rounding) this is found by using a single division. As a side effect is also a tad cheaper to calculate. Also using clk_rate >> PWM_DUTY_WIDTH looses precision. Consider for example clk_rate = 47999999 and period = 106667: mul_u64_u64_div_u64(pc->clk_rate >> PWM_DUTY_WIDTH, period_ns, NSEC_PER_SEC) = 19 mul_u64_u64_div_u64(pc->clk_rate, period_ns, NSEC_PER_SEC << PWM_DUTY_WIDTH) = 20 (The exact result is 20.000062083332033.) With this optimizations also switch from round-closest to round-down for the period calculation. Given that the calculations were non-optimal for quite some time now with variations in both directions which nobody reported as a problem, this is the opportunity to align the driver's behavior to the requirements of new drivers. This has several upsides: - Implementation is easier as there are no round-nearest variants of mul_u64_u64_div_u64(). - Requests for too small periods are now consistently refused. This was kind of arbitrary before, where period_ns < min_period_ns was refused, but in some cases min_period_ns isn't actually implementable and then values between min_period_ns and the actual minimum were rounded up to the actual minimum. Note that the duty_cycle calculation isn't using the usual round-down approach yet. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: tegra: Rename variable pointing to driver private data

2022-02-02T17:03:04+00:00

Status quo is that variables of type struct tegra_pwm_chip * are named "pwm", "chip" or "pc". The two formers are all not optimal because usually only struct pwm_device * variables are named "pwm" and "chip" is usually used for variabled of type struct pwm_chip *. So consistently use the same and non-conflicting name "pc". Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: tegra: Add runtime PM and OPP support

2021-12-16T13:05:23+00:00

The PWM on Tegra belongs to the core power domain and we're going to enable GENPD support for the core domain. Now PWM must be resumed using runtime PM API in order to initialize the PWM power state. The PWM clock rate must be changed using OPP API that will reconfigure the power domain performance state in accordance to the rate. Add runtime PM and OPP support to the PWM driver. Reviewed-by: Ulf Hansson Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding

pwm: tegra: Assert reset only after the PWM was unregistered

2021-06-30T17:12:20+00:00

The driver is supposed to stay functional until pwmchip_remove() returns. So the reset must be asserted only after that. pwmchip_remove() always returns 0, so the return code can be ignored which keeps the tegra_pwm_remove() a bit simpler. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: tegra: Don't needlessly enable and disable the clock in .remove()

2021-06-30T17:12:20+00:00

There is no reason to enable the PWM clock just to assert the reset control. (If the reset control depends on the clock this is a bug and probably it doesn't because in .probe() the reset is deasserted without the clock being enabled.) Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: tegra: Don't modify HW state in .remove callback

2021-06-30T17:12:20+00:00

A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: tegra: Drop an if block with an always false condition

2021-06-30T17:12:20+00:00

tegra_pwm_remove() is only called after tegra_pwm_probe() successfully completed. In this case platform_set_drvdata() was called with a non-NULL value and so platform_get_drvdata(pdev) cannot return NULL. Returning an error code from a platform_driver's remove function is ignored anyway, so it's a good thing this exit path is gone. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: Always allocate PWM chip base ID dynamically

2021-03-22T10:53:00+00:00

Since commit 5e5da1e9fbee ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") all drivers use dynamic ID allocation explicitly. New drivers are supposed to do the same, so remove support for driver specified base IDs and drop all assignments in the low-level drivers. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: tegra: Convert to devm_platform_ioremap_resource()

2020-12-17T13:18:39+00:00

Use devm_platform_ioremap_resource() to simplify code. Signed-off-by: Yangtao Li Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding