riscv-non-isa / riscv-brs

The Boot and Runtime Services (BRS) specification provides the software requirements for system vendors and Operating System Vendors (OSVs) to interoperate with one another by providing expectations for the Operating System (OS) to utilize in acts of device discovery, system management, and other rich operations provided in this specification.
https://jira.riscv.org/browse/RVG-48
Creative Commons Attribution 4.0 International
38 stars 13 forks source link

ACPI/FFH gaps around exposing suspend-to-RAM capability. #61

Open andreiw opened 1 year ago

andreiw commented 1 year ago
          We discussed this topic in BRS meeing today: https://docs.google.com/presentation/d/1bWS_YUZAZwwDDgHOWf2S1vyoP_Eh7y6090-NjoJQTSo/edit#slide=id.g21d5651495d_0_17

Suspend shouldn't be mandatory, but we don't have the ACPI framework in place to allow arbitrary sbi calls?

Originally posted by @adurbin-rivos in https://github.com/riscv-non-isa/riscv-brs/issues/52#issuecomment-1668182024

andreiw commented 1 year ago

Suspend-to-RAM is not a BRS-I requirement today. It may become a requirement in a platform-specific section (e.g. client, BRS-I-C?), but for that perhaps it would be preferable to expose this in some ACPI-specific manner instead of just having the OS use SBI SUSP?

Need to study the ACPI spec and understand the necessary plumbing (that needs to be created) before making a call.

adurbin-rivos commented 1 year ago

@atishp04 This topic was supposed to be discussed in the PRS meeting today. Atish, could you share what transpired then?

atishp04 commented 1 year ago

We did not have a PRS meeting last week due to holidays in India. It is on next week's meeting agenda. I will update the summary after the meeting.

adurbin-rivos commented 1 year ago

Sorry. I was thinking there was one today, but there wasn't.

jones-drew commented 1 year ago

This was discussed in the PRS call on August 29, 2023. There may be a recording of that session and below is a summary of the slides

For HW-reduced systems, the ACPI-specific manner in which an OSPM initiates suspend-to-ram is with the FADT.SLEEP_CONTROL_REG, which is an MMIO address (it's not a generic address descriptor, so it can't be an FFH defined SBI call). While any OSPM that implements suspend-to-ram using the FADT register is able to do so in an ACPI-specific way, the trade-off is that the platform must provide the MMIO addresses. Regardless of the mechanism used for suspend-to-ram, it probably shouldn't be BRS-I mandatory as the ACPI spec also provides ways to describe when a platform is low power s0 idle capable and states that that means "...that the system will achieve no power benefit by making a sleep transition to S3". IOW, some platforms may want to only provide LPI levels and not system suspend (suspend-to-ram).