[PATCH v7 4/7] pmdomain: rockchip: Add smc call to inform firmware

[Shawn Lin]

在 2025/2/18 19:05, Ulf Hansson 写道:
> On Tue, 18 Feb 2025 at 01:53, Shawn Lin <shawn.lin at rock-chips.com> wrote:
>>
>> Hi Heiko, Steven
>>
>> 在 2025/2/18 4:50, Heiko Stübner 写道:
>>> Am Montag, 17. Februar 2025, 18:10:32 MEZ schrieb Steven Price:
>>>> On 17/02/2025 15:16, Heiko Stübner wrote:
>>>>> Hi Steven,
>>>>>
>>>>> Am Montag, 17. Februar 2025, 15:47:21 MEZ schrieb Steven Price:
>>>>>> On 05/02/2025 06:15, Shawn Lin wrote:
>>>>>>> Inform firmware to keep the power domain on or off.
>>>>>>>
>>>>>>> Suggested-by: Ulf Hansson <ulf.hansson at linaro.org>
>>>>>>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>>>>>>> ---
>>>>>>
>>>>>> This patch is causing my Firefly RK3288 to fail to boot, it hangs
>>>>>> shortly after reaching user space, but the bootup messages include the
>>>>>> suspicious line "Bad mode in prefetch abort handler detected".
>>>>>> I suspect the firmware on this board doesn't support this new SMC
>>>>>> correctly. Reverting this patch on top of linux-next gets everything
>>>>>> working again.
>>>>>
>>>>> Is your board actually running some trusted firmware?
>>>>
>>>> Not as far as I know.
>>>>
>>>>> Stock rk3288 never had tf-a / psci [0], I did work on that for a while,
>>>>> but don't think that ever took off.
>>>>>
>>>>> I'm wondering who the smcc call is calling, but don't know about
>>>>> about smcc stuff.
>>>>
>>>> Good question - it's quite possible things are blowing up just because
>>>> there's nothing there to handle the SMC. My DTB is as upstream:
>>>>
>>>>           cpus {
>>>>                   #address-cells = <0x01>;
>>>>                   #size-cells = <0x00>;
>>>>                   enable-method = "rockchip,rk3066-smp";
>>>>                   rockchip,pmu = <0x06>;
>>>>
>>>> I haven't investigated why this code is attempting to call an SMC on
>>>> this board.
>>>
>>> I guess the why is easy, something to do with suspend :-) .
>>>
>>> I did go testing a bit, booting a rk3288-veyron produces the same issue
>>> you saw, likely due to the non-existent trusted-firmware.
>>>
>>> On the arm64-side, I tried a plethora of socs + tfa-versions,
>>>
>>>     rk3328: v2.5 upstream(?)-tf-a
>>>     rk3399: v2.9 upstream-tf-a
>>>     px30: v2.4+v2.9 upstream-tf-a
>>>     rk3568: v2.3 vendor-tf-a
>>>     rk3588: v2.3 vendor-tf-a
>>>
>>> and all ran just fine.
>>> So it really looks like the smcc call going to some unset location is
>>> the culprit.
>>>
>>> Looking at other users of arm_smcc_smc, most of them seem to be handled
>>> unguarded, but some older(?) arm32 boards actually check their DTs for an
>>> optee node before trying their smc-call.
>>>
>>> I guess in the pm-domain case, we could just wrap the call with:
>>>        if(arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_NONE)
>>>
>>
>> Thanks for the report and helping find out the cause!
>>
>> @Ulf, if the solution above seems reasonable to you, I can cook a fix-up
>> patch.
> 
> Seems reasonable to me, thanks!

Thanks Ulf, I have sent a individual fix-up patch.

> 
> [...]
> 
> Kind regards
> Uffe
>