在2024年6月14日六月 上午3:32,Huacai Chen写道: > On Fri, Jun 14, 2024 at 10:25 AM Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx> wrote: >> >> >> >> 在2024年6月14日六月 上午3:11,Huacai Chen写道: >> > Hi, Jiaxun, >> > >> > On Fri, Jun 14, 2024 at 12:41 AM Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx> 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/sleeping-states.html 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 >> -- - Jiaxun