Update the gpio-backlight binding to support configurations that require
more than one GPIO for enabling/disabling the backlight.
Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
---
.../leds/backlight/gpio-backlight.yaml | 24 +++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
index 584030b6b0b9..4e4a856cbcd7 100644
--- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
@@ -16,8 +16,18 @@ properties:
const: gpio-backlight
gpios:
- description: The gpio that is used for enabling/disabling the backlight.
- maxItems: 1
+ description: |
+ The gpio that is used for enabling/disabling the backlight.
+ Multiple GPIOs can be specified for panels that require several
+ enable signals. All GPIOs are controlled together.
+ type: array
+ minItems: 1
+ items:
+ type: array
+ minItems: 3
+ maxItems: 3
+ items:
+ type: integer
default-on:
description: enable the backlight at boot.
@@ -38,4 +48,14 @@ examples:
default-on;
};
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ backlight {
+ compatible = "gpio-backlight";
+ gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>,
+ <&gpio3 5 GPIO_ACTIVE_HIGH>,
+ <&gpio3 6 GPIO_ACTIVE_HIGH>;
+ default-on;
+ };
+
...
--
2.34.1On 20/01/2026 13:50, Sudarshan Shetty wrote: > 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. > > Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com> > --- > .../leds/backlight/gpio-backlight.yaml | 24 +++++++++++++++++-- > 1 file changed, 22 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml > index 584030b6b0b9..4e4a856cbcd7 100644 > --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml > +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml > @@ -16,8 +16,18 @@ properties: > const: gpio-backlight > > gpios: > - description: The gpio that is used for enabling/disabling the backlight. > - maxItems: 1 > + description: | > + The gpio that is used for enabling/disabling the backlight. > + Multiple GPIOs can be specified for panels that require several > + enable signals. All GPIOs are controlled together. > + type: array There is no such syntax in the bindings, from where did you get it? Type is already defined. items: minItems: 1 maxItems: 3 > + minItems: 1 > + items: > + type: array > + minItems: 3 > + maxItems: 3 > + items: > + type: integer All this is some odd stuff - just to be clear, don't send us LLM output. I don't want to waste my time to review microslop. Was it done with help of Microslop? Best regards, Krzysztof
On 20-01-2026 20:01, Krzysztof Kozlowski wrote: > On 20/01/2026 13:50, Sudarshan Shetty wrote: >> 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 >> >> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com> >> --- >> .../leds/backlight/gpio-backlight.yaml | 24 +++++++++++++++++-- >> 1 file changed, 22 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >> index 584030b6b0b9..4e4a856cbcd7 100644 >> --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >> +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >> @@ -16,8 +16,18 @@ properties: >> const: gpio-backlight >> >> gpios: >> - description: The gpio that is used for enabling/disabling the backlight. >> - maxItems: 1 >> + description: | >> + The gpio that is used for enabling/disabling the backlight. >> + Multiple GPIOs can be specified for panels that require several >> + enable signals. All GPIOs are controlled together. >> + type: array > > There is no such syntax in the bindings, from where did you get it? Type > is already defined. > > items: > minItems: 1 > maxItems: 3 > > >> + minItems: 1 >> + items: >> + type: array >> + minItems: 3 >> + maxItems: 3 >> + items: >> + type: integer > > All this is some odd stuff - just to be clear, don't send us LLM output. > I don't want to waste my time to review microslop. > > Was it done with help of Microslop? > I understand now that the schema changes I proposed were not correct, and I will address this in the next patch series. My intention was to check whether the gpio-backlight binding could support more than one enable-type GPIO. Could you please advise what would be an appropriate maximum number of GPIOs for gpio-backlight in such a scenario? For example, would allowing 2 GPIOs be acceptable, or should this case be handled in a different way? > Best regards, > Krzysztof
On 23/01/2026 12:11, tessolveupstream@gmail.com wrote: > > > On 20-01-2026 20:01, Krzysztof Kozlowski wrote: >> On 20/01/2026 13:50, Sudarshan Shetty wrote: >>> 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 That's not an enable gpio, but PWM. You write bindings for this device, not for something else - like your board. > >>> >>> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com> >>> --- >>> .../leds/backlight/gpio-backlight.yaml | 24 +++++++++++++++++-- >>> 1 file changed, 22 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>> index 584030b6b0b9..4e4a856cbcd7 100644 >>> --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>> +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>> @@ -16,8 +16,18 @@ properties: >>> const: gpio-backlight >>> >>> gpios: >>> - description: The gpio that is used for enabling/disabling the backlight. >>> - maxItems: 1 >>> + description: | >>> + The gpio that is used for enabling/disabling the backlight. >>> + Multiple GPIOs can be specified for panels that require several >>> + enable signals. All GPIOs are controlled together. >>> + type: array >> >> There is no such syntax in the bindings, from where did you get it? Type >> is already defined. >> >> items: >> minItems: 1 >> maxItems: 3 >> >> >>> + minItems: 1 >>> + items: >>> + type: array >>> + minItems: 3 >>> + maxItems: 3 >>> + items: >>> + type: integer >> >> All this is some odd stuff - just to be clear, don't send us LLM output. >> I don't want to waste my time to review microslop. >> >> Was it done with help of Microslop? >> > > I understand now that the schema changes I proposed were not correct, How such code could be even created... Just in case, do you understand that Microslop and LLM is waste of our time? > and I will address this in the next patch series. My intention was to > check whether the gpio-backlight binding could support more than one > enable-type GPIO. > Could you please advise what would be an appropriate maximum number of > GPIOs for gpio-backlight in such a scenario? For example, would allowing > 2 GPIOs be acceptable, or should this case be handled in a different way? We have plenty of examples for this, but anyway you won't need it because this is not an enable GPIO. Best regards, Krzysztof
On Wed, Jan 28, 2026 at 11:11:33AM +0100, Krzysztof Kozlowski wrote: > On 23/01/2026 12:11, tessolveupstream@gmail.com wrote: > > > > > > On 20-01-2026 20:01, Krzysztof Kozlowski wrote: > >> On 20/01/2026 13:50, Sudarshan Shetty wrote: > >>> 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 > > 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? Daniel.
On 28-01-2026 16:50, Daniel Thompson wrote: > On Wed, Jan 28, 2026 at 11:11:33AM +0100, Krzysztof Kozlowski wrote: >> On 23/01/2026 12:11, tessolveupstream@gmail.com wrote: >>> >>> >>> On 20-01-2026 20:01, Krzysztof Kozlowski wrote: >>>> On 20/01/2026 13:50, Sudarshan Shetty wrote: >>>>> 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 >> >> 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. > > Daniel.
On Thu, Jan 29, 2026 at 11:11:34AM +0530, tessolveupstream@gmail.com wrote: > On 28-01-2026 16:50, Daniel Thompson wrote: > > On Wed, Jan 28, 2026 at 11:11:33AM +0100, Krzysztof Kozlowski wrote: > >> On 23/01/2026 12:11, tessolveupstream@gmail.com wrote: > >>> > >>> > >>> On 20-01-2026 20:01, Krzysztof Kozlowski wrote: > >>>> On 20/01/2026 13:50, Sudarshan Shetty wrote: > >>>>> 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 > >> > >> 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.
On 23-01-2026 16:41, tessolveupstream@gmail.com wrote: > > > On 20-01-2026 20:01, Krzysztof Kozlowski wrote: >> On 20/01/2026 13:50, Sudarshan Shetty wrote: >>> 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 > >>> >>> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com> >>> --- >>> .../leds/backlight/gpio-backlight.yaml | 24 +++++++++++++++++-- >>> 1 file changed, 22 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>> index 584030b6b0b9..4e4a856cbcd7 100644 >>> --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>> +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>> @@ -16,8 +16,18 @@ properties: >>> const: gpio-backlight >>> >>> gpios: >>> - description: The gpio that is used for enabling/disabling the backlight. >>> - maxItems: 1 >>> + description: | >>> + The gpio that is used for enabling/disabling the backlight. >>> + Multiple GPIOs can be specified for panels that require several >>> + enable signals. All GPIOs are controlled together. >>> + type: array >> >> There is no such syntax in the bindings, from where did you get it? Type >> is already defined. >> >> items: >> minItems: 1 >> maxItems: 3 >> >> >>> + minItems: 1 >>> + items: >>> + type: array >>> + minItems: 3 >>> + maxItems: 3 >>> + items: >>> + type: integer >> >> All this is some odd stuff - just to be clear, don't send us LLM output. >> I don't want to waste my time to review microslop. >> >> Was it done with help of Microslop? >> > > I understand now that the schema changes I proposed were not correct, > and I will address this in the next patch series. My intention was to > check whether the gpio-backlight binding could support more than one > enable-type GPIO. > Could you please advise what would be an appropriate maximum number of > GPIOs for gpio-backlight in such a scenario? For example, would allowing > 2 GPIOs be acceptable, or should this case be handled in a different way? > In line with Daniel’s suggestion, I am planning to adopt a fixed upper limit for the number of backlight GPIOs. The current hardware only requires two GPIOs, so the maxItems can be set to 2. If future platforms or customers require support for a higher number of GPIOs, this limit can be increased and the driver can be updated accordingly. Kindly advise if this solution aligns with your expectations, or if you prefer an alternative maximum value. >> Best regards, >> Krzysztof >
On 27/01/2026 13:46, tessolveupstream@gmail.com wrote: > > > On 23-01-2026 16:41, tessolveupstream@gmail.com wrote: >> >> >> On 20-01-2026 20:01, Krzysztof Kozlowski wrote: >>> On 20/01/2026 13:50, Sudarshan Shetty wrote: >>>> 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 >> >>>> >>>> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com> >>>> --- >>>> .../leds/backlight/gpio-backlight.yaml | 24 +++++++++++++++++-- >>>> 1 file changed, 22 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>>> index 584030b6b0b9..4e4a856cbcd7 100644 >>>> --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>>> +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml >>>> @@ -16,8 +16,18 @@ properties: >>>> const: gpio-backlight >>>> >>>> gpios: >>>> - description: The gpio that is used for enabling/disabling the backlight. >>>> - maxItems: 1 >>>> + description: | >>>> + The gpio that is used for enabling/disabling the backlight. >>>> + Multiple GPIOs can be specified for panels that require several >>>> + enable signals. All GPIOs are controlled together. >>>> + type: array >>> >>> There is no such syntax in the bindings, from where did you get it? Type >>> is already defined. >>> >>> items: >>> minItems: 1 >>> maxItems: 3 >>> >>> >>>> + minItems: 1 >>>> + items: >>>> + type: array >>>> + minItems: 3 >>>> + maxItems: 3 >>>> + items: >>>> + type: integer >>> >>> All this is some odd stuff - just to be clear, don't send us LLM output. >>> I don't want to waste my time to review microslop. >>> >>> Was it done with help of Microslop? >>> >> >> I understand now that the schema changes I proposed were not correct, >> and I will address this in the next patch series. My intention was to >> check whether the gpio-backlight binding could support more than one >> enable-type GPIO. >> Could you please advise what would be an appropriate maximum number of >> GPIOs for gpio-backlight in such a scenario? For example, would allowing >> 2 GPIOs be acceptable, or should this case be handled in a different way? >> > > In line with Daniel’s suggestion, I am planning to adopt a fixed upper > limit for the number of backlight GPIOs. The current hardware only > requires two GPIOs, so the maxItems can be set to 2. > > If future platforms or customers require support for a higher number > of GPIOs, this limit can be increased and the driver can be > updated accordingly. > > Kindly advise if this solution aligns with your expectations, or if > you prefer an alternative maximum value. You have entire commit msg to explain the hardware and explain WHY you are doing this. In a concise and readable way. I will not be going through 2 different email threads with 20 messages to figure that out. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.