On 2/26/2025 5:58 AM, Abel Vesa wrote:
Ideally, the requested duty cycle should never translate to a PWM value higher than the selected resolution (PWM size), but currently the best matched period is never reported back to the PWM consumer, so the consumer will still be using the requested period which is higher than the best matched one. This will result in PWM consumer requesting duty cycle values higher than the allowed PWM value. Currently, the consumer driver known to fail this way is the PWM backlight (pwm_bl) and should be reworked in such a way that the best matched period is used instead. As for the current implementation of the duty cycle calculation, it is capping the max value, fix that by using the resolution to figure out the maximum allowed PWM value. Cc: stable@xxxxxxxxxxxxxxx # 6.4 Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM") Signed-off-by: Abel Vesa <abel.vesa@xxxxxxxxxx> --- drivers/leds/rgb/leds-qcom-lpg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/leds/rgb/leds-qcom-lpg.c b/drivers/leds/rgb/leds-qcom-lpg.c index f3c9ef2bfa572f9ee86c8b8aa37deb8231965490..146cd9b447787bf170310321e939022dfb176e9f 100644 --- a/drivers/leds/rgb/leds-qcom-lpg.c +++ b/drivers/leds/rgb/leds-qcom-lpg.c @@ -529,7 +529,7 @@ static void lpg_calc_duty(struct lpg_channel *chan, uint64_t duty) unsigned int clk_rate;if (chan->subtype == LPG_SUBTYPE_HI_RES_PWM) {- max = LPG_RESOLUTION_15BIT - 1; + max = BIT(lpg_pwm_resolution_hi_res[chan->pwm_resolution_sel]) - 1; clk_rate = lpg_clk_rates_hi_res[chan->clk_sel]; } else {
I have a patch under review, https://lore.kernel.org/all/20250213003533.1684131-1-anjelique.melendez@xxxxxxxxxxxxxxxx/, which adds support for 6-bit resolution for regular PWM so this capping problem will also become an issue for regular PWM. I think it would make sense for you to include fixing the max for regular PWM here. Thoughts?
max = LPG_RESOLUTION_9BIT - 1;
