docs: Fix some typos

We fix few typos in documentation.

Signed-off-by: zhangdongdong <zhangdongdong@eswincomputing.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Xiang W <wxjstz@126.com>
Reviewed-by: Anup Patel <anup@brainfault.org>

4 files changed, 10 insertions, 10 deletions

diff --git a/docs/domain_support.md b/docs/domain_support.md
index 73931f1..8963b57 100644
--- a/docs/domain_support.md
+++ b/docs/domain_support.md
@@ -2,7 +2,7 @@ OpenSBI Domain Support
 ======================
 
 An OpenSBI domain is a system-level partition (subset) of underlying hardware
-having it's own memory regions (RAM and MMIO devices) and HARTs. The OpenSBI
+having its own memory regions (RAM and MMIO devices) and HARTs. The OpenSBI
 will try to achieve secure isolation between domains using RISC-V platform
 features such as PMP, ePMP, IOPMP, SiFive Shield, etc.
 
@@ -15,7 +15,7 @@ Important entities which help implement OpenSBI domain support are:
 Each HART of a RISC-V platform must have an OpenSBI domain assigned to it.
 The OpenSBI platform support is responsible for populating domains and
 providing HART id to domain mapping. The OpenSBI domain support will by
-default assign **the ROOT domain** to all HARTs of a RISC-V platform so
+default assign **the ROOT domain** to all HARTs of a RISC-V platform, so
 it is not mandatory for the OpenSBI platform support to populate domains.
 
 Domain Memory Region
@@ -29,7 +29,7 @@ OpenSBI and has following details:
 * **base** - The base address of a memory region is **2 ^ order**
   aligned start address
 * **flags** - The flags of a memory region represent memory type (i.e.
-  RAM or MMIO) and allowed accesses (i.e. READ, WRITE, EXECUTE, etc)
+  RAM or MMIO) and allowed accesses (i.e. READ, WRITE, EXECUTE, etc.)
 
 Domain Instance
 ---------------
diff --git a/docs/library_usage.md b/docs/library_usage.md
index d5d2ba9..bb64bc4 100644
--- a/docs/library_usage.md
+++ b/docs/library_usage.md
@@ -73,7 +73,7 @@ firmware drivers based on the external firmware architecture.
 **OPENSBI_EXTERNAL_SBI_TYPES** identifier is introduced to *sbi_types.h* for selecting
 external header file during the build preprocess in order to define OpensSBI data types
 based on external firmware data type binding.
-For example, *bool* is declared as *int* in sbi_types.h. However in EDK2 build system,
+For example, *bool* is declared as *int* in sbi_types.h. However, in EDK2 build system,
 *bool* is declared as *BOOLEAN* which is defined as *unsigned char* data type.
 
 External firmware can define **OPENSBI_EXTERNAL_SBI_TYPES** in CFLAGS and specify it to the
diff --git a/docs/platform_requirements.md b/docs/platform_requirements.md
index 68dc393..8735adb 100644
--- a/docs/platform_requirements.md
+++ b/docs/platform_requirements.md
@@ -10,7 +10,7 @@ To handle this, we have two types of RISC-V platform requirements:
 2. **Release specific platform requirements** which apply to a OpenSBI
    release and later releases
 
-Currently, we don't have any **Release specific platform requirements**
+Currently, we don't have any **Release specific platform requirements**,
 but such platform requirements will be added in future.
 
 Base Platform Requirements
diff --git a/docs/pmu_support.md b/docs/pmu_support.md
index d79b515..1db36fc 100644
--- a/docs/pmu_support.md
+++ b/docs/pmu_support.md
@@ -1,7 +1,7 @@
 OpenSBI SBI PMU extension support
 ==================================
 SBI PMU extension supports allow supervisor software to configure/start/stop
-any performance counter at anytime. Thus, an user can leverage full
+any performance counter at anytime. Thus, a user can leverage full
 capability of performance analysis tools such as perf if SBI PMU extension is
 enabled. The OpenSBI implementation makes the following assumptions about the
 hardware platform.
@@ -25,7 +25,7 @@ SBI PMU Device Tree Bindings
 ----------------------------
 
 Platforms may choose to describe PMU event selector and event to counter mapping
-values via device tree. The following sections describes the PMU DT node
+values via device tree. The following sections describe the PMU DT node
 bindings in details.
 
 * **compatible** (Mandatory) - The compatible string of SBI PMU device tree node.
@@ -42,7 +42,7 @@ This property shouldn't encode any raw hardware event.
 * **riscv,event-to-mhpmcounters**(Optional) - It represents a MANY-to-MANY
 mapping between a range of events and all the MHPMCOUNTERx in a bitmap format
 that can be used to monitor these range of events. The information is encoded in
-a table format where each row represent a certain range of events and
+a table format where each row represents a certain range of events and
 corresponding counters. The first column represents starting of the pmu event id
 and 2nd column represents the end of the pmu event id. The third column
 represent a bitmap of all the MHPMCOUNTERx. This property is mandatory if
@@ -53,10 +53,10 @@ shouldn't encode any raw event.
 or MANY-to-MANY mapping between the raw event(s) and all the MHPMCOUNTERx in
 a bitmap format that can be used to monitor that raw event. The encoding of the
 raw events are platform specific. The information is encoded in a table format
-where each row represent the specific raw event(s). The first column is a 64bit
+where each row represents the specific raw event(s). The first column is a 64bit
 match value where the invariant bits of range of events are set. The second
 column is a 64 bit mask that will have all the variant bits of the range of
-events cleared. Every other bits should be set in the mask.
+events cleared. All other bits should be set in the mask.
 The third column is a 32bit value to represent bitmap of all MHPMCOUNTERx that
 can monitor these set of event(s).
 If a platform directly encodes each raw PMU event as a unique ID, the value of