上传英文

Signed-off-by: Nduangavin123 <duanxichao@huawei.com>

en/device-dev/device-dev-guide.md

@@ -40,7 +40,7 @@ In addition, OpenHarmony provides a series of optional system components that ca
 | Basic&nbsp;capabilities | Using&nbsp;basic&nbsp;capabilities&nbsp;of<br/>&nbsp;OpenHarmony | -&nbsp;[Kernel&nbsp;for&nbsp;Mini&nbsp;Systems](kernel/kernel-mini-overview.md)<br/>-&nbsp;[Kernel&nbsp;for&nbsp;Small&nbsp;Systems](kernel/kernel-small-overview.md)<br/>-&nbsp;[Drivers](driver/driver-hdf-overview.md)<br/>-&nbsp;[Subsystems](subsystems/subsys-build-mini-lite.md)<br/>-&nbsp;[Security&nbsp;Guidelines](security/security-guidelines-overall.md)<br/>-&nbsp;[Privacy&nbsp;Protection](security/security-privacy-protection.md) |
 | Advanced&nbsp;development | Developing&nbsp;smart&nbsp;devices&nbsp;based<br/>&nbsp;on&nbsp;system&nbsp;capabilities | -&nbsp;[WLAN-connected&nbsp;Products](guide/device-wlan-led-control.md)<br/>-&nbsp;[Cameras&nbsp;Without&nbsp;a&nbsp;Screen](guide/device-iotcamera-control-overview.md)<br/>-&nbsp;[Cameras&nbsp;with&nbsp;a&nbsp;Screen](guide/device-camera-control-overview.md) |
 | Porting&nbsp;and&nbsp;adaptation | -&nbsp;Porting&nbsp;and&nbsp;adapting&nbsp;the&nbsp;<br/>OpenHarmony&nbsp;to&nbsp;an&nbsp;SoC<br/>-&nbsp;Porting&nbsp;and&nbsp;adapting&nbsp;the<br/>&nbsp;OpenHarmony&nbsp;to&nbsp;a<br/>&nbsp;third-party&nbsp;library | -&nbsp;[Mini&nbsp;System&nbsp;SoC&nbsp;Porting&nbsp;Guide](porting/oem_transplant_chip_prepare_knows.md)<br/>-&nbsp;[Small&nbsp;System&nbsp;SoC&nbsp;Porting&nbsp;Guide](porting/porting-smallchip-prepare-needs.md)<br/>-&nbsp;[Third-Party&nbsp;Library&nbsp;Porting&nbsp;Guide&nbsp;for&nbsp;Mini&nbsp;and&nbsp;Small&nbsp;Systems](porting/porting-thirdparty-overview.md) |
-| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](bundles/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](bundles/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](bundles/hpm-part-reference.md) |
+| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](hpm-part/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](hpm-part/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](hpm-part/hpm-part-reference.md) |
 | Reference | Referring&nbsp;to&nbsp;development&nbsp;specifications | [FAQs](faqs/faqs-overview.md) |
 
 
@@ -54,6 +54,6 @@ In addition, OpenHarmony provides a series of optional system components that ca
 | Basic&nbsp;capabilities | Using&nbsp;basic&nbsp;capabilities&nbsp;of&nbsp;OpenHarmony | -&nbsp;[Kernel&nbsp;for&nbsp;Standard&nbsp;Systems](kernel/kernel-standard-overview.md)<br/>-&nbsp;[Drivers](driver/driver-hdf-overview.md)<br/>-&nbsp;[Subsystems](subsystems/subsys-build-standard-large.md)<br/>-&nbsp;[Security&nbsp;Guidelines](security/security-guidelines-overall.md)<br/>-&nbsp;[Privacy&nbsp;Protection](security/security-privacy-protection.md) |
 | Advanced&nbsp;development | Developing&nbsp;smart&nbsp;devices<br/>&nbsp;based&nbsp;on&nbsp;system&nbsp;capabilities | -&nbsp;[Development&nbsp;Guidelines&nbsp;on&nbsp;Clock&nbsp;Apps](guide/device-clock-guide.md)<br/>-&nbsp;[Development&nbsp;Example&nbsp;for&nbsp;Platform&nbsp;Drivers](guide/device-driver-demo.md)<br/>-&nbsp;[Development&nbsp;Example&nbsp;for&nbsp;Peripheral&nbsp;Drivers](guide/device-outerdriver-demo.md) |
 | Porting&nbsp;and&nbsp;adaptation | Porting&nbsp;and&nbsp;adapting&nbsp;the<br/>&nbsp;OpenHarmony&nbsp;to&nbsp;a&nbsp;third-party&nbsp;library | -&nbsp;[Standard&nbsp;System&nbsp;Porting&nbsp;Guide](porting/standard-system-porting-guide.md)<br/>-&nbsp;[A&nbsp;Method&nbsp;for&nbsp;Rapidly&nbsp;Porting&nbsp;the&nbsp;OpenHarmony&nbsp;Linux&nbsp;Kernel](porting/porting-linux-kernel.md) |
-| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](bundles/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](bundles/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](bundles/hpm-part-reference.md) |
+| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](hpm-part/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](hpm-part/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](hpm-part/hpm-part-reference.md) |
 | Reference | Referring&nbsp;to&nbsp;development&nbsp;specifications | [FAQs](faqs/faqs-overview.md) 
 

en/device-dev/driver/Readme-EN.md

@@ -9,6 +9,7 @@
   - [HDF Development Example](driver-hdf-sample.md)
 - [Platform Driver Development](driver-develop.md)
   - [ADC](driver-platform-adc-develop.md)
+  - [DAC](driver-platform-dac-develop.md)
   - [GPIO](driver-platform-gpio-develop.md)
   - [HDMI](driver-platform-hdmi-develop.md)
   - [I2C](driver-platform-i2c-develop.md)
@@ -26,12 +27,14 @@
   - [Watchdog](driver-platform-watchdog-develop.md)
 - [Platform Driver Usage](driver-platform.md)
   - [ADC](driver-platform-adc-des.md)
+  - [DAC](driver-platform-dac-des.md)
   - [GPIO](driver-platform-gpio-des.md)
   - [HDMI](driver-platform-hdmi-des.md)
   - [I2C](driver-platform-i2c-des.md)
   - [I3C](driver-platform-i3c-des.md)
   - [MIPI CSI](driver-platform-mipicsi-des.md)
   - [MIPI DSI](driver-platform-mipidsi-des.md)
+  - [Pin](driver-platform-pin-des.md)
   - [PWM](driver-platform-pwm-des.md)
   - [Regulator](driver-platform-regulator-des.md)
   - [RTC](driver-platform-rtc-des.md)
@@ -46,4 +49,6 @@
   - [WLAN](driver-peripherals-external-des.md)
   - [Audio](driver-peripherals-audio-des.md)
   - [USB](driver-peripherals-usb-des.md)
-  - [Camera](driver-peripherals-camera-des.md)
+  - [Camera](driver-peripherals-camera-des.md)
\ No newline at end of file
+  - [Vibrator](driver-peripherals-vibrator-des.md)
+  - [Light](driver-peripherals-light-des.md)
\ No newline at end of file

en/device-dev/driver/driver-develop.md

@@ -2,6 +2,8 @@
 
 -   **[ADC](driver-platform-adc-develop.md)**  
 
+-   **[DAC](driver-platform-dac-develop.md)**  
+
 -   **[GPIO](driver-platform-gpio-develop.md)**  
 
 -   **[HDMI](driver-platform-hdmi-develop.md)**

en/device-dev/driver/driver-peripherals-lcd-des.md

@@ -159,9 +159,9 @@ The following example shows code for developing an LCD driver:
 #define HORIZONTAL_BACK_PORCH     20
 #define HORIZONTAL_FRONT_PORCH    20
 #define HORIZONTAL_SYNC_WIDTH     10
-#define VERTIACL_BACK_PORCH       14
-#define VERTIACL_FRONT_PORCH      16
-#define VERTIACL_SYNC_WIDTH       2
+#define VERTICAL_BACK_PORCH       14
+#define VERTICAL_FRONT_PORCH      16
+#define VERTICAL_SYNC_WIDTH       2
 #define FRAME_RATE                60
 
 /* PanelInfo structure */
@@ -300,9 +300,9 @@ static struct PanelInfo g_panelInfo = {
     .hbp = HORIZONTAL_BACK_PORCH,       /* horizontal back porch */
     .hfp = HORIZONTAL_FRONT_PORCH,      /* horizontal front porch */
     .hsw = HORIZONTAL_SYNC_WIDTH,       /* horizontal sync width */
-    .vbp = VERTIACL_BACK_PORCH,         /* vertiacl back porch */
-    .vfp = VERTIACL_FRONT_PORCH,        /* vertiacl front porch */
-    .vsw = VERTIACL_SYNC_WIDTH,         /* vertiacl sync width */
+    .vbp = VERTICAL_BACK_PORCH,         /* vertical back porch */
+    .vfp = VERTICAL_FRONT_PORCH,        /* vertical front porch */
+    .vsw = VERTICAL_SYNC_WIDTH,         /* vertical sync width */
     .frameRate = FRAME_RATE,            /* frame rate */
     .intfType = MIPI_DSI,               /* panel interface type */
     .intfSync = OUTPUT_USER,            /* output timming type */

en/device-dev/driver/driver-peripherals-light-des.md

@@ -148,7 +148,7 @@ The light driver model provides APIs to obtain information about all the lights
          HdfWorkDestroy(&drvData->work);
          HdfWorkQueueDestroy(&drvData->workQueue);
          (void)OsalMutexDestroy(&drvData->mutex);
-         (void)OsalMemFree(drvData);
+         OsalMemFree(drvData);
          g_lightDrvData = NULL;
      }
      ```

en/device-dev/driver/driver-peripherals-sensor-des.md

 # Sensor
-  
+ 
 
 ## Overview
 
@@ -7,7 +7,8 @@
 
 The sensor driver model masks the sensor hardware differences and provides interfaces for the upper-layer sensor service to implement basic sensor capabilities, including querying the sensor list, enabling or disabling a sensor, subscribing to or unsubscribing from sensor data changes, and setting sensor options. The model is developed on the Hardware Driver Foundation (HDF), Operating System Abstraction Layer (OSAL), and platform driver interfaces (such as the I2C, SPI, and UART buses). It provides functionalities such as cross-OS migration and differentiated device configurations. The figure below shows the architecture of the sensor driver model.
 
-**Figure 1** Sensor driver model 
+**Figure 1** Sensor driver model
+ 
 ![Sensor driver model](figures/sensor_driver_model.png)
 
 ### Basic Concepts
@@ -44,12 +45,12 @@ The following uses the acceleration sensor driver on the Hi3516D V300 developmen
 ### When to Use
 
 - Data provided by the gravity and gyroscope sensors denotes the tilt and rotation of the device, which helps your application improve user experience in games.
-- Data provided by the proximity sensor denotes the distance between the device and a visible object, which enables the device to automatically turn on or off its screen accordingly to prevent accidental touch on the screen. For example, when the proximity sensor detects the user face approaches the earpiece during a call, it triggers backlight of the screen to be turned off. This can further reduce power consumption.
+- Data provided by the proximity sensor denotes the distance between the device and a visible object, which enables the device to automatically turn on or off its screen accordingly to prevent accidental touch on the screen. For example, when the proximity sensor detects the user face approaches the earpiece during a call, it triggers backlight of the screen to be turned off. This prevents the screen from being accidentally touched and further reduces power consumption.
 - Data provided by the barometric pressure sensor helps your application accurately determine the altitude of the device.
 - Data provided by the ambient light sensor helps your device automatically adjust its backlight.
 - Data provided by the Hall effect sensor implements the smart cover mode of your device. When the smart cover is closed, a small window is opened on the phone to reduce power consumption. 
 
-### Available APIs<a name="section188213414114"></a>
+### Available APIs
 
 The sensor driver model offers the following APIs:
 
@@ -61,7 +62,7 @@ The sensor driver model offers the following APIs:
 
 The sensor driver model provides APIs for the hardware service to make sensor service development easier. See the table below.
 
-**Table 1** APIs for the members in the PinCntlrMethod structure
+**Table 1** APIs of the sensor driver model
 
 | API| Description| 
 | ----- | -------- |
@@ -111,9 +112,9 @@ The sensor driver model also provides certain driver development APIs that need
 | void ReadSensorData(void) | Reads sensor data.|
 
 
-For details about the interface implementation, see [How to Develop](#section7893102915819).
+For details about the interface implementation, see "How to Develop" below.
 
-### How to Develop<a name="section7893102915819"></a>
+### How to Develop
 1. Develop the acceleration sensor abstract driver. Specifically, implement the **Bind**, **Init**, **Release**, and **Dispatch** functions.
 
    - Implement the entry function for the acceleration sensor.
@@ -513,12 +514,11 @@ For details about the interface implementation, see [How to Develop](#section789
 
 >![](../public_sys-resources/icon-note.gif) **NOTE**
 >
->- The sensor driver model provides certain APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, common configuration, and configuration parsing capabilities. For details about them, see [Table 2](#table1156812588320).
->
->- You need to implement the following functions: certain sensor operation interfaces (listed in [Table 3](#table1083014911336)) and sensor chipset HCS configuration.
-> - You also need to verify basic driver functions.
+>- The sensor driver model provides certain APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, common configuration, and configuration parsing capabilities. For details about them, see Table 2.
+>- You need to implement the following functions: certain sensor operation interfaces (listed in Table 3) and sensor chipset HCS configuration.
+>- You also need to verify basic driver functions.
 
-### Commissioning and Verifying<a name="section106021256121219"></a>
+### How to Verify
 
 After the driver is developed, you can develop self-test cases in the sensor unit test to verify the basic functions of the driver. Use the developer self-test platform as the test environment.
 
@@ -545,7 +545,7 @@ void HdfSensorTest::SetUpTestCase()
 {
     g_sensorDev = NewSensorInterfaceInstance();
     if (g_sensorDev == nullptr) {
-        printf("test sensorHdi get Module instace failed\n\r");
+        printf("test sensorHdi get Module instance failed\n\r");
     }
 }
 /* Release case resources. */

en/device-dev/driver/driver-platform-dac-des.md

+# DAC
+
+
+## Overview
+
+### DAC
+
+A digit-to-analog converter (DAC) is a device that converts a digital signal into an analog signal in electronics.
+
+The DAC APIs provide a set of methods for DAC data transfer, including:
+
+- Opening or closing a DAC device
+- Setting the target digital-to-analog (DA) value
+
+
+### Basic Concepts
+
+The DAC module provides the output channel for the process control computer system. It connects to the executor to implement automatic control of the production process. It is also an important module in the analog-to-digital converter using feedback technologies.
+
+- Resolution
+
+  The number of binary bits that can be converted by a DAC. A greater number of bits indicates a higher resolution.
+
+- Conversion precision
+
+  Difference between the actual output value of the DAC and the theoretical value when the maximum value is added to the input end. The conversion precision of a DAC converter varies depending on the structure of the chip integrated on the DAC and the interface circuit configuration. The ideal conversion precision value should be as small as possible. To achieve optimal DAC conversion precision, the DAC must have high resolution. In addition, errors in the devices or power supply of the interface circuits will affect the conversion precision. When the error exceeds a certain degree, a DAC conversion error will be caused.
+
+- Conversion speed
+
+  The conversion speed is determined by the setup time. The setup time is the period from the time the input suddenly changes from all 0s to all 1s to the time the output voltage remains within the FSR ± ½LSB (or FSR ± x%FSR). It is the maximum response time of the DAC, and hence used to measure the conversion speed.
+  
+  The full scale range (FSR) is the maximum range of the output signal amplitude of a DAC. Different DACs have different FSRs, which can be limited by positive and negative currents or voltages.
+  
+  The least significant byte (LSB) refers to bit 0 (the least significant bit) in a binary number.
+
+### Working Principles
+
+In the Hardware Driver Foundation (HDF), the DAC module uses the unified service mode for API adaptation. In this mode, a device service is used as the DAC manager to handle access requests from the devices of the same type in a unified manner. The unified service mode applies to the scenario where there are many device objects of the same type. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services. The figure below shows the unified service mode.
+
+The DAC module is divided into the following layers:
+- The interface layer provides APIs for opening or closing a device and writing data.
+- The core layer provides the capabilities of binding, initializing, and releasing devices.
+- The adaptation layer implements other functions.
+
+![](../public_sys-resources/icon-note.gif)NOTE<br/>The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer.
+
+**Figure 1** Unified service mode
+
+![](figures/unified-service-mode.png "DAC-unified-service-mode")
+
+### Constraints
+
+ Currently, the DAC module supports only the kernels (LiteOS) of mini and small systems.
+
+## Development Guidelines
+
+### When to Use
+
+ The DAC module converts digital signals into analog signals in the form of current, voltage, or charge. It is mainly used in audio devices. Audio players and headsets use the DAC module as the digital-to-analog conversion channels.
+
+### Available APIs
+
+The table below describes the APIs of the DAC module. For more details, see API Reference.
+
+**Table 1** DAC driver APIs
+
+| API                                                     | Description        |
+| :------------------------------------------------------------| :------------ |
+| DevHandle DacOpen(uint32_t number)                           | Opens a DAC device. |
+| void DacClose(DevHandle handle)                              | Closes a DAC device. |
+| int32_t DacWrite(DevHandle handle, uint32_t channel, uint32_t val) | Sets the target DA value. |
+
+### How to Develop
+
+The figure below illustrates the process of using a DAC device.
+
+**Figure 2** Process of using a DAC device
+ 
+![](figures/process-of-using-DAC.png "Process of using a DAC")
+
+#### Opening a DAC Device
+
+Call **DacOpen()** to open a DAC device before performing the DA conversion.
+
+```
+DevHandle DacOpen(uint32_t number);
+```
+
+**Table 2** Description of DacOpen
+
+| **Parameter**      | Description         |
+| ---------- | ----------------- |
+| number     | DAC device number.        |
+| **Return Value**| **Description**   |
+| NULL       | Failed to open the DAC device.  |
+| Device handle  | Handle of the DAC device opened.|
+
+
+
+Open device 1 of the two ADC devices (numbered 0 and 1) in the system.
+
+```
+DevHandle dacHandle = NULL; /* DAC device handle /
+
+/* Open the DAC device. */
+dacHandle = DacOpen(1);
+if (dacHandle == NULL) {
+    HDF_LOGE("DacOpen: failed\n");
+    return;
+}
+```
+
+#### Setting the Target DA Value
+
+```
+int32_t DacWrite(DevHandle handle, uint32_t channel, uint32_t val);
+```
+
+**Table 3** Description of DacWrite
+
+
+| **Parameter**      | Description      |
+| ---------- | -------------- |
+| handle     | DAC device handle.   |
+| channel    | DAC channel number. |
+| val        | DA value to set.    |
+| **Return Value**| **Description**|
+| 0          | The operation is successful.      |
+| Negative value      | The operation failed.      |
+
+```
+/* Write the target DA value through the DAC_CHANNEL_NUM channel. */
+    ret = DacWrite(dacHandle, DAC_CHANNEL_NUM, val);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("%s: tp DAC write reg fail!:%d", __func__, ret);
+        DacClose(dacHandle);
+        return -1;
+    }
+```
+
+#### Closing a DAC Device
+
+After the DAC communication is complete, call **DacClose()** to close the DAC device.
+```
+void DacClose(DevHandle handle);
+```
+
+**Table 4** Description of DacClose
+
+
+| **Parameter**      | Description      |
+| ---------- | -------------- |
+| handle     | DAC device handle.   |
+| **Return Value**| **Description**|
+| void       | -            |
+
+
+
+Example:
+
+```
+DacClose(dacHandle); /* Close the DAC device. */
+```
+
+## Development Example
+
+The procedure is as follows:
+
+1. Open the DAC device based on the device number and obtain the device handle.
+2. Set the DA value. If the operation fails, close the device handle.
+3. Close the DAC device handle if the access to the DAC is complete.
+
+You can obtain the operation result by printing the log information based on the **val**.
+
+```
+#include "hdmi_if.h"          /* Header file for DAC APIs */
+#include "hdf_log.h"         /* Header file for log APIs */
+
+/* Define device 0, channel 1. */
+#define DAC_DEVICE_NUM 0
+#define DAC_CHANNEL_NUM 1
+
+/* Main entry of DAC routines. */
+static int32_t TestCaseDac(void)
+{
+    // Set the target DA value.
+    uint32_t val = 2;
+    int32_t ret;
+    DevHandle dacHandle;
+
+    /* Open the DAC device. */
+    dacHandle = DacOpen(DAC_DEVICE_NUM);
+    if (dacHandle == NULL) {
+        HDF_LOGE("%s: Open DAC%u fail!", __func__, DAC_DEVICE_NUM);
+        return -1;
+    }
+
+    /* Write data. */
+    ret = DacWrite(dacHandle, DAC_CHANNEL_NUM, val);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("%s: tp DAC write reg fail!:%d", __func__, ret);
+        DacClose(dacHandle);
+        return -1;
+    }
+
+    /* Close the DAC device. */
+    DacClose(dacHandle);
+
+    return 0;
+}
+```

en/device-dev/driver/driver-platform-i3c-des.md

@@ -225,7 +225,7 @@ if (ret != 2) {
 }
 ```
 
->![](./public_sys-resources/icon-caution.gif) **Caution**
+>![](../public_sys-resources/icon-caution.gif) **Caution**
 >
 >-   The device address in the **I3cMsg** structure does not contain the read/write flag bit. The read/write information is passed by the read/write control bit in the member variable **flags**.
 >-   The **I3cTransfer()** function does not limit the number of message structures or the length of data in each message structure. The I3C controller determines these two limits.

en/device-dev/driver/driver-platform-i3c-develop.md

@@ -164,9 +164,9 @@ The I3C module adaptation involves the following steps:
     
         ```c
         struct VirtualI3cCntlr {
-            struct AdcDevice device;// (Mandatory) Control object at the core layer. For details, see the following description of I3cCntlr.
+            struct I3cCntlr cntlr;   // (Mandatory) Control object at the core layer. For details, see the following description of I3cCntlr.
             volatile unsigned char *regBase;// (Mandatory) Register base address.
-            uint32_t regBasePhy; // (Mandatory) Physical base address of the register.
+            uint32_t regBasePhy;     // (Mandatory) Physical base address of the register.
             uint32_t regSize;        // (Mandatory) Bit width of the register.
             uint16_t busId;          // (Mandatory) Device number.
             uint16_t busMode;

en/device-dev/driver/driver-platform-pin-des.md

+#  Pin
+
+
+## Overview<a name="section1"></a>
+
+### Pin<a name="section2"></a>
+
+-   The pin, also called pin controller, manages pin resources of system on a chip (SoC) vendors and provides the pin multiplexing function.
+-   The pin module defines a set of common methods for managing pins, including:
+    -   Obtaining or releasing the pin description handle: The kernel compares the pin name passed in with the pin names of each controller in the linked list. If a match is found, a pin description handle is obtained. After the operation on the pin is complete, the pin description handle will be released.
+    -   Setting or obtaining the pull type of a pin: The pull type can be pull-up, pull-down, or floating.
+    -   Setting or obtaining the pull strength of a pin: You can set the pull strength as required.
+    -   Setting or obtaining the functions of a pin to implement pin multiplexing
+
+### Basic Concepts<a name="section3"></a>
+Pin, as a software concept, provides APIs for uniformly managing the pins from different SoC vendors, providing the pin multiplexing function, and configuring the electrical features of pins.
+
+- SoC
+
+  An SOC is a chip that integrates microprocessors, analog IP cores, digital IP cores, and memory for specific purposes.
+
+- Pin multiplexing
+
+  When the number of pins of a chip cannot handle the increasing connection requests, you can set the software registers to make the pins to work in different states.
+
+### Working Principles<a name="section4"></a>
+
+In the HDF, the pin module does not support the user mode and therefore does not need to publish services. It uses the service-free mode in interface adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS that does not distinguish the user mode and the kernel mode. The **DevHandle**, a void pointer, directly points to the kernel mode address of the device object.
+
+The pin module is divided into the following layers:
+-   Interface layer: provides APIs for obtaining a pin, setting or obtaining the pull type, pull strength, and functions of a pin, and releasing a pin.
+-   Core layer: provides the capabilities of matching pin resources and adding, removing, and managing pin controllers. The core layer interacts with the adaptation layer by using hooks.
+-   Adaptation layer: instantiates hooks to implement specific functions.
+
+**Figure 1** Service-free mode<a name="fig14423182615525"></a> 
+![](figures/service-free-mode.png "pin service-free mode")
+
+### Constraints<a name="section5"></a>
+
+ Currently, the pin module supports only the kernels (LiteOS) of mini and small systems.
+
+ ## Usage Guidelines<a name="section6"></a>
+
+ ### When to Use<a name="7"></a>
+
+  The pin module is a software concept and is used to manage pin resources. You can set the functions, pull type, and pull strength of pins to implement pin multiplexing.
+
+### Available APIs<a name="section8"></a>
+
+The table below describes the APIs of the pin module. For more details, see API Reference.
+
+**Table 1** Pin driver APIs
+<a name="table1"></a>
+
+| **API**                                                  | **Description**        |
+| ------------------------------------------------------------ | ---------------- |
+| DevHandle PinGet(const char *pinName);                       | Obtains the pin description handle.|
+| void PinPut(DevHandle handle);                               | Releases the pin description handle.|
+| int32_t PinSetPull(DevHandle handle, enum PinPullType pullType); | Sets the pull type of a pin.|
+| int32_t PinGetPull(DevHandle handle, enum PinPullType *pullType); | Obtains the pull type of a pin.|
+| int32_t PinSetStrength(DevHandle handle, uint32_t strength); | Sets the pull strength of a pin.|
+| int32_t PinGetStrength(DevHandle handle, uint32_t *strength); | Obtains the pull strength of a pin.|
+| int32_t PinSetFunc(DevHandle handle, const char *funcName);  | Sets the pin function.    |
+| int32_t PinGetFunc(DevHandle handle, const char **funcName); | Obtains the pin functions.    |
+
+>![](../public_sys-resources/icon-note.gif) **NOTE**<br/>
+>All APIs described in this document can be called only in the kernel space.
+
+### How to Develop<a name="section9"></a>
+
+The figure below shows the process.
+
+ **Figure 2** Process of using the pin module<a name="fig2"></a> 
+![](figures/process-of-using-pin.png "Process of using the pin module")
+
+#### Obtaining the Pin Description Handle
+
+Before performing an operation on a pin, call **PinGet** to obtain the pin description handle. This API returns the pin description handle that matches the input pin name.
+
+```
+DevHandle PinGet(const char *pinName);
+```
+
+**Table 2** Description of PinGet
+
+<a name="table2"></a>
+
+| Parameter      | Description               |
+| ---------- | ----------------------- |
+| pinName    | Pointer to the pin name.                 |
+| **Return Value**| **Description**         |
+| NULL       | Failed to obtain the pin description handle.|
+| handle     | Pin description handle obtained.        |
+
+Example: Obtain the handle of P18.
+
+```
+DevHandle handle = NULL;               /* Pin description handle */
+char pinName = "P18";                 /* Pin name. */
+handle = PinGet(pinName);
+if (handle == NULL) {
+    HDF_LOGE("PinGet: get handle failed!\n");
+    return;
+}
+```
+
+#### Setting the Pull Type of a Pin
+
+Call **PinSetPull** to set the pull type of a pin. 
+
+```
+int32_t PinSetPull(DevHandle handle, enum PinPullType pullType);
+```
+
+**Table 3** Description of PinSetPull
+
+<a name="table3"></a>
+
+| Parameter      | Description               |
+| ---------- | ----------------------- |
+| handle     | Pin description handle.        |
+| pullType   | Pull type to set.        |
+| **Return Value**| **Description**         |
+| 0          | The operation is successful.|
+| Negative value      | The operation fails.|
+
+Example: Set the pull type to pull-up.
+
+```
+int32_t ret;
+enum PinPullType pullTypeNum;
+/* Set the pull type of a pin. */
+pullTypeNum = 1;
+ret = PinSetPull(handle, pullTypeNum);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinSetPull: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Obtaining the Pull Type of a Pin
+
+Call **PinGetPull** to obtain the pull type of a pin.
+
+```
+int32_t PinGetPull(DevHandle handle, enum PinPullType *pullType);
+```
+
+**Table 4** Description of PinGetPull
+
+<a name="table4"></a>
+
+| Parameter      | Description                 |
+| ---------- | ------------------------- |
+| handle     | Pin description handle.          |
+| pullType   | Pointer to the pull type obtained.|
+| **Return Value**| **Description**           |
+| 0          | The operation is successful.  |
+| Negative value      | The operation fails.  |
+
+Example: Obtain the pull type of a pin.
+
+```
+int32_t ret;
+enum PinPullType pullTypeNum;
+/* Obtain the pull type of a pin.  */
+ret = PinGetPull(handle, &pullTypeNum);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinGetPull: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Setting the Pull Strength of a Pin
+
+Call **PinSetStrength** to set the pull type of a pin.
+
+```
+int32_t PinSetStrength(DevHandle handle, uint32_t strength);
+```
+
+**Table 5** Description of PinSetStrength
+
+<a name="table5"></a>
+
+| Parameter      | Description               |
+| ---------- | ----------------------- |
+| handle     | Pin description handle.           |
+| strength   | Pull strength to set.        |
+| **Return Value**| **Description**         |
+| 0          | The operation is successful.|
+| Negative value      | The operation fails.|
+
+Example: Set the pull strength of the pin to 2. 
+
+```
+int32_t ret;
+uint32_t strengthNum;
+/* Set the pull strength of the pin. */
+strengthNum = 2;
+ret = PinSetStrength(handle, strengthNum);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinSetStrength: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Obtaining the Pull Strength of a Pin
+
+Call **PinGetStrength** to obtain the pull strength set.
+
+```
+int32_t PinGetStrength(DevHandle handle, uint32_t *strength);
+```
+
+**Table 6** Description of PinGetStrength
+
+<a name="table6"></a>
+
+| Parameter      | Description                 |
+| ---------- | ------------------------- |
+| handle     | Pin description handle.             |
+| strength   | Pointer to the pull strength obtained.|
+| **Return Value**| **Description**           |
+| 0          | The operation is successful.  |
+| Negative value      | The operation fails.  |
+
+Example: Obtain the pull strength of a pin.
+
+```
+int32_t ret;
+uint32_t strengthNum;
+/* Obtain the pull strength of the pin. */
+ret = PinGetStrength(handle, &strengthNum);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinGetStrength: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Setting the Pin Function
+
+The pin function refers to the pin multiplexing function. The function of each pin is different. For details about the pin functions, see [pin_config.hcs](https://gitee.com/openharmony/device_soc_hisilicon/blob/master/hi3516dv300/sdk_liteos/hdf_config/pin/pin_config.hcs).
+
+Call **PinSetFunc** to set the pin function.
+
+```
+int32_t PinSetFunc(DevHandle handle, const char *funcName);
+```
+
+**Table 7** Description of PinSetFunc
+
+<a name="table7"></a>
+
+| Parameter      | Description           |
+| ---------- | ------------------- |
+| handle     | Pin description handle.       |
+| funcName   | Pointer to the pin function to set.      |
+| **Return Value**| **Description**     |
+| 0          | The operation is successful.|
+| Negative value      | The operation fails.|
+
+Example: Set the pin function to LSADC_CH1 (ADC channel 1).
+
+```
+int32_t ret;
+char funcName = "LSADC_CH1";
+/* Sets the pin function. */
+ret = PinSetFunc(handle, funcName);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinSetFunc: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Obtaining the Pin Function
+
+Call **PinGetFunc** to obtain the pin function set.
+
+```
+int32_t PinGetFunc(DevHandle handle, const char **funcName);
+```
+
+**Table 8** Description of PinGetFunc
+
+<a name="table8"></a>
+
+| Parameter      | Description             |
+| ---------- | --------------------- |
+| handle     | Pin description handle.         |
+| funcName   | Pointer to the function name obtained.|
+| **Return Value**| **Description**       |
+| 0          | The operation is successful.  |
+| Negative value      | The operation fails.  |
+
+Example: Obtain the pin function. 
+
+```
+int32_t ret;
+char *funcName;
+/* Obtain the pin function. */
+ret = PinGetFunc(handle,&funcName);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinGetFunc: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+####  Releasing a Pin Description Handle
+
+After the operations on a pin are complete, call **PinPut** to release the pin description handle.
+
+```
+void PinPut(DevHandle handle);
+```
+
+**Table 9** Description of PinPut
+
+<a name="table9"></a>
+
+| Parameter      | Description      |
+| ---------- | -------------- |
+| handle     | Pin description handle.  |
+| **Return Value**| **Description**|
+| NA         | No value is returned.      |
+
+Example: Release a pin description handle.
+
+``` 
+PinPut(handle);
+```
+
+## Development Example<a name="section10"></a>
+
+The procedure is as follows:
+1. Pass in the pin name to obtain the pin description handle.
+2. Set the pull type of the pin. If the operation fails, release the pin description handle.
+3. Obtain the pull type of the pin. If the operation fails, release the pin description handle.
+4. Set the pull strength of the pin. If the operation fails, release the pin description handle.
+5. Obtain the pin pull strength. If the operation fails, release the pin description handle.
+5. Set the pin function. If the operation fails, release the pin description handle.
+6. Obtain the pin function. If the operation fails, release the pin description handle.
+7. Release the pin description handle if no operation needs to be performed on the pin.
+
+```
+#include "hdf_log.h"         /* Header file for log APIs */
+#include "pin_if.h"   /* Header file for standard pin APIs */
+
+int32_t PinTestSample(void)
+{
+    int32_t ret;
+    uint32_t strengthNum;
+    enum PinPullType pullTypeNum;
+    char pinName;
+    char *funName;
+    DevHandle handle = NULL;
+
+    /* Pin name. Set it to the actual pin name. */
+    pinName = "P18"; 
+    /* Obtain the pin description handle. */
+    handle = PinGet(pinName);
+    if (handle == NULL) {
+        HDF_LOGE("PinGet: failed!\n");
+        return;
+    }
+    /* Set the pull type to pull-up for the pin. */
+    pullTypeNum = 1;
+    ret = PinSetPull(handle, pullTypeNum);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinSetPull: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Obtain the pull type of the pin. */
+    ret = PinGetPull(handle, &pullTypeNum);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinGetPull: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Set the pull strength of the pin to 2. */
+    strengthNum = 2;
+    ret = PinSetStrength(handle, strengthNum);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinSetStrength: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Obtain the pull strength of the pin. */
+    ret = PinGetStrength(handle, &strengthNum);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinGetStrength: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Set the pin function to LSADC_CH1. */
+    funName = "LSADC_CH1";
+    ret = PinSetFunc(handle, funName);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinSetFunc: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Obtain the pin function. */
+    ret = PinGetFunc(handle, &funcName);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinGetFunc: failed, ret %d\n", ret);
+        goto ERR;
+    }
+ERR:
+    /* Release the pin description handle. */
+    PinPut(handle); 
+    return ret;
+}

en/device-dev/driver/driver-platform.md

@@ -2,6 +2,8 @@
 
 -   **[ADC](driver-platform-adc-des.md)**  
 
+-   **[DAC](driver-platform-dac-des.md)**  
+
 -   **[GPIO](driver-platform-gpio-des.md)**  
 
 -   **[HDMI](driver-platform-hdmi-des.md)**  
@@ -14,6 +16,8 @@
 
 -   **[MIPI DSI](driver-platform-mipidsi-des.md)**  
 
+-   **[Pin](driver-platform-pin-des.md)**
+
 -   **[PWM](driver-platform-pwm-des.md)**  
 
 -   **[RTC](driver-platform-rtc-des.md)**  

en/device-dev/get-code/Readme-EN.md

 # Source Code Acquisition
 
-- [Source Code Acquisition](sourcecode-acquire.md)
-- [Tool Acquisition](gettools.md)
-  - [Docker Environment](gettools-acquire.md)
-  - [IDE](gettools-ide.md)
-
+- [Obtaining Source Code](sourcecode-acquire.md)
+- Obtaining Tools
+    - [Overview](gettools-overview.md)
+    - [Docker Environments](gettools-acquire.md)
+    - [IDE](gettools-ide.md)

en/device-dev/get-code/gettools-acquire.md

@@ -166,7 +166,7 @@ Files generated during building are stored in the  **out/{device_name}/**  direc
 
 ## HPM-based Docker Environment<a name="section485713518337"></a>
 
-**docker\_dist**  is a template component in the  [HPM](https://hpm.harmonyos.com/#/en/home)  system. It helps to quickly initialize an HPM project and use the Docker image to quickly build a distribution of OpenHarmony, greatly simplifying environment configurations needed for building. After configuring the Ubuntu and [hpm-cli](../bundles/hpm-part-development.md) development environments, perform the following steps to access the Docker environment:
+**docker\_dist**  is a template component in the  [HPM](https://hpm.harmonyos.com/#/en/home)  system. It helps to quickly initialize an HPM project and use the Docker image to quickly build a distribution of OpenHarmony, greatly simplifying environment configurations needed for building. After configuring the Ubuntu and hpm-cli development environments, perform the following steps to access the Docker environment:
 
 ### Setting Up the Docker Environment<a name="section3295842510"></a>
 

en/device-dev/get-code/gettools-ide.md

-# IDE<a name="EN-US_TOPIC_0000001128361880"></a>
+# IDE
 
-## Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)<a name="section2452141120244"></a>
+## Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)
 
 HUAWEI DevEco Device Tool is a one-stop integrated development environment \(IDE\) provided to develop applications for OpenHarmony devices. It allows on-demand customization of OpenHarmony components, code editing, building, burning, and debugging, and supports C and C++ languages. This tool is installed in Visual Studio Code as a plug-in. For details, see  [HUAWEI DevEco Device Tool](https://device.harmonyos.com/en/ide)  and  [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905).
 
-The roadmap of Huawei DevEco Device Tool for supporting OpenHarmony device development is shown in the figure below.
 
-![](figure/evolution-roadmap.png)
+## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)
 
-## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)<a name="section0904101019258"></a>
-
-HUAWEI DevEco Studio \(DevEco Studio for short\) is a one-stop IDE oriented to Huawei devices in all scenarios. It provides E2E OpenHarmony application development services, ranging from project template creation to development, building, debugging, and release. With DevEco Studio, you will be able to efficiently develop OpenHarmony applications with distributed capabilities while speeding up innovation. For details, see  [HUAWEI DevEco Studio](https://developer.harmonyos.com/en/develop/deveco-studio)  and  [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387).
+HUAWEI DevEco Studio \(DevEco Studio for short\) is a one-stop IDE oriented to Huawei devices in all scenarios. It provides E2E OpenHarmony application development services, ranging from project template creation to development, building, debugging, and release. With DevEco Studio, you will be able to efficiently develop OpenHarmony applications with distributed capabilities while speeding up innovation. For details, see  [HUAWEI DevEco Studio](https://developer.harmonyos.com/en/develop/deveco-studio)  and  [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ohos-deveco-studio-overview-0000001263280421).
 

en/device-dev/get-code/gettools-overview.md

+# Overview
+
+To streamline your device development process, OpenHarmony provides the useful tools listed below.
+
+**Table 1**  Tools for device development
+
+| Tool | Description | Related Resources|
+| ----  | ------ | ------ |
+| DevEco Device Tool | A one-stop integrated development environment (IDE) provided for developers of OpenHarmony-powered smart devices. It allows on-demand component customization, as well as code editing, compilation, burning, and debugging. The tool supports C and C++ languages and can be installed in Visual Studio Code as a plug-in.| [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/documentation/guide/service_introduction-0000001050166905)|
+| Docker | A containerization platform used to build and containerize applications. The Docker environments in OpenHarmony encapsulate compilation toolchains for different OpenHarmony variants, so you can start your building straightaway without having to install the compilation toolchain on your own.| [Docker Environment](gettools-acquire.md)|

en/device-dev/bundles/Readme-EN.md → en/device-dev/hpm-part/Readme-EN.md

-# Bundles
+# HPM Part
 
 - [HPM Part Overview](hpm-part-about.md)
 - [HPM Part Development](hpm-part-development.md)

en/device-dev/bundles/hpm-part-reference.md → en/device-dev/hpm-part/hpm-part-reference.md

@@ -157,22 +157,22 @@ You can use the hpm-cli tool to manage the lifecycle of an HPM Part. The followi
 | -------- | -------- | -------- |
 | Querying version information| **hpm -V** or **hpm --version**| Displays the version of the hpm-cli tool.| 
 | Querying help information| **hpm -h** or **hpm --version**| Displays the command list and help information.| 
-| hpm -h | Displays command help information.| 
+|| hpm -h | Displays command help information.| 
 | Creating a project| hpm init bundle | Creates an HPM Part project.| 
-| hpm init -t template | Creates a scaffolding project from a template.| 
+|| hpm init -t template | Creates a scaffolding project from a template.| 
 | Installing HPM Parts| **hpm install** or **hpm i**| Installs dependent HPM Parts in the bundle.json file.| 
-| hpm install bundle\@version | Installs HPM Parts of a specified version.| 
+|| hpm install bundle\@version | Installs HPM Parts of a specified version.| 
 | Uninstalling HPM Parts| hpm uninstall bundle | Uninstalls dependent HPM Parts.| 
-| **hpm remove** or **hpm rm bundlename**| Uninstalls dependent HPM Parts.| 
+|| **hpm remove** or **hpm rm bundlename**| Uninstalls dependent HPM Parts.| 
 | Viewing information| **hpm list** or **hpm ls**| Displays the dependency tree of the HPM part.| 
-| hpm dependencies | Generates the dependency relationship data of the HPM Part. (This command is also integrated in the **hpm ui** command. After you run the hpm ui command, a hpm UI is displayed with the dependencies.)| 
+|| hpm dependencies | Generates the dependency relationship data of the HPM Part. (This command is also integrated in the **hpm ui** command. After you run the hpm ui command, a hpm UI is displayed with the dependencies.)| 
 | Searching for HPM Parts| hpm search name | Searches for HPM Parts. **--json** is used to specify the search result in JSON format, and **-type** is used to set the target type, which can be **part**, **distribution**, or **code-segment**.| 
 | Setting HPM configuration items| hpm config set key value | Sets configuration items, such as the server address and network proxy.| 
-| hpm config delete key | Deletes configurations.| 
+|| hpm config delete key | Deletes configurations.| 
 | Updating HPM Part versions| hpm update | Updates the versions of dependent HPM Parts.| 
-| hpm check-update | Checks whether version updates are available to dependent HPM Parts.| 
+|| hpm check-update | Checks whether version updates are available to dependent HPM Parts.| 
 | Building| hpm build | Builds an HPM Part.| 
-| hpm dist | Builds a distribution. The build depends on the **dist** script in **scripts** of **bundle.json**.| 
+|| hpm dist | Builds a distribution. The build depends on the **dist** script in **scripts** of **bundle.json**.| 
 | Packing | hpm pack | Packs dependencies of local HPM Parts.| 
 | Burning| hpm run flash | Burns the firmware. The firmware burning depends on the **flash** script in **scripts** of **bundle.json**.| 
 | Publishing| hpm publish | Publishes an HPM Part, which must be unique in the repository and has a unique version. (An account is required for login.)| 
@@ -242,7 +242,7 @@ HPM Part dependencies (including indirect dependencies) can be displayed by runn
 ```
 $ hpm list
 +--demo@1.0.0
-| +--@huawei/media@1.0.2
+| +--@example/media@1.0.2
 | +--@demo/sport_hi3518ev300_liteos_a@1.0.0
 | | +--@demo/app@4.0.1
 | | | +--@demo/build@4.0.1

en/device-dev/kernel/Readme-EN.md

@@ -172,5 +172,10 @@
 
 - [Kernel for Standard Systems](kernel-standard.md)
   - [Linux Kernel Overview](kernel-standard-overview.md)
-  - [Applying Patches on OpenHarmony Development Boards](kernel-standard-patch.md)
-  - [Guidelines for Building the Linux Kernel](kernel-standard-build.md)
+  - [Applying Patches on Development Boards](kernel-standard-patch.md)
+  - [Compiling and Building the Linux Kernel](kernel-standard-build.md)
\ No newline at end of file
+  - [Enhanced Kernel Features](kernel-standard-enhanced-features.md)
+    - [Enhanced SWAP](kernel-standard-mm-eswap.md)
+    - [Task Scheduling](kernel-standard-sched.md)
+      - [Related Thread Group](kernel-standard-sched-rtg.md)
+      - [Lightweight CPU Isolation](kernel-standard-sched-cpuisolation.md)         
\ No newline at end of file

en/device-dev/kernel/kernel-standard-build.md

-# Guidelines for Compiling and Building the Linux Kernel<a name="EN-US_TOPIC_0000001076416924"></a>
+# Compiling and Building the Linux Kernel<a name="EN-US_TOPIC_0000001076416924"></a>
 
 -   [Example 1](#section19369206113115)
 

en/device-dev/kernel/kernel-standard-enhanced-features.md

+# Enhanced Kernel Features
+
+- **[Memory Management](kernel-standard-mm.md)**
+- **[Task Scheduling](kernel-standard-sched.md)**

en/device-dev/kernel/kernel-standard-mm.md

+# Memory Management
+
+- **[Enhanced Swap] (kernel-standard-mm-eswap.md)**

en/device-dev/kernel/kernel-standard-patch.md

-# Guidelines for Using Patches on OpenHarmony Development Boards<a name="EN-US_TOPIC_0000001081980461"></a>
+# Applying Patches on Development Boards<a name="EN-US_TOPIC_0000001081980461"></a>
 
 1.  Apply the HDF patches.
 

en/device-dev/kernel/kernel-standard-sched.md

+# Task Scheduling
+
+- **[Related Thread Group](kernel-standard-sched-rtg.md)**
+- **[Lightweight CPU Isolation](kernel-standard-sched-cpuisolation.md)**