From: Arpit Saini <arpit.saini@oss.qualcomm.com>
To: Neil Armstrong <neil.armstrong@linaro.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Krzysztof Kozlowski <krzk@kernel.org>
Cc: Jessica Zhang <jesszhan0024@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>,
devicetree@vger.kernel.org, rajeevny@qti.qualcomm.com
Subject: Re: [PATCH 1/2] dt-bindings: display: panel: add optional wled-supply
Date: Tue, 6 Oct 2026 19:52:06 +0530 [thread overview]
Message-ID: <a3f1a0da-039f-43be-89a3-ecb5df28bc1d@oss.qualcomm.com> (raw)
In-Reply-To: <54da53e6-66db-4357-a00d-da27fb936117@linaro.org>
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
>>
>> 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
>>
>>
>>
>>
>
next prev parent reply other threads:[~2026-10-06 14:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 13:12 [PATCH 0/2] drm/panel: add WLED supply support Arpit Saini
2026-09-29 13:12 ` [PATCH 1/2] dt-bindings: display: panel: add optional wled-supply Arpit Saini
2026-10-01 6:55 ` Krzysztof Kozlowski
2026-10-01 6:57 ` Krzysztof Kozlowski
2026-10-01 9:55 ` Dmitry Baryshkov
2026-10-01 18:09 ` Arpit Saini
2026-10-02 8:22 ` Neil Armstrong
2026-10-06 14:22 ` Arpit Saini [this message]
2026-09-29 13:12 ` [PATCH 2/2] drm/panel: ili7807s: Add WLED supply Arpit Saini
2026-10-01 7:01 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3f1a0da-039f-43be-89a3-ecb5df28bc1d@oss.qualcomm.com \
--to=arpit.saini@oss.qualcomm.com \
--cc=airlied@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jesszhan0024@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=krzysztof.kozlowski@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rajeevny@qti.qualcomm.com \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®