[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