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

[Neil Armstrong <neil.armstrong@linaro.org>]

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?
> 
> Please refer to this Hardware diagram I explained earlier ,
> Link : https://lore.kernel.org/all/bade420c-aeb8-4bdd-b0cf-3ade17b21c18@oss.qualcomm.com/
> 
> 
> Please let me know your suggestions.
> 
> Thanks,
> Arpit
> 
> 
>     
> 
>