Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: add panel rails to simplefb

[Konrad Dybcio]

On 6/30/26 12:51 AM, Sam Day wrote:
> Hi Konrad,
> 
> On Tuesday, 30 June 2026 at 8:39 AM, Sam Day <me@xxxxxxxxxxx> wrote:
> 
>> Hey Konrad,
>>
>> On Tuesday, 30 June 2026 at 12:24 AM, Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>>
>>> On 6/20/26 1:15 AM, Sam Day wrote:
>>>> Hello Konrad,
>>>>
>>>> On Saturday, 20 June 2026 at 1:11 AM, Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>>>>
>>>>> On 6/16/26 7:27 AM, Sam Day via B4 Relay wrote:
>>>>>> From: Sam Day <me@xxxxxxxxxxx>
>>>>>>
>>>>>> These regulators are marked regulator-boot-on, but that doesn't
>>>>>> guarantee they'll stay alive as long as the simplefb does. Adding the
>>>>>> explicit supplies ensures that booting with MDSS disabled doesn't
>>>>>> switch the panel off 30 seconds after boot.
>>>>>
>>>>> Why would you boot without MDSS if you want the panel to function?
>>>>
>>>> For my particular use-case [1] I'm trying to avoid taking over the display
>>>> hardware entirely, and use simplefb until kexecing into the real kernel. In
>>>> this case the user might halt in a pre-boot menu UI for a while.
>>>>
>>>> I can also imagine this being similarly useful for "recovery kernel" use-cases
>>>> where again, it may not be desirable to assume control of MDSS/MDP/DSI blocks.
>>>>
>>>> [1]: https://github.com/samcday/pocketboot
>>>
>>> Can you handle this by adding a panel = <&display_panel> property
>>> under simplefb, pointing to the display panel defined in the same
>>> file?
>>
>> No, that won't work because display_panel is a child of mdss_dsi0, which is
>> a child of mdss. So if those nodes are disabled (which is what I'm trying to
>> achieve), fw_devlink will defer probing simplefb.
> 
> I apologize for spamming you with false assertions! I just realized that
> fw_devlink won't step in and enforce such probe deferral unless the property
> explicitly ends with -supply.
> 
> However, I tried your suggestion and confirm that the LCD_VCI_3V + VDDI_POC
> regulators are still turned off by regulator_init_complete_work(). Since I've
> already embarrassed myself once today I'm not going to attempt to speculate as
> to why :)

That's the way we all learn!

Looks like the answer is 'because nothing grabs these regulators'..
At a glance, grabbing a regulator reference is strictly tied to a
struct device (and its fwnode), so it's probably not so easy to make it..

Konrad