在2024年6月14日六月 上午3:32，Huacai Chen写道：
On Fri, Jun 14, 2024 at 10:25 AM Jiaxun Yang jiaxun.yang@flygoat.com wrote:
在2024年6月14日六月 上午3:11，Huacai Chen写道：
Hi, Jiaxun,
On Fri, Jun 14, 2024 at 12:41 AM Jiaxun Yang jiaxun.yang@flygoat.com wrote:
Most LoongArch 64 machines are using custom "SADR" ACPI extension to perform ACPI S3 sleep. However the standard ACPI way to perform sleep is to write a value to ACPI PM1/SLEEP_CTL register, and this is never supported properly in kernel.
Maybe our hardware is insane so we need "SADR", if so, this patch may break real hardware. What's your opinion, Jianmin?
I understand why your hardware need SADR. Most systems DDR self-refresh mode needs to be setup by firmware.
_S3 is also a firmware method, why we can't use it to setup self-refresh?
That's the problem from ACPI spec. As per ACPI spec _S3 method only tells you what should you write into PM1 or SLEEP_CTL register, it will NOT perform actual task to enter sleeping. (See 16.1.3.1 [1])
On existing LoongArch hardware _S3 method is only used to mark presence of S3 state. This is violating ACPI spec, but I guess we must live with it.
Furthermore, on Loongson hardware you have to disable access to DDR memory to access DDR controller's configuration registers. Which means self-refresh code must run from BIOS ROM.
[1]: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/16_Waking_and_Sleeping/sleepin...
Thanks - Jiaxun
Huacai
There is no chance that it may break real hardware. When firmware supplied SADR it will always use SADR. The fallback only happens when _S3 method exist but no SADR supplied, which won't happen on real hardware.
For QEMU we don't have stub firmware but standard compliant SEEP_CTL is sufficient for entering sleep mode, thus we need this fallback path.
Thanks
Huacai
--
- Jiaxun