Re: [PATCH] arm64: dts: qcom: sdm850-lenovo-yoga-c630: lower PSCI cluster idle

[Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>]

On 15/05/2026 14:13, Konrad Dybcio wrote:
> On 5/15/26 1:09 PM, Dmitry Baryshkov wrote:
>> On 15/05/2026 14:03, Konrad Dybcio wrote:
>>> On 5/15/26 1:01 PM, Dmitry Baryshkov wrote:
>>>> On 15/05/2026 14:00, Konrad Dybcio wrote:
>>>>> On 4/28/26 9:36 PM, Dmitry Baryshkov wrote:
>>>>>> 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 <dmitry.baryshkov@oss.qualcomm.com>
>>>>>> ---
>>>>>>     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.

> 
>> 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