Re: [PATCH v4 3/4] arm64: dts: qcom: shikra-cqm-evk: Enable display and add ili7807s panel

[Arpit Saini <arpit.saini@oss.qualcomm.com>]

On 9/23/2026 5:38 PM, Dmitry Baryshkov wrote:
> On Wed, Sep 23, 2026 at 04:16:21PM +0530, Arpit Saini wrote:
>> Hi Dmitry,
>>
>> On 9/22/2026 9:33 PM, Dmitry Baryshkov wrote:
>>> On Wed, Sep 16, 2026 at 02:41:20PM +0530, Nabige Aala wrote:
>>>> From: Arpit Saini <arpit.saini@oss.qualcomm.com>
>>>>
>>>> Enable the Shikra MDSS display subsystem on the Qualcomm
>>>> Shikra CQM EVK board and add the DLC0697 MIPI DSI display
>>>> panel node. Pin pm4125_l5 to 1.232V with regulator-allow-set-load
>>>> for DSI PHY PLL stability.
>>>>
>>>> Signed-off-by: Arpit Saini <arpit.saini@oss.qualcomm.com>
>>>> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 118 ++++++++++++++++++++++++++++
>>>>  1 file changed, 118 insertions(+)
>>>>
>>>> +
>>>> +&mdss_dsi0 {
>>>> +	vdda-supply = <&pm4125_l5>;
>>>> +
>>>> +	status = "okay";
>>>> +
>>>> +	panel@0 {
>>>> +		compatible = "dlc,dlc0697", "ilitek,ili7807s";
>>>> +		reg = <0>;
>>>> +
>>>> +		reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
>>>> +
>>>> +		vddi-supply = <&pm4125_l15>;
>>>> +		avdd-supply = <&vreg_disp_p>;
>>>> +		avee-supply = <&vreg_disp_n>;
>>>> +
>>>> +		pinctrl-0 = <&panel_rst_n &panel_te_pin &panel_bl_en>;
>>>
>>> As far as I remember, your panel_bl_en enables an external regulator.
>>> Why is it not described in this way?
>>>
>>
>> panel_bl_en is a Qcom's daughter card specific platform signal , it does not feed into the panel.
>>
>> It is a board-level GPIO on the CQM EVK daughter card used purely for
>> platform power sequencing.
>>
>> Adding panel_bl_en as an external regulator would be misleading and incorrect from a hardware perspective,
>> as it is not directly going into the panel.
> 
> Well... Aren't VREG_WLED and WLED_SIN1 / SIN2 directly going to the
> panel?
> 
>>
>> for the CQM EVK, the backlight is MIPI DCS driven and panel_bl_en is a
>> platform-specific sequencing pin, making pinctrl states the
>> appropriate binding here.
>>
>> Could you please take a look at earlier discussion we had and let us know your thoughts ?
>>
>> https://lore.kernel.org/all/29ca6303-4368-4aeb-b82f-039aa252780a@oss.qualcomm.com/
> 
> Exactly. The diagram there shows that GPIO 91 (panel_bl_en) is an enable
> signal for the WLED regulator, whose output is then fed to the panel.
> 

Hi Dmitry

Based on your feedback, I understand that the daughter-card WLED circuit
should be modelled as a regulator-controlled device.

I am planning the following implementation:

vreg_wled: regulator-wled {
	compatible = "regulator-fixed";
	regulator-name = "vreg_wled";
	gpio = <&tlmm 91 GPIO_ACTIVE_HIGH>;
	enable-active-high;
};

The panel node will reference it as:

wled-supply = <&vreg_wled>;

In the panel driver, I will add wled to the existing bulk supply list:

static const struct regulator_bulk_data ili7807s_supplies[] = {
	{ .supply = "vddi" },
	{ .supply = "avdd" },
	{ .supply = "avee" },
	{ .supply = "wled" },
};
The existing regulator_bulk_enable() and regulator_bulk_disable() calls in prepare() and unprepare()
will then control GPIO 91 through the fixed regulator.

Brightness will continue to be controlled through the panel's DCS backlight implementation:

wled-supply controls the WLED driver's enable signal.

The DCS backlight controls brightness through the panel CABC/PWM output.
panel_bl_en and panel_bl_suspend pinctrl states will be removed.

Could you please confirm whether this modelling and driver sequence match your expectations?

Thanks,
Arpit