On Fri, May 15, 2026 at 02:15:55PM +0300, Dmitry Baryshkov wrote:

On 15/05/2026 14:13, Konrad Dybcio wrote:

quoted

On 5/15/26 1:09 PM, Dmitry Baryshkov wrote:

quoted

On 15/05/2026 14:03, Konrad Dybcio wrote:

quoted

On 5/15/26 1:01 PM, Dmitry Baryshkov wrote:

quoted

On 15/05/2026 14:00, Konrad Dybcio wrote:

quoted

On 4/28/26 9:36 PM, Dmitry Baryshkov wrote:

quoted

With the default PSCI suspend value for cluster idle state Lenovo Yoga
C630 isn't stable enough. For example it might reset if display device
isn't probed early enough. Drop one of the bits from the PSCI suspend
value to make C630 work in stable way.

Fixes: a1ade6cac5a2 ("arm64: dts: qcom: sdm845: Switch PSCI cpu idle states from PC to OSI")
Signed-off-by: Dmitry Baryshkov <redacted>
---
    arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 4 ++++
    1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
index e41200839dbe..e6c67016552a 100644
--- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
+++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts

@@ -347,6 +347,10 @@ &cdsp_pas {
        status = "okay";
    };
    +&cluster_sleep_0 {
+    arm,psci-suspend-param = <0x41003244>;
+};

Is it better if you do hack in a

qmp_send(qmp, "{class: cx_mol, res: cx, val: mol}");

Any clarification? Then I can try hacking it in.

This will send a message to AOSS to intrusct it to prevent CX from
collapsing

This sounds like a dirty hack. I think, hacking psci-suspend-param is a lesser evil.

Yes, that dirty hack is supposed to help us understand why this is an issue
in the first place. Especially since it only came around at some point
(although I suppose you're not really happy with spending a day bisecting
when exactly)

A similar patch has, I think, always been in any laptop tree targeting c630.
It could having been a disablement of sync state, a removal of cluster sleep
or something similar.

And gracious ping.... Can we sort this out somehow?

quoted

quoted

I know that we should spend time on understanding, what should vote on CX instead, but having the issue only on C630 doesn't really help. Maybe it will go away once I can sort out the gcc / dispcc / mdss issue on SDM845 & SM8150.

If it's a "not enough votes" type issue, it can vary from device to
device, from unit to unit, depending on your luck in the silicon
lottery

Konrad

-- 
With best wishes
Dmitry

-- 
With best wishes
Dmitry