Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: add panel rails to simplefb
From: Sam Day
Date: Mon Jun 29 2026 - 18:51:25 EST
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 :)
Cheers,
-Sam
>
> BR,
> -Sam
>
> >
> > Konrad
> >