Re: [PATCH 1/2] dt-bindings: display: panel: add optional wled-supply

[Arpit Saini]

On 10/6/2026 7:52 PM, Arpit Saini wrote:
> 
> 
> On 10/2/2026 1:52 PM, Neil Armstrong wrote:
>> On 10/1/26 20:09, Arpit Saini wrote:
>>>
>>>
>>> On 10/1/2026 3:25 PM, Dmitry Baryshkov wrote:
>>>> On Thu, Oct 01, 2026 at 08:57:52AM +0200, Krzysztof Kozlowski wrote:
>>>>> On 01/10/2026 08:55, Krzysztof Kozlowski wrote:
>>>>>> On Tue, Sep 29, 2026 at 06:42:20PM +0530, Arpit Saini wrote:
>>>>>>> Some boards drive the ILI7807S panel's backlight from an external
>>>>>>> WLED driver whose enable input is wired to a GPIO, typically modeled
>>>>>>> as a fixed regulator (e.g. vreg_wled).
>>>>>>
>>>>>> You describe something else. What's fixed regulator should not matter
>>>>>> here. Which pin is it in ILI7807S?
>>>>>>
>>>>>> It seems you just want to represent GPIO with a regulator. This is just
>>>>>> confusing and typical downstream workaround.
>>>>>
>>>>> What's more, you basically REVERT the review YOU RECEIVED in v1. Really,
>>>>> just sneak the same stuff 3 months after like the review never happened.
>>>>>
>>>>> NAK
>>>>
>>>> After discussing this offline with Krzysztof. It's not a supply (my
>>>> fault), it's an LCD driver. So, the best way to handle your displaycard
>>>> seems to add a gpio-backlight, reference it from the panel and then in
>>>> the driver check for the backlight's max_brightness level. If it's 1,
>>>> then you have to send extra DCS commands to control PWM. If it's
>>>> higher, use normal backlight class controls.
>>>>
>>>
>>> Hi Dmitry, Krzysztof
>>>
>>> I have a few clarifying questions regarding the proposed approach. Please let me know if I've misunderstood anything.
>>>      panel_backlight: backlight {
>>>        compatible = "gpio-backlight";
>>>        gpios = <&tlmm 91 GPIO_ACTIVE_HIGH>;
>>>        default-on;
>>>    };
>>>
>>> 1) Adding gpio-backlight and check for max_brightness level if its 1,
>>>
>>>     If we model LCD_BKLT_EN using gpio-backlight, the backlight device effectively exposes only on/off control (max_brightness = 1),
>>>     we can't support the full range of brightness i.e 0 to 16383 (0x3FFF)
>>>
>>> 2) Adding gpio-backlight and based upon max_brightness level of 1 , are you suggesting to register another
>>>     backlight device that can actually drive DCS brightness. In that case we can actually have the MIPI DCS controlled brightness
>>>
>>>     If so, wouldn't that result in two backlight devices associated with the same panel:
>>>
>>>      gpio-backlight device for enable/disable
>>>      panel backlight device for DCS brightness control
>>>       Is that the expected design?
>>
>> It's a great question because there's a large variety of how backlight is
>> implemented, and some panels can drive a PWM to an actually backlight controller
>> which uses external pwm. In this case we should model the backlight IC as
>> backlight driver with only 1 or 0 capability and use the DCS to program
>> the PWM.
>>
>> So it leads exactly to your issue. So perhaps one way would be to either:
>> - call into the gpio-backlight from the DCS callback, we may need to fix some locking issues
>> - add way to "link" backlight devices so the backlight value can be propagated
>>
>>
>> In any case the problem remains that both backlight devices will be exposed
>> to userspace, which we don't want. So additional changes will be needed.
>>
>>>
>>> 3) I previously tried modeling LCD_BKLT_EN using pinctrl states (panel_bl_en / panel_bl_suspend)
>>>     for the enable GPIO itself. However, Dmitry suggested modeling it as a regulator instead:
>>>
>>>     Link : https://lore.kernel.org/all/qkhgg5x67sijiialucvzac275zhpjrtt47a4udjpyzmgvilut5@dcrslq3ai7mc/
>>>
>>> 4) Modeled optional regulator wled-supply: a regulator that only gates the external backlight driver chip's power/enable,
>>>     with DCS remaining the sole brightness path in this current patch , the panel-himax-hx83121a.c does exactly the same.
>>>         Would this can be the preferred modeling for such panels?
> 
> Hi Neil,
> 
> Could you please help me understand why we cannot model the external WLED enable path similarly to panel-himax-hx83121a.c using an optional bl_supply?
> 
> In our case, this supply would only enable or disable the external WLED driver through LCD_BKLT_EN/GPIO91,
> while the panel’s existing MIPI DCS backlight would continue to control the brightness.
> 
> This approach would also avoid exposing a second backlight device to userspace. Would this be an acceptable way to model the ILI7807S panel?
> 
> Thanks,
> Arpit

Hi Dmitry, Krzysztof, Neil,

Could you please clarify why we cannot model the ILI7807S backlight similarly to the approach used in panel-himax-hx83121a.c?

Reference:
https://lore.kernel.org/all/20260608162622.403713-3-zhengxingda@xxxxxxxxxxx/

Our hardware has a similar split-control arrangement:

- The panel driver controls brightness through MIPI DCS commands.
- An external WLED driver powers the panel backlight LEDs.
- LCD_BKLT_EN / GPIO91 only enables or disables the external WLED driver.
- No separate backlight device is required for brightness control.

Therefore, could LCD_BKLT_EN be modeled as an optional bl-supply, 
with the panel driver enabling or disabling it while continuing to use DCS for brightness?

This would also avoid exposing a second backlight device to userspace. 

If this approach is not suitable, could you please clarify what differs from the accepted panel-himax-hx83121a.c model,
and advise on the preferred way to represent it ?

Thanks,
Arpit