[PATCH] clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time

[PATCH] clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time

[Pengyu Luo]

Parking disp{0,1}_cc_mdss_mdp_clk_src clk broke simplefb on HUAWEI
Gaokun3, the image will stuck at grey for seconds until msm takes
over framebuffer. Use clk_rcg2_shared_no_init_park_ops to skip it.

Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
 drivers/clk/qcom/dispcc-sc8280xp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/qcom/dispcc-sc8280xp.c b/drivers/clk/qcom/dispcc-sc8280xp.c
index e91dfed0f..acc927c21 100644
--- a/drivers/clk/qcom/dispcc-sc8280xp.c
+++ b/drivers/clk/qcom/dispcc-sc8280xp.c
@@ -977,7 +977,7 @@ static struct clk_rcg2 disp0_cc_mdss_mdp_clk_src = {
 		.name = "disp0_cc_mdss_mdp_clk_src",
 		.parent_data = disp0_cc_parent_data_5,
 		.num_parents = ARRAY_SIZE(disp0_cc_parent_data_5),
-		.ops = &clk_rcg2_shared_ops,
+		.ops = &clk_rcg2_shared_no_init_park_ops,
 	},
 };
 
@@ -991,7 +991,7 @@ static struct clk_rcg2 disp1_cc_mdss_mdp_clk_src = {
 		.name = "disp1_cc_mdss_mdp_clk_src",
 		.parent_data = disp1_cc_parent_data_5,
 		.num_parents = ARRAY_SIZE(disp1_cc_parent_data_5),
-		.ops = &clk_rcg2_shared_ops,
+		.ops = &clk_rcg2_shared_no_init_park_ops,
 	},
 };
 
-- 
2.53.0

Re: [PATCH] clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time

[Konrad Dybcio]

On 3/3/26 4:01 PM, Pengyu Luo wrote:
> Parking disp{0,1}_cc_mdss_mdp_clk_src clk broke simplefb on HUAWEI
> Gaokun3, the image will stuck at grey for seconds until msm takes
> over framebuffer. Use clk_rcg2_shared_no_init_park_ops to skip it.

Do you have clk_ignore_unused/pd_ignore_unused in your cmdline?

The sc8280xp-huawei-gaokun3.dts references no clocks in the simplefb
node, so if you're unlucky with timing, this is ""expected behavior""

Konrad

Re: [PATCH] clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time

[Pengyu Luo]

On Wed, Mar 4, 2026 at 7:20 PM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 3/3/26 4:01 PM, Pengyu Luo wrote:
> > Parking disp{0,1}_cc_mdss_mdp_clk_src clk broke simplefb on HUAWEI
> > Gaokun3, the image will stuck at grey for seconds until msm takes
> > over framebuffer. Use clk_rcg2_shared_no_init_park_ops to skip it.
>
> Do you have clk_ignore_unused/pd_ignore_unused in your cmdline?
>

Yes, always.

> The sc8280xp-huawei-gaokun3.dts references no clocks in the simplefb
> node, so if you're unlucky with timing, this is ""expected behavior""
>

On gaokun, if simplefb holds the mdp clk, there will not be the early
framebuffer, I can't see it. After seconds, msm initialized, the
display would show logs.

Once I owned another sc8280xp device(Ntmer TW220 aka robo & kala), dsi
didn't work at that time, to bring up the simplefb, the clk must be
held and no parking. gaokun3 always requires no parking only.

BTW, I can see this grey flash without simplefb too. On x13s, if
building msm as a module and not putting the module into the initial
ramdisk, what happens?

Best wishes,
Pengyu

Re: [PATCH] clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time

[Konrad Dybcio]

On 3/4/26 12:54 PM, Pengyu Luo wrote:
> On Wed, Mar 4, 2026 at 7:20 PM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 3/3/26 4:01 PM, Pengyu Luo wrote:
>>> Parking disp{0,1}_cc_mdss_mdp_clk_src clk broke simplefb on HUAWEI
>>> Gaokun3, the image will stuck at grey for seconds until msm takes
>>> over framebuffer. Use clk_rcg2_shared_no_init_park_ops to skip it.
>>
>> Do you have clk_ignore_unused/pd_ignore_unused in your cmdline?
>>
> 
> Yes, always.
> 
>> The sc8280xp-huawei-gaokun3.dts references no clocks in the simplefb
>> node, so if you're unlucky with timing, this is ""expected behavior""
>>
> 
> On gaokun, if simplefb holds the mdp clk, there will not be the early
> framebuffer, I can't see it. After seconds, msm initialized, the
> display would show logs.

I'm going to assume you don't have efifb.

Is there a chance it's because simplefb is waiting for dispcc to probe,
and by the time that happens, msm probes right away?

i.e. it seems like something like

https://lore.kernel.org/lkml/20220806163255.10404-1-markuss.broks@gmail.com/

would be better suited if you want to get logs early *and* you have a
panel driver that works anyway

> 
> Once I owned another sc8280xp device(Ntmer TW220 aka robo & kala), dsi
> didn't work at that time, to bring up the simplefb, the clk must be
> held and no parking. gaokun3 always requires no parking only.
> 
> BTW, I can see this grey flash without simplefb too. On x13s, if
> building msm as a module and not putting the module into the initial
> ramdisk, what happens?

Do you mean that in conjunction with dispcc-sc8280xp present in
initramfs?

Konrad

Re: [PATCH] clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time

[Pengyu Luo]

On Wed, Mar 11, 2026 at 9:32 PM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 3/4/26 12:54 PM, Pengyu Luo wrote:
> > On Wed, Mar 4, 2026 at 7:20 PM Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> wrote:
> >>
> >> On 3/3/26 4:01 PM, Pengyu Luo wrote:
> >>> Parking disp{0,1}_cc_mdss_mdp_clk_src clk broke simplefb on HUAWEI
> >>> Gaokun3, the image will stuck at grey for seconds until msm takes
> >>> over framebuffer. Use clk_rcg2_shared_no_init_park_ops to skip it.
> >>
> >> Do you have clk_ignore_unused/pd_ignore_unused in your cmdline?
> >>
> >
> > Yes, always.
> >
> >> The sc8280xp-huawei-gaokun3.dts references no clocks in the simplefb
> >> node, so if you're unlucky with timing, this is ""expected behavior""
> >>
> >
> > On gaokun, if simplefb holds the mdp clk, there will not be the early
> > framebuffer, I can't see it. After seconds, msm initialized, the
> > display would show logs.
>
> I'm going to assume you don't have efifb.
>

TBH, I don't know it well. How can I check it?
Recently, grub works well and I can set a new degraded resolution for it.
On my x86 laptop, the downgraded resolution will be scaled up to full
screen, on this device, it displays on central with the degraded
resolution and keeps
around unused, no scale up.

> Is there a chance it's because simplefb is waiting for dispcc to probe,
> and by the time that happens, msm probes right away?
>

This is quite different from the android phone, where enabled dispcc
will kill simplefb.
AFAIK, the bootloader would setup display things. The display things
are properly configured(include dispcc) so that we can use fb.
However, when dispcc probed, mdp clk is reconfigured(mdp clk park on
xo), this will kill the fb, and it will reparent to dispcc_pll later
when clk_set_rate() on mdp_clk in somewhere of msm. (My disclaimer: I
am an amateur, this is only my quick insight, maybe totally wrong)

> i.e. it seems like something like
>
> https://lore.kernel.org/lkml/20220806163255.10404-1-markuss.broks@gmail.com/
>
> would be better suited if you want to get logs early *and* you have a
> panel driver that works anyway
>

Actually, I just want to cancel the grey flash.

> >
> > Once I owned another sc8280xp device(Ntmer TW220 aka robo & kala), dsi
> > didn't work at that time, to bring up the simplefb, the clk must be
> > held and no parking. gaokun3 always requires no parking only.
> >
> > BTW, I can see this grey flash without simplefb too. On x13s, if
> > building msm as a module and not putting the module into the initial
> > ramdisk, what happens?
>
> Do you mean that in conjunction with dispcc-sc8280xp present in
> initramfs?
>

I mean if we can load msm asap(builtin or early kms), then we may not
see the grey flash?
So the things I wondered are
Do you set msm and dispcc builtin or put it into initramfs?
Do you meet the grey flash before the display shows logs?

I built all the display things as modules if possible, and early kms
won't cancel the grey flash

Thanks.

Best wishes,
Pengyu

Re: [PATCH] clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time

[Jérôme de Bretagne]

> Parking disp{0,1}_cc_mdss_mdp_clk_src clk broke simplefb on HUAWEI
> Gaokun3, the image will stuck at grey for seconds until msm takes
> over framebuffer. Use clk_rcg2_shared_no_init_park_ops to skip it.
>
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>

This patch allows to keep the built-in display enabled on the Microsoft
Surface Pro 9 5G (Arcata) using efifb and software rendering. This was
achieved by passing the "module_blacklist=msm" option. It is really
useful as the built-in display is not yet working thus not described
in the arcata devicetree so far.

Thank you Pengyu.

Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>


Without this patch, the initial EFI framebuffer gets disabled a few
seconds after the initial boot messages. This has been a regression
as it used to work when doing the initial bringup with Linux 6.9.

As mentioned in the similar patchset for the x1e80100 dispcc driver
https://lore.kernel.org/all/67a51928-1c16-48a6-ac65-f67c36297e5e@oss.qualcomm.com/
according to Hans, this should be a fix for the following commit:

Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration")


Regards,
Jérôme