On Thu, Jan 29, 2026 at 11:11:34AM +0530, tessolveupstream@gmail.com wrote:
On 28-01-2026 16:50, Daniel Thompson wrote:
quoted
On Wed, Jan 28, 2026 at 11:11:33AM +0100, Krzysztof Kozlowski wrote:
quoted
On 23/01/2026 12:11, tessolveupstream@gmail.com wrote:
quoted
On 20-01-2026 20:01, Krzysztof Kozlowski wrote:
quoted
On 20/01/2026 13:50, Sudarshan Shetty wrote:
quoted
Update the gpio-backlight binding to support configurations that require
more than one GPIO for enabling/disabling the backlight.
Why? Which devices need it? How a backlight would have three enable
GPIOs? I really do not believe, so you need to write proper hardware
justification.
To clarify our hardware setup:
the panel requires one GPIO for the backlight enable signal, and it
also has a PWM input. Since the QCS615 does not provide a PWM controller
for this use case, the PWM input is connected to a GPIO that is driven
high to provide a constant 100% duty cycle, as explained in the link
below.
https://lore.kernel.org/all/20251028061636.724667-1-tessolveupstream@gmail.com/T/#m93ca4e5c7bf055715ed13316d91f0cd544244cf5 (local)
That's not an enable gpio, but PWM.
You write bindings for this device, not for something else - like your
board.
Sudarshan: I believe at one point the intent was to model this hardware
as a pwm-backlight (using enables GPIOs to drive the enable pin)
attached to a pwm-gpio (to drive the PWM pin). Did this approach work?
Yes, the original plan was to model this using pwm‑gpio, and that
setup worked. But on the SOC there’s no actual PWM controller available
for this path— the LED_PWM line is just tied to a GPIO that’s driven
high (effectively a fixed 100% duty cycle). Because of that, describing
it as a PWM in DT was flagged as incorrect.
As pointed out during the SoC DTS review, the correct path forward is
to extend gpio‑backlight to handle multiple GPIOs, rather than
representing them as multiple separate backlight devices.
That not quite what I got from the link above. There is a suggestion to
use gpio-backlight, but the reason it was flagged is because pwm-gpio
was unused... it was not referenced by a pwm-backlight.
Having said that I suspect it is better to model this backlight controller
on this board as a gpio-backlight because from a backlight controller
point of this that is physically what the controller is composed of
(assuming there is not sufficient capacitance on the signal for a
software PWM to work at anything other than 0% and 100%). Even if those
GPIO signals are connected to the panel's PWM input I'm not sure that's
relevant because none of the backlight controller bindings model the
panel anyway.
Whatever route you select, you do need to make it clear in the patch
description *why* it is correct to model the system as a gpio-backlight.
Deferring to (potentially ambiguous) review comments is not sufficient
to explain why changing the gpio-backlight bindings are an improvement.
Daniel.