susp.rs 5.2 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788
  1. use sbi_spec::binary::SbiRet;
  2. /// System Suspend extension.
  3. ///
  4. /// The system suspend extension defines a set of system-level sleep states and a
  5. /// function which allows the supervisor-mode software to request that the system
  6. /// transitions to a sleep state. Sleep states are identified with 32-bit wide
  7. /// identifiers (`sleep_type`). The possible values for the identifiers are shown
  8. /// in the table below:
  9. ///
  10. /// | Type | Name | Description
  11. /// |-------------------------|----------------|-------------------------------
  12. /// | 0 | SUSPEND_TO_RAM | This is a "suspend to RAM" sleep type, similar to ACPI’s S2 or S3. Entry requires all but the calling hart be in the HSM `STOPPED` state and all hart registers and CSRs saved to RAM.
  13. /// | 0x00000001 - 0x7fffffff | | Reserved for future use
  14. /// | 0x80000000 - 0xffffffff | | Platform-specific system sleep types
  15. /// | > 0xffffffff | | Reserved
  16. ///
  17. /// The term "system" refers to the world-view of supervisor software. The
  18. /// underlying SBI implementation may be provided by machine mode firmware or a
  19. /// hypervisor.
  20. ///
  21. /// The system suspend extension does not provide any way for supported sleep types
  22. /// to be probed. Platforms are expected to specify their supported system sleep
  23. /// types and per-type wake up devices in their hardware descriptions. The
  24. /// `SUSPEND_TO_RAM` sleep type is the one exception, and its presence is implied
  25. /// by that of the extension.
  26. pub trait Susp {
  27. /// Request the SBI implementation to put the system transitions to a sleep state.
  28. ///
  29. /// A return from a `system_suspend()` call implies an error and an error code
  30. /// will be in `sbiret.error`. A successful suspend and wake up, results in the
  31. /// hart which initiated the suspend, resuming from the `STOPPED` state. To resume,
  32. /// the hart will jump to supervisor-mode, at the address specified by `resume_addr`,
  33. /// with the specific register values described in the table below.
  34. ///
  35. /// | Register Name | Register Value
  36. /// | ------------------------------------------------- | ------------------
  37. /// | satp | 0
  38. /// | sstatus.SIE | 0
  39. /// | a0 | hartid
  40. /// | a1 | `opaque` parameter
  41. /// All other registers remain in an undefined state.
  42. ///
  43. /// # Parameters
  44. ///
  45. /// The `resume_addr` parameter points to a runtime-specified physical address,
  46. /// where the hart can resume execution in supervisor-mode after a system suspend.
  47. ///
  48. /// *NOTE:* A single `usize` parameter is sufficient as `resume_addr`,
  49. /// because the hart will resume execution in supervisor-mode with the MMU off,
  50. /// hence `resume_addr` must be less than XLEN bits wide.
  51. ///
  52. /// The `opaque` parameter is an XLEN-bit value which will be set in the `a1`
  53. /// register when the hart resumes exectution at `resume_addr` after a
  54. /// system suspend.
  55. ///
  56. /// Besides ensuring all entry criteria for the selected sleep type are met, such
  57. /// as ensuring other harts are in the `STOPPED` state, the caller must ensure all
  58. /// power units and domains are in a state compatible with the selected sleep type.
  59. /// The preparation of the power units, power domains, and wake-up devices used for
  60. /// resumption from the system sleep state is platform specific and beyond the
  61. /// scope of this specification.
  62. ///
  63. /// When supervisor software is running inside a virtual machine, the SBI
  64. /// implementation is provided by a hypervisor. The system suspend will behave
  65. /// functionally the same as the native case, but might not result in any physical
  66. /// power changes.
  67. ///
  68. /// # Return value
  69. ///
  70. /// The possible return error codes returned in `SbiRet.error` are shown in the table below:
  71. ///
  72. /// | Error code | Description
  73. /// | --------------------------- | -------------------
  74. /// | `SbiRet::success()` | System has suspended and resumed successfully.
  75. /// | `SbiRet::invalid_param()` | `sleep_type` is reserved or is platform-specific and unimplemented.
  76. /// | `SbiRet::not_supported()` | `sleep_type` is not reserved and is implemented, but the platform does not support it due to one or more missing dependencies.
  77. /// | `SbiRet::invalid_address()` | `resume_addr` is not valid, possibly due to the following reasons: * It is not a valid physical address. * Executable access to the address is prohibited by a physical memory protection mechanism or H-extension G-stage for supervisor mode.
  78. /// | `SbiRet::failed()` | The suspend request failed for unspecified or unknown other reasons.
  79. fn system_suspend(&self, sleep_type: u32, resume_addr: usize, opaque: usize) -> SbiRet;
  80. }
  81. impl<T: Susp> Susp for &T {
  82. #[inline]
  83. fn system_suspend(&self, sleep_type: u32, resume_addr: usize, opaque: usize) -> SbiRet {
  84. T::system_suspend(self, sleep_type, resume_addr, opaque)
  85. }
  86. }