On Thu, Feb 27, 2025 at 04:06:47AM +0100, Sebastian Reichel wrote: > Hi, > > On Wed, Feb 26, 2025 at 05:34:50PM +0100, Uwe Kleine-König wrote: > > On Wed, Feb 26, 2025 at 05:31:08PM +0200, Abel Vesa wrote: > > > The current implementation assumes that the PWM provider will be able to > > > meet the requested period, but that is not always the case. Some PWM > > > providers have limited HW configuration capabilities and can only > > > provide a period that is somewhat close to the requested one. This > > > simply means that the duty cycle requested might either be above the > > > PWM's maximum value or the 100% duty cycle is never reached. > > > > If you request a state with 100% relative duty cycle you should get 100% > > unless the hardware cannot do that. Which PWM hardware are you using? > > Which requests are you actually doing that don't match your expectation? > > drivers/leds/rgb/leds-qcom-lpg.c (which probably should at least get > a MAINTAINERS entry to have you CC'd considering all the PWM bits in > it). See the following discussion (I point you to my message in the > middle of a thread, which has a summary and probably is a good > starting point): > > https://lore.kernel.org/all/vc7irlp7nuy5yvkxwb5m7wy7j7jzgpg73zmajbmq2zjcd67pd2@cz2dcracta6w/ I had a quick glance at this thread. It sounded to me like the PWM driver was scaling the requested period to match h/ware capability but then neglected to scale the requested duty cycle accordingly. That means the qcomm PWM driver programming a fractional value into the hardware that was not being anywhere close to duty_cycle / period. So the recommendation was to fix the PWM driver rather than have pwm_bl.c work around it? Daniel.
