update docs

Signed-off-by: NAnnie_wang <annie.wangli@huawei.com>

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

@@ -28,7 +28,7 @@ struct GpioMethod {
   int32_t (*unsetIrq)(struct GpioCntlr *cntlr, uint16_t local);
   int32_t (*enableIrq)(struct GpioCntlr *cntlr, uint16_t local);
   int32_t (*disableIrq)(struct GpioCntlr *cntlr, uint16_t local);
-}
+};
 ```
 
   **Table 1** Description of the callback functions in GpioMethod

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

@@ -46,13 +46,13 @@ The figure below shows a simplified CSI. The D-PHY transmits data by using one p
 
 <a name="table3_MIPI_CSIDes"></a>
 
-  | Category| API| 
+| Category| API|
 | -------- | -------- |
 | Opening or closing the MIPI CSI controller operation handle| **MipiCsiOpen**: opens the MIPI CSI controller operation handle.<br>**MipiCsiClose**: closes the MIPI CSI controller operation handle.|
-| Setting MIPI CSI parameters| **MipiCsiSetComboDevAttr**: sets parameters of the MIPI, CMOS, or LVDS camera to the controller. The parameters include the working mode, image area, image depth, data rate, and physical channel.<br>**MipiCsiSetExtDataType** (optional): sets the YUV and RAW data formats and bit depths.<br>**MipiCsiSetHsMode**: sets the MIPI RX lane distribution. Set the mode based on the hardware connection.<br>**MipiCsiSetPhyCmvmode**: sets the common-mode voltage (CMV) mode.| 
+| Setting MIPI CSI attributes | **MipiCsiSetComboDevAttr**: sets attributes of the MIPI, CMOS, or LVDS camera to the controller. The attributes include the working mode, image area, image depth, data rate, and physical channel.<br>**MipiCsiSetExtDataType** (optional): sets the YUV and RAW data formats and bit depths.<br>**MipiCsiSetHsMode**: sets the MIPI RX lane distribution. Set the mode based on the hardware connection.<br>**MipiCsiSetPhyCmvmode**: sets the common-mode voltage (CMV) mode. |
 | Resetting a sensor or deasserting the reset of a sensor| **MipiCsiResetSensor**: resets a sensor.<br>**MipiCsiUnresetSensor**: deasserts the reset of a sensor.|
 | Resetting the MIPI RX or deasserting the reset of the MIPI RX| **MipiCsiResetRx**: resets the MIPI&amp;nbsp;RX. The value of **enSnsType** varies depending on the value of **s32WorkingViNum**.<br>**MipiCsiUnresetRx**: deasserts the reset on the MIPI&amp;nbsp;RX.|
-| Enabling or disabling the MIPI Clock| **MipiCsiEnableClock**: enables the MIPI clock. The **enSnsType** passed by the upper-layer function during electrophoresis determines whether MIPI or LVDS is used.<br>**MipiCsiDisableClock**: disables the MIPI clock.| 
+| Enabling or disabling the MIPI clock| **MipiCsiEnableClock**: enables the MIPI clock. The **enSnsType** passed by the upper-layer function during electrophoresis determines whether MIPI or LVDS is used.<br>**MipiCsiDisableClock**: disables the MIPI clock.|
 | Enabling or disabling the MIPI sensor clock| **MipiCsiEnableSensorClock**: enables the MIPI sensor clock.<br>**MipiCsiDisableSensorClock**: disables the MIPI sensor clock.|
 
 
@@ -90,7 +90,7 @@ For example, open the controller operation handle of MIPI CSI lane 0:
 
 ```c
 DevHandle mipiCsiHandle = NULL;  /* Device handle */
-id = 0; /* MIPI CSI lane ID*/
+id = 0; /* MIPI CSI lane ID */
 
 /* Open the controller operation handle. */
 MipiCsiHandle = MipiCsiOpen(id);

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

@@ -198,9 +198,11 @@ The following uses **mipi_rx_hi35xx.c** as an example to present the information
 - Init function
 
    **Input parameter**:
+   
   **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information.
    
    **Return value**:
+   
    HDF_STATUS<br/>The table below describes some status. For more information, see **HDF_STATUS** in the **/drivers/framework/include/utils/hdf_base.h** file.
 
 
@@ -214,6 +216,7 @@ The following uses **mipi_rx_hi35xx.c** as an example to present the information
    | HDF_FAILURE            |   Operation failed.  |
 
    **Function description**:
+
    Attaches the **MipiCsiCntlrMethod** instance, calls **MipiCsiRegisterCntlr**, and initializes the custom structure.
 
 
@@ -283,13 +286,18 @@ The following uses **mipi_rx_hi35xx.c** as an example to present the information
 - Release function
 
    **Input parameter**:
+   
   **HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information.
    
    **Return value**:
+  
    No value is returned.
    
   **Function description**:
-   Releases the memory and deletes the controller. This function assigns values to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the value assignment operations.
+  
+  Releases the memory and deletes the controller. This function assigns values to the **Release** API in the driver entry structure. When the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. 
+  
+  All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the value assignment operations.
   
   ```c
   static void Hi35xxMipiCsiRelease(struct HdfDeviceObject *device)

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

@@ -3,7 +3,7 @@
 
 ## Overview
 
-In the Hardware Driver Foundation (HDF) framework, the MultiMedia Card (MMC) uses the independent service mode for API adaptation.  In this mode, each device independently publishes a service to process external access requests. When receiving an access request, the HDF DeviceManager extracts parameters from the request to call the internal APIs of the target device. In the independent service mode, the HDF DeviceManager provides service management capabilities. However, you need to configure a node for each device to increase memory resources.
+In the Hardware Driver Foundation (HDF), the MultiMedia Card (MMC) uses the independent service mode for API adaptation.  In this mode, each device independently publishes a service to process external access requests. When receiving an access request, the HDF DeviceManager extracts parameters from the request to call the internal APIs of the target device. In the independent service mode, the HDF DeviceManager provides service management capabilities. However, you need to configure a node for each device to increase memory resources.
 
   **Figure 1** Independent service mode
 
@@ -52,7 +52,7 @@ struct MmcCntlrOps {
 | devReadOnly | **cntlr**: structure pointer to the MMC controller at the core layer.| Boolean value| Checks whether the device is read-only.|
 | cardPluged | **cntlr**: structure pointer to the MMC controller at the core layer.| Boolean value| Checks whether the device is removed.|
 | devBusy | **cntlr**: structure pointer to the MMC controller at the core layer.| Boolean value| Checks whether the device is being used.|
-| tune | **cntlr**: structure pointer to the MMC controller at the core layer.<br>**cmdCode**: command code of the uint32_t type.| HDF_STATUS| Tunes the MMC controller.| 
+| tune | **cntlr**: structure pointer to the MMC controller at the core layer.<br>**cmdCode**: command code of the uint32_t type.| HDF_STATUS| Tunes the oscillator circuit frequency. |
 | rescanSdioDev | **cntlr**: structure pointer to the MMC controller at the core layer.| HDF_STATUS| Scans and adds an SDIO device.|
 
 
@@ -75,6 +75,7 @@ The MMC module adaptation involves the following steps:
       > For details about the functions in **MmcCntlrOps**, see [Available APIs](#available-apis).
 
 4. Debug the driver.
+   
    (Optional) For new drivers, verify the basic functions, for example, verify the information returned after the **MmcCntlrOps** instance is attached and whether the device starts successfully.
 
 
@@ -82,7 +83,7 @@ The MMC module adaptation involves the following steps:
 
 The following uses **himci.c** as an example to present the information required for implementing device functions.
 
-1. Instantiate the driver entry.<br/>The driver entry must be a global variable of the **HdfDriverEntry** type (defined in **hdf_device_desc.h**), and the value of **moduleName** must be the same as that in **device_info.hcs**. In the HDF framework, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
+1. Instantiate the driver entry.<br/>The driver entry must be a global variable of the **HdfDriverEntry** type (defined in **hdf_device_desc.h**), and the value of **moduleName** must be the same as that in **device_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers is collected to form a segment address space similar to an array for the upper layer to invoke.
 
    Generally, the HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, the HDF calls **Release** to release driver resources and exit.
 
@@ -99,8 +100,10 @@ The following uses **himci.c** as an example to present the information required
    HDF_INIT(g_mmcDriverEntry);           // Call HDF_INIT to register the driver entry with the HDF.
    ```
 
-2. Add the **deviceNode** information to the **device_info.hcs** file and configure the device attributes in the **mmc_config.hcs** file. The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **MmcCntlr** members at the core layer.
-     If there are multiple devices, you need to add the **deviceNode** information to the **device_info** file and add the device attributes to the **mmc_config** file for each device. 
+2. Add the **deviceNode** information to the **device_info.hcs** file and configure the device attributes in the **mmc_config.hcs** file. 
+     
+   The **deviceNode** information is related to registration of the driver entry. The device attribute values are closely related to the default values or value ranges of the **MmcCntlr** members at the core layer. If there are multiple devices, you need to add the **deviceNode** information to the **device_info** file and add the device attributes to the **mmc_config** file for each device. 
+   
    - **device_info.hcs** configuration example
    
      
@@ -340,7 +343,7 @@ The following uses **himci.c** as an example to present the information required
 
       HDF_STATUS
 
-      Function description:
+      **Function description**:
 
       Implements **ProcMciInit**.