Date
1 - 3 of 3
[PATCH 1/1] riscv-sbi.adoc: fix typos
|
%s/secion/section/
%s/managment/management/ %s/implemenation/implementation/ %s/requestd/requested/ %s/hierarchial/hierarchical/ %s/inititated/initiated/ %s/recieves/receives/ %s/rententive/retentive/ Signed-off-by: Heinrich Schuchardt <xypron.glpk@...> =2D-- riscv-sbi.adoc | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index 11c30c3..4b6f2c3 100644 =2D-- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -31,9 +31,9 @@ https://creativecommons.org/licenses/by/4.0/. * Improved document styling and naming conventions * Added SBI system reset extension -* Improved SBI introduction secion -* Improved documentation of SBI hart state managment extension -* Added suspend function to SBI hart state managment extension +* Improved SBI introduction section +* Improved documentation of SBI hart state management extension +* Added suspend function to SBI hart state management extension =3D=3D=3D Version 0.2 @@ -52,7 +52,7 @@ of the SBI follows the general RISC-V philosophy of havi= ng a small core along with a set of optional modular extensions. The higher privilege software providing SBI interface to the supervisor-m= ode -software is referred to as a SBI implemenation or Supervisor Execution +software is referred to as a SBI implementation or Supervisor Execution Environment (SEE). A SBI implementation (or SEE) can be platform runtime firmware executing in machine-mode (M-mode) (see below <<fig_intro1>>) or it can be some hypervisor executing in hypervisor-mode (HS-mode) (see bel= ow @@ -741,7 +741,7 @@ along with a unique **HSM state id** for each state: in the **STOPPED** state. | 4 | SUSPENDED | This hart is in a platform specific suspen= d (or low power) state. -| 5 | SUSPEND_PENDING | The hart has requestd to put itself in a +| 5 | SUSPEND_PENDING | The hart has requested to put itself in a platform specific low power state from the **STARTED** state and the SBI implementati= on is still working to get the hart in the @@ -764,22 +764,22 @@ image::riscv-sbi-hsm.png[] A platform can have multiple harts grouped into a hierarchical topology groups (namely cores, clusters, nodes, etc) with separate platform specif= ic low-power states for each hierarchical group. These platform specific -low-power states of hierarchial topology groups can be represented as +low-power states of hierarchical topology groups can be represented as platform specific suspend states of a hart. A SBI implementation can utilize the suspend states of higher topology groups using one of the following approaches: . *Platform-coordinated:* In this approach, when a hart becomes idle the - supervisor-mode power-managment software will request deepest suspend + supervisor-mode power-management software will request deepest suspend state for the hart and higher topology groups. A SBI implementation should choose a suspend state at higher topology group which is: .. Not deeper than the specified suspend state .. Wake-up latency is not higher than the wake-up latency of the specified suspend state -. *OS-inititated:* In this approach, the supervisor-mode power-managment +. *OS-initiated:* In this approach, the supervisor-mode power-management software will directly request a suspend state for higher topology grou= p after the last hart in that group becomes idle. When a hart becomes idl= e, - the supervisor-mode power-managment software will always select suspend + the supervisor-mode power-management software will always select suspen= d state for the hart itself but it will select a suspend state for a high= er topology group only if the hart is the last running hart in the group. A SBI implementation should: @@ -815,7 +815,7 @@ below. |=3D=3D=3D This call is asynchronous -- more specifically, the `sbi_hart_start()` ma= y -return before target hart starts executing as long as the SBI implemenati= on +return before target hart starts executing as long as the SBI implementat= ion is capable of ensuring the return code is accurate. It is recommended tha= t if the SBI implementation is a platform runtime firmware executing in machine-mode (M-mode) then it MUST configure PMP and other M-mode state @@ -915,13 +915,13 @@ struct sbiret sbi_hart_suspend(uint32_t suspend_type= , unsigned long opaque) ---- -Request the SBI implementation to put the calling hart in a platform spec= fic +Request the SBI implementation to put the calling hart in a platform spec= ific suspend (or low power) state specified by the `suspend_type` parameter. T= he hart will automatically come out of suspended state and resume normal -execution when it recieves an interrupt or platform specific hardware eve= nt. +execution when it receives an interrupt or platform specific hardware eve= nt. The platform specific suspend states for a hart can be either retentive -or non-rententive in nature. A retentive suspend state will preserve hart +or non-retentive in nature. A retentive suspend state will preserve hart register and CSR values for all privilege modes whereas a non-retentive suspend state will not preserve hart register and CSR values. =2D- 2.30.2 |
|
|
|
Bin Meng
On Fri, Jun 4, 2021 at 5:17 AM Heinrich Schuchardt <xypron.glpk@...> wrote:
Reviewed-by: Bin Meng <bmeng.cn@...> |
|
|
|
atishp@...
On Thu, 2021-06-03 at 23:16 +0200, Heinrich Schuchardt wrote:
%s/secion/section/Reviewed-by: Atish Patra <atish.patra@...> -- Regards, Atish |
|
|