linux-dev/drivers/pwm, branch linus/master

pwm: pwm-cros-ec: Add channel type support

2022-05-20T14:40:01Z

Add support for EC_PWM_TYPE_DISPLAY_LIGHT and EC_PWM_TYPE_KB_LIGHT pwm types to the PWM cros_ec_pwm driver. This allows specifying one of these PWM channel by functionality, and let the EC firmware pick the correct channel, thus abstracting the hardware implementation from the kernel driver. To use it, define the node with the "google,cros-ec-pwm-type" compatible. Signed-off-by: Fabio Baltieri Reviewed-by: Tzung-Bi Shih Signed-off-by: Thierry Reding

pwm: twl-led: Implement .apply() callback

2022-05-20T14:34:54Z

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: lpc18xx: Implement .apply() callback

2022-05-20T14:29:58Z

To eventually get rid of all legacy drivers convert this driver to the modern world implementing .apply(). This pushes a variant of pwm_apply_legacy into the driver that was slightly simplified because the .set_polarity callback was a noop. There is no change in behavior. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: mediatek: Implement .apply() callback

2022-05-20T14:29:16Z

pwm: lpc32xx: Implement .apply() callback

2022-05-20T14:29:01Z

pwm: tegra: Implement .apply() callback

2022-05-20T14:28:49Z

pwm: stmpe: Implement .apply() callback

2022-05-20T14:28:35Z

pwm: sti: Implement .apply() callback

2022-05-20T14:28:18Z

pwm: pwm-mediatek: Add support for MediaTek Helio X10 MT6795

2022-05-20T14:22:15Z

The MediaTek Helio X10 MT6795 SoC has 7 PWMs: add a compatible string to use the right match data. Signed-off-by: AngeloGioacchino Del Regno Acked-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: tegra: Optimize period calculation

2022-05-20T14:20:07Z

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