Re: [PATCH RFC] backlight: pwm_bl: Read back PWM period from provider

[Daniel Thompson <danielt@kernel.org>]

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.