@@ -143,7 +143,7 @@ The following uses **gpio_hi35xx.c** as an example to present the information re
...
@@ -143,7 +143,7 @@ The following uses **gpio_hi35xx.c** as an example to present the information re
3. Initialize the **GpioCntlr** object at the core layer, including defining a custom structure (to pass parameters and data) and implementing the **HdfDriverEntry** member functions (**Init** and **Release**) to instantiate **GpioMethod** in **GpioCntlr** (so that the underlying driver functions can be called).
3. Initialize the **GpioCntlr** object at the core layer, including defining a custom structure (to pass parameters and data) and implementing the **HdfDriverEntry** member functions (**Init** and **Release**) to instantiate **GpioMethod** in **GpioCntlr** (so that the underlying driver functions can be called).
- Defining a custom structure
- Defining a custom structure
To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **gpio_config.hcs** file to initialize the members in the custom structure and pass important parameters, such as the GPIO group number and the number of pins, to the **GpioCntlr** object at the core layer.
To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **gpio_config.hcs** file to initialize the members in the custom structure and passes important parameters, such as the GPIO group number and the number of pins, to the **GpioCntlr** object at the core layer.
@@ -9,19 +9,19 @@ High Definition Multimedia Interface (HDMI) is an audio and video transmission p
...
@@ -9,19 +9,19 @@ High Definition Multimedia Interface (HDMI) is an audio and video transmission p
### Basic Concepts
### Basic Concepts
- TMDS is used to transmit audio, video, and various auxiliary data.
- TMDS<br>Transmits audio, video, and various auxiliary data.
- Display data channel (DDC) allows the TX and RX ends to obtain the transmitting and receiving capabilities. However, HDMI only needs to unidirectionally obtain the capabilities of the RX end (display).
- Display data channel (DDC)<br>Allows the TX and RX ends to obtain the transmitting and receiving capabilities. However, HDMI only needs to unidirectionally obtain the capabilities of the RX end (display).
- Consumer Electronics Control (CEC) enables interaction between the HDMI TX and RX devices.
- Consumer Electronics Control (CEC)<br> Enables interaction between the HDMI TX and RX devices.
- Fixed rate link (FRL) allows the maximum TMDS bandwidth to be increased from 18 Gbit/s to 48 Gbit/s.
- Fixed rate link (FRL)<br>Allows the maximum TMDS bandwidth to be increased from 18 Gbit/s to 48 Gbit/s.
- High-bandwidth Digital Content Protection (HDCP) prevents copying of digital audio and video content being transmitted across devices.
- High-bandwidth Digital Content Protection (HDCP)<br>Prevents copying of digital audio and video content being transmitted across devices.
### Working Principles
### Working Principles
In the HDF, the HDMI module 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 HDF, the HDMI module 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, which increases memory usage.
**Figure 1** Independent service mode
**Figure 1** Independent service mode
...
@@ -121,18 +121,18 @@ struct HdmiCntlrOps {
...
@@ -121,18 +121,18 @@ struct HdmiCntlrOps {
The HDMI module adaptation involves the following steps:
The HDMI module adaptation involves the following steps:
- Instantiate the driver entry.
1. Instantiate the driver entry.
- Instantiate the **HdfDriverEntry** structure.
- Instantiate the **HdfDriverEntry** structure.
- Call **HDF_INIT** to register the **HdfDriverEntry** instance with the HDF.
- Call **HDF_INIT** to register the **HdfDriverEntry** instance with the HDF.
2. Configure attribute files.
- Configure attribute files.
- Add the **deviceNode** information to the **device_info.hcs** file.
- Add the **deviceNode** information to the **device_info.hcs** file.
- (Optional) Add the **hdmi_config.hcs** file.
- (Optional) Add the **hdmi_config.hcs** file.
3. Instantiate the HDMI controller object.
- Instantiate the HDMI controller object.
- Initialize **HdmiCntlr**.
- Initialize **HdmiCntlr**.
- Instantiate **HdmiCntlrOps** in **HdmiCntlr**.
- Instantiate **HdmiCntlrOps** in **HdmiCntlr**.
### Development Example
1. Instantiate the driver entry.
1. Instantiate the driver entry.
The driver entry must be a global variable of the **HdfDriverEntry** type (which is 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.
The driver entry must be a global variable of the **HdfDriverEntry** type (which is 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.
...
@@ -158,7 +158,7 @@ The HDMI module adaptation involves the following steps:
...
@@ -158,7 +158,7 @@ The HDMI module adaptation involves the following steps:
Configure HDMI controller information from the first node. This node specifies a type of HDMI controllers rather than a specific HDMI controller. In this example, there is only one HDMI controller. If there are multiple HDMI controllers, you need to add the **deviceNode** information to the **device_info** file and add the corresponding device attributes to the **hdmi_config** file.
Configure HDMI controller information from the first node. This node specifies a type of HDMI controllers rather than a specific HDMI controller. In this example, there is only one HDMI controller. If there are multiple HDMI controllers, you need to add the **deviceNode** information to the **device_info** file and add the corresponding device attributes to the **hdmi_config** file.
- **device_info.hcs** configuration example:
- **device_info.hcs** configuration example
```c
```c
root {
root {
...
@@ -177,7 +177,7 @@ The HDMI module adaptation involves the following steps:
...
@@ -177,7 +177,7 @@ The HDMI module adaptation involves the following steps:
}
}
```
```
- **hdmi_config.hcs** configuration example:
- **hdmi_config.hcs** configuration example
```c
```c
root {
root {
...
@@ -235,7 +235,7 @@ The HDMI module adaptation involves the following steps:
...
@@ -235,7 +235,7 @@ The HDMI module adaptation involves the following steps:
> To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **hdmi_config.hcs** file to initialize the members in the custom structure and pass important parameters, such as the device number and bus number, to the **HdmiCntlr** object at the core layer.
> To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **hdmi_config.hcs** file to initialize the members in the custom structure and passes important parameters, such as the device number and bus number, to the **HdmiCntlr** object at the core layer.
The Display Serial Interface \(DSI\) is a specification stipulated by the Mobile Industry Processor Interface \(MIPI\) Alliance, aiming to reduce the cost of display controllers in a mobile device. It defines a serial bus and communication protocol among the host, the source of image data, and the target device. In this way, the DSI can send pixel data or commands to peripherals \(usually LCDs or similar display devices\) in serial mode, or reads information such as status and pixel from the peripherals.
The Display Serial Interface (DSI) is a specification stipulated by the Mobile Industry Processor Interface (MIPI) Alliance, aiming to reduce the cost of display controllers in a mobile device. It defines a serial bus and communication protocol among the host, the source of image data, and the target device. In this way, the DSI can send pixel data or commands to peripherals (usually LCDs or similar display devices) in serial mode, or reads information such as status and pixel from the peripherals.
MIPI DSI is capable of working in both high speed (HS) mode and low power (LP) mode. All data lanes can only travel from the DSI host to a peripheral in HS mode, except the first data lane, which can also receive data such as status information and pixels from the peripheral in LP mode. The clock lane is dedicated to transmitting synchronization clock signals in HS mode.
MIPI DSI is capable of working in both high speed \(HS\) mode and low power \(LP\) mode. All data lanes can only travel from the DSI host to a peripheral in HS mode, except the first data lane, which can also receive data such as status information and pixels from the peripheral in LP mode. The clock lane is dedicated to transmitting synchronization clock signals in HS mode.
The figure below shows a simplified DSI interface. Conceptually, a DSI-compliant interface has the same features as interfaces complying with DBI-2 and DPI-2 standards. It sends pixels or commands to a peripheral and can read status or pixel information from the peripheral. The main difference is that the DSI serializes all pixel data, commands, and events that, in traditional interfaces, are conveyed to and from the peripheral on a parallel data bus with additional control signals.
[Figure 1](#fig1122611461203) shows a simplified DSI interface. Conceptually, a DSI-compliant interface has the same features as interfaces complying with DBI-2 and DPI-2 standards. It sends pixels or commands to a peripheral and can read status or pixel information from the peripheral. The main difference is that the DSI serializes all pixel data, commands, and events that, in traditional interfaces, are conveyed to and from the peripheral on a parallel data bus with additional control signals.
**Figure 1** DSI transmitting and receiving interface<aname="fig1122611461203"></a>
<tdclass="cellrowborder"valign="top"width="44.47%"headers="mcps1.2.4.1.3 "><pid="p919911233240"><aname="p919911233240"></a><aname="p919911233240"></a>Sets configuration parameters for a MIPI DSI device.</p>
<tdclass="cellrowborder"valign="top"headers="mcps1.2.4.1.2 "><pid="p1119919235248"><aname="p1119919235248"></a><aname="p1119919235248"></a>Obtains configuration parameters of a MIPI DSI device.</p>
<tdclass="cellrowborder"valign="top"headers="mcps1.2.4.1.2 "><pid="p520062313249"><aname="p520062313249"></a><aname="p520062313249"></a>Releases a specified MIPI DSI device handle.</p>
</td>
</tr>
<trid="row7200152382417"><tdclass="cellrowborder"rowspan="2"valign="top"width="26.619999999999997%"headers="mcps1.2.4.1.1 "><pid="p8200202312241"><aname="p8200202312241"></a><aname="p8200202312241"></a>Setting the LP or HS mode</p>
<tdclass="cellrowborder"valign="top"width="44.47%"headers="mcps1.2.4.1.3 "><pid="p16200192319240"><aname="p16200192319240"></a><aname="p16200192319240"></a>Sets LP mode for a MIPI DSI device.</p>
<tdclass="cellrowborder"valign="top"headers="mcps1.2.4.1.2 "><pid="p22001423192418"><aname="p22001423192418"></a><aname="p22001423192418"></a>Sets HS mode for a MIPI DSI device.</p>
<tdclass="cellrowborder"valign="top"width="44.47%"headers="mcps1.2.4.1.3 "><pid="p1020082319243"><aname="p1020082319243"></a><aname="p1020082319243"></a>Sends a display command set (DCS) command for sending data.</p>
<tdclass="cellrowborder"valign="top"headers="mcps1.2.4.1.2 "><pid="p9200102312249"><aname="p9200102312249"></a><aname="p9200102312249"></a>Receives a DCS command for reading data with the specified length.</p>
</td>
</tr>
</tbody>
</table>
> **NOTE**<br> All functions described in this document can be called only in kernel space.
## Usage Guidelines
## Usage Guidelines
### How to Use
### How to Use
The figure below illustrates how to use the APIs.
The figure below shows the general process of using the MIPI DSI driver APIs.
**Figure 2** Using MIPI DSI driver APIs
**Figure 2** Using MIPI DSI driver APIs
### Obtaining a MIPI DSI Device Handle<a name="section5126155683811"></a>
### Opening a MIPI DSI Device Handle
Before performing MIPI DSI communication, obtain a MIPI DSI device handle by calling **MipiDsiOpen**. This function returns a MIPI DSI device handle with a specified channel ID.
Before performing MIPI DSI communication, open a MIPI DSI device handle by calling **MipiDsiOpen()**. This function returns the MIPI DSI device handle of the specified channel ID.
<tdclass="cellrowborder"valign="top"width="79.34%"headers="mcps1.2.3.1.2 "><pid="p760471912388"><aname="p760471912388"></a><aname="p760471912388"></a>Failed to receive the specified command.</p>
<tdclass="cellrowborder"valign="top"width="79.34%"headers="mcps1.2.3.1.2 "><pid="p3604181933818"><aname="p3604181933818"></a><aname="p3604181933818"></a>MIPI DSI device handle with a specified channel ID, whose data type is <strongid="b643184319293"><aname="b643184319293"></a><aname="b643184319293"></a>DevHandle</strong>.</p>
</td>
</tr>
</tbody>
</table>
The following example shows how to obtain a MIPI DSI device handle with the channel ID **0**:
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p11691554280"><aname="p11691554280"></a><aname="p11691554280"></a>Failed to set MIPI DSI configuration parameters.</p>
</td>
</tr>
</tbody>
</table>
```
### Setting MIPI DSI Attributes
int32_t ret;
struct MipiCfg cfg = {0};
- Call **MipiDsiSetCfg()** to set MIPI DSI attributes.
/* Configuration parameters of the connected device are as follows: */
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p171195516285"><aname="p171195516285"></a><aname="p171195516285"></a>Succeeded in receiving the specified command.</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p77116555286"><aname="p77116555286"></a><aname="p77116555286"></a>Failed to receive the specified command.</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p7282752412"><aname="p7282752412"></a><aname="p7282752412"></a>Pointer to the command to be sent.</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p1231981611712"><aname="p1231981611712"></a><aname="p1231981611712"></a>Succeeded in sending the specified command.</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p93191161174"><aname="p93191161174"></a><aname="p93191161174"></a>Failed to send the specified command.</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p0706424183610"><aname="p0706424183610"></a><aname="p0706424183610"></a>Pointer to the command to be received.</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p564617356360"><aname="p564617356360"></a><aname="p564617356360"></a>Length of the data to read.</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p91991042143618"><aname="p91991042143618"></a><aname="p91991042143618"></a>Pointer to the read data.</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p62324353251"><aname="p62324353251"></a><aname="p62324353251"></a>Succeeded in receiving the specified command.</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p323283510252"><aname="p323283510252"></a><aname="p323283510252"></a>Failed to receive the specified command.</p>
The Display Serial Interface \(DSI\) is a specification developed by the Mobile Industry Processor Interface \(MIPI\) Alliance to reduce the cost of display controllers in mobile devices. In the Hardware Driver Foundation (HDF) framework, the MIPI DSI module uses the service-free mode for API adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS system that does not distinguish the user mode and the kernel mode. In the service-free mode, **DevHandle**\(a void pointer\) directly points to the kernel-mode address of the device object.
The Display Serial Interface (DSI) is a specification developed by the Mobile Industry Processor Interface (MIPI) Alliance to reduce the cost of display controllers in mobile devices. In the Hardware Driver Foundation (HDF), the MIPI DSI module uses the service-free mode for API adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the operating system (OS) that does not distinguish the user mode and the kernel mode. In the service-free mode, **DevHandle** (a void pointer) directly points to the kernel-mode address of the device object.
| setCmd | **cntlr**: structure pointer to the MIPI DSI controller.<br>cmd: structure pointer to the commands to send.| –| HDF_STATUS| Sends commands to a display device.|
</th>
| getCmd | **cntlr**: structure pointer to the MIPI DSI controller.<br>**cmd**: pointer to the command description structure.<br>**readLen**: length of the data to read.| **out**: structure pointer to the data obtained.| HDF_STATUS| Reads data by sending commands.|
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.2 "><pid="p1518931041716"><aname="p1518931041716"></a><aname="p1518931041716"></a><strongid="b14872821599"><aname="b14872821599"></a><aname="b14872821599"></a>cntlr</strong>: structure pointer to the MIPI DSI controller.</p>
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.2 "><pid="p177917412215"><aname="p177917412215"></a><aname="p177917412215"></a><strongid="b4791144113213"><aname="b4791144113213"></a><aname="b4791144113213"></a>cntlr</strong>: structure pointer to the MIPI DSI controller. </p>
<pid="p12189131018174"><aname="p12189131018174"></a><aname="p12189131018174"></a><strongid="b192414338012"><aname="b192414338012"></a><aname="b192414338012"></a>cmd</strong>: structure pointer to the input instruction.</p>
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.5 "><pid="p15190110141710"><aname="p15190110141710"></a><aname="p15190110141710"></a>Sends instructions to a display device.</p>
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.2 "><pid="p121902101179"><aname="p121902101179"></a><aname="p121902101179"></a><strongid="b516432716114"><aname="b516432716114"></a><aname="b516432716114"></a>cntlr</strong>: structure pointer to the MIPI DSI controller.</p>
</td>
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.3 "><pid="p1519018101171"><aname="p1519018101171"></a><aname="p1519018101171"></a>cmd: structure pointer to the instruction to output.</p>
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.5 "><pid="p519061031710"><aname="p519061031710"></a><aname="p519061031710"></a>Reads instructions from the display device.</p>
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.2 "><pid="p151906102178"><aname="p151906102178"></a><aname="p151906102178"></a><strongid="b159559351014"><aname="b159559351014"></a><aname="b159559351014"></a>cntlr</strong>: structure pointer to the MIPI DSI controller.</p>
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.5 "><pid="p2190310101715"><aname="p2190310101715"></a><aname="p2190310101715"></a>Sets the high-speed mode.</p>
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.2 "><pid="p819121011714"><aname="p819121011714"></a><aname="p819121011714"></a><strongid="b189629351219"><aname="b189629351219"></a><aname="b189629351219"></a>cntlr</strong>: structure pointer to the MIPI DSI controller.</p>
<tdclass="cellrowborder"valign="top"width="20%"headers="mcps1.2.6.1.5 "><pid="p1919121091712"><aname="p1919121091712"></a><aname="p1919121091712"></a>Sets the low-power mode.</p>
</td>
</tr>
</tbody>
</table>
## How to Develop<a name="section545182932161538"></a>
The MIPI DSI module adaptation involves the following steps:
The MIPI DSI module adaptation involves the following steps:
1. Instantiate the driver entry.
1. Instantiate the driver entry.
- Instantiate the **HdfDriverEntry** structure.
- Instantiate the **HdfDriverEntry** structure.
- Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
- Call **HDF_INIT** to register the **HdfDriverEntry** instance with the HDF.
2. Configure attribute files.
2. Configure attribute files.
- Add the **deviceNode** information to the **device\_info.hcs** file.
- Add the **deviceNode** description to the **device_info.hcs** file.
-\(Optional\) Add the **mipidsi\_config.hcs** file.
- (Optional) Add the **mipidsi_config.hcs** file.
3. Instantiate the MIPI DSI controller object.
3. Instantiate the MIPI DSI controller object.
- Initialize **MipiDsiCntlr**.
- Initialize **MipiDsiCntlr**.
- Instantiate **MipiDsiCntlrMethod** in the **MipiDsiCntlr** object.
- Instantiate **MipiDsiCntlrMethod** in the **MipiDsiCntlr** object.
> For details about the functions in **MipiDsiCntlrMethod**, see [Available APIs](#available-apis).
For details, see [Available APIs](#available-apis).
4. Debug the driver.
(Optional) For new drivers, verify basic functions, for example, check the information returned after the driver is attached and whether data is successfully transmitted.
4.\(Optional\) Debug the driver.
For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
## Development Example
## Development Example<a name="section1167576616161538"></a>
The following uses **mipi_tx_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement device functions.
1. Configure the device attributes in **xx_config.hcs** and add the **deviceNode** information to the **device_info.hcs** file. <br>The device attribute values are closely related to the default values or value range of the **MipiDsiCntlr** members at the core layer. The **deviceNode** information is related to the driver entry registration.
1. Generally, you need to configure the device attributes in **xx\_config.hcs** and add the **deviceNode** information to the **device\_info.hcs** file. The device attribute values are closely related to the default values or value range of the **MipiDsiCntlr** members at the core layer. The **deviceNode** information is related to the driver entry registration.
In this example, no additional attribute needs to be configured for the MIPI DSI controller. If required, add the **deviceMatchAttr** information to **deviceNode** in the **device_info** file and add the **mipidsi_config** file.
In this example, no additional attribute needs to be configured for the MIPI DSI controller. If required, you need to add the **deviceMatchAttr** information to **deviceNode** in the **device\_info** file and add the **mipidsi\_config** file.
**device_info.hcs** configuration example:
- **device\_info.hcs** configuration reference
```
```
root {
root {
...
@@ -145,8 +84,8 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
...
@@ -145,8 +84,8 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
policy = 0;
policy = 0;
priority = 150;
priority = 150;
permission = 0644;
permission = 0644;
moduleName = "HDF_MIPI_TX"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
moduleName = "HDF_MIPI_TX"; // (Mandatory) Driver name, which must be the same as moduleName in the driver entry.
serviceName = "HDF_MIPI_TX";// (Mandatory) Unique name of the service published by the driver
serviceName = "HDF_MIPI_TX"; // (Mandatory) Unique name of the service published by the driver.
}
}
}
}
}
}
...
@@ -154,26 +93,26 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
...
@@ -154,26 +93,26 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
}
}
```
```
2. Instantiate the driver entry. 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**. The function pointer members of the **HdfDriverEntry** structure are filled by the vendors' operation functions. 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.
2. 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**. The function pointer members in the **HdfDriverEntry** structure are filled by the vendors' operation functions. 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.
Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
- MIPI DSI driver entry reference
- MIPI DSI driver entry example
```
```
struct HdfDriverEntry g_mipiTxDriverEntry = {
struct HdfDriverEntry g_mipiTxDriverEntry = {
.moduleVersion = 1,
.moduleVersion = 1,
.Init = Hi35xxMipiTxInit, // See the Init function.
.Init = Hi35xxMipiTxInit, // See the Init function.
.Release = Hi35xxMipiTxRelease, //See the Release function.
.Release = Hi35xxMipiTxRelease, // See the Release function.
.moduleName = "HDF_MIPI_TX", // (Mandatory) The value must be the same as that in the device_info.hcs file.
.moduleName = "HDF_MIPI_TX", // (Mandatory) The value must be the same as that in the device_info.hcs file.
};
};
HDF_INIT(g_mipiTxDriverEntry); // Call HDF_INIT to register the driver entry with the HDF framework.
HDF_INIT(g_mipiTxDriverEntry); // Call HDF_INIT to register the driver entry with the HDF.
```
```
3. Initialize the **MipiDsiCntlr** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **MipiDsiCntlrMethod**\(used to call underlying functions of the driver\) in **MipiDsiCntlr**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
3. Initialize the **MipiDsiCntlr** object at the core layer, including defining a custom structure (to pass parameters and data) and implementing the **HdfDriverEntry** member functions (**Bind**, **Init** and **Release**) to instantiate **MipiDsiCntlrMethod** in **MipiDsiCntlr** (so that the underlying driver functions can be called).
- Custom structure reference
- Defining a custom structure
To the driver, the custom structure holds parameters and data. Generally, the values in the **config** file are used to initialize the structure members. However, in this example, the MIPI DSI has no device attribute file. Therefore, the basic member structure is similar to that of **MipiDsiCntlr**.
To the driver, the custom structure carries parameters and data. The values in the **config** file are used to initialize the structure members. In this example, the MIPI DSI has no device attribute file. Therefore, the basic member structure is similar to that of **MipiDsiCntlr**.
```
```
typedef struct {
typedef struct {
...
@@ -183,11 +122,11 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
...
@@ -183,11 +122,11 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
VideoModeTag videoMode; // Synchronization mode of the display device
VideoModeTag videoMode; // Synchronization mode of the display device
OutputFormatTag outputFormat; // Format of the output DSI image, which can be RGB or YUV.
OutputFormatTag outputFormat; // Format of the output DSI image, which can be RGB or YUV.
SyncInfoTag syncInfo; // Settings related to timing
SyncInfoTag syncInfo; // Settings related to timing
unsigned int phyDataRate; // mbps
unsigned int phyDataRate; // Data rate, in Mbit/s
unsigned int pixelClk; // KHz
unsigned int pixelClk; // Clock, in kHz
} ComboDevCfgTag;
} ComboDevCfgTag;
// MipiDsiCntlr is the controller structure at the core layer. Its members are assigned with values by using the Init function.
// MipiDsiCntlr is the controller structure at the core layer. The Init function assigns values to the members of MipiDsiCntlr.
struct MipiDsiCntlr {
struct MipiDsiCntlr {
struct IDeviceIoService service;
struct IDeviceIoService service;
struct HdfDeviceObject *device;
struct HdfDeviceObject *device;
...
@@ -198,8 +137,8 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
...
@@ -198,8 +137,8 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
void *priv;
void *priv;
};
};
```
```
- Instantiating **MipiDsiCntlrMethod** in **MipiDsiCntlr** (other members are initialized by **Init**)
- Instantiate the callback function structure **MipiDsiCntlrMethod** in **MipiDsiCntlr**. Other members are initialized by using the Init function.
```
```
static struct MipiDsiCntlrMethod g_method = {
static struct MipiDsiCntlrMethod g_method = {
...
@@ -210,76 +149,46 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
...
@@ -210,76 +149,46 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
.toLp = Hi35xxToLp,
.toLp = Hi35xxToLp,
};
};
```
```
-**Init** function
**Input parameter**:
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information.
**Return value**:
HDF_STATUS<br>The table below lists some status. For more information, see HDF_STATUS in the /drivers/framework/include/utils/hdf_base.h file.
| Status| Description|
| -------- | -------- |
| HDF_ERR_INVALID_OBJECT | Invalid object.|
| HDF_ERR_MALLOC_FAIL | Failed to allocate memory.|
| HDF_ERR_INVALID_PARAM | Invalid parameter.|
| HDF_ERR_IO | I/O error.|
| HDF_SUCCESS | Operation successful.|
| HDF_FAILURE | Operation failed.|
**Function description**:
Attaches the **MipiDsiCntlrMethod** instance, calls **MipiDsiRegisterCntlr**, and performs other vendor-defined initialization operations.
- Init function
Input parameters:
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
g_mipiTx.priv = NULL; // g_mipiTx is a global variable.
g_mipiTx.priv = NULL; // g_mipiTx is a global variable defined.
// static struct MipiDsiCntlr g_mipiTx {
// static struct MipiDsiCntlr g_mipiTx {
// .devNo=0
// .devNo=0
// };
//};
g_mipiTx.ops = &g_method;// Connect to the MipiDsiCntlrMethod instance.
g_mipiTx.ops = &g_method;// Attach the MipiDsiCntlrMethod instance.
ret = MipiDsiRegisterCntlr(&g_mipiTx, device);// (Mandatory) Call the function at the core layer and g_mipiTx to initialize global variables at the core layer.
ret = MipiDsiRegisterCntlr(&g_mipiTx, device);// (Mandatory) Call the function at the core layer and g_mipiTx to initialize global variables at the core layer.
...
...
return MipiTxDrvInit(0); // (Mandatory) Device initialization customized by the vendor.
return MipiTxDrvInit(0); // (Mandatory) Device initialization customized by the vendor.
cntlr->device = device; // Enable conversion between HdfDeviceObject and MipiDsiHandle.
cntlr->device = device; // Prerequisites for conversion between HdfDeviceObject and MipiDsiHandle.
device->service = &(cntlr->service); // Enable conversion between HdfDeviceObject and MipiDsiHandle.
device->service = &(cntlr->service); // Prerequisites for conversion between HdfDeviceObject and MipiDsiHandle.
cntlr->priv = NULL;
cntlr->priv = NULL;
...
...
return HDF_SUCCESS;
return HDF_SUCCESS;
...
@@ -300,20 +209,20 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
...
@@ -300,20 +209,20 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the contents
return HDF_FAILURE;
return HDF_FAILURE;
}
}
```
```
-**Release** function
- Release function
**Input parameter**:
Input parameters:
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information.
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
**Return value**:
Return values:
No value is returned.
–
**Function description**:
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 corresponding value assignment operations.
Releases the memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. When the HDF framework 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 corresponding value assignment operations.
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.
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, which increases memory usage.
**Figure 1** Independent service mode
**Figure 1** Independent service mode
...
@@ -76,7 +76,7 @@ The MMC module adaptation involves the following steps:
...
@@ -76,7 +76,7 @@ The MMC module adaptation involves the following steps:
4. Debug the driver.
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.
(Optional) For new drivers, verify the basic functions, for example, check the information returned after the **MmcCntlrOps** instance is attached and whether the device starts successfully.
## Development Example
## Development Example
...
@@ -202,7 +202,7 @@ The following uses **himci.c** as an example to present the information required
...
@@ -202,7 +202,7 @@ The following uses **himci.c** as an example to present the information required
3. Initialize the **MmcCntlr** object at the core layer, including defining a custom structure (to pass parameters and data) and implementing the **HdfDriverEntry** member functions (**Bind**, **Init**, and **Release**) to instantiate **MmcCntlrOps** in **MmcCntlr** (so that the underlying driver functions can be called).
3. Initialize the **MmcCntlr** object at the core layer, including defining a custom structure (to pass parameters and data) and implementing the **HdfDriverEntry** member functions (**Bind**, **Init**, and **Release**) to instantiate **MmcCntlrOps** in **MmcCntlr** (so that the underlying driver functions can be called).
- Defining a custom structure
- Defining a custom structure
To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **mmc_config.hcs** file to initialize the members in the custom structure and pass important parameters to the **MmcCntlr** object at the core layer.
To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **mmc_config.hcs** file to initialize the members in the custom structure and passes important parameters to the **MmcCntlr** object at the core layer.
Pulse width modulation (PWM) is a technology that digitally encodes analog signal levels and converts them into pulses. It can be used for motor control and backlight brightness adjustment.
Pulse width modulation (PWM) is a technology that digitally encodes analog signal levels and converts them into pulses. It can be used for motor control and backlight brightness adjustment.
The PWM APIs provide a set of functions for operating a PWM device, including those for:
The PWM APIs provide a set of functions for operating a PWM device, including those for:
- Opening or closing a PWM device handle
- Opening or closing a PWM device handle
- Setting the PWM period, signal ON-state time, and polarity
- Setting the PWM period, signal ON-state time, and polarity
In the Hardware Driver Foundation \(HDF\), the Pulse Width Modulator \(PWM\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
## Overview
**Figure 1** Independent service mode<aname="fig983655084219"></a>
In the Hardware Driver Foundation (HDF), the Pulse Width Modulator (PWM) 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, which increases memory usage.
| setConfig | -**pwm**: structure pointer to the PWM controller at the core layer.<br>-**config**: structure pointer to the attributes to set.| HDF_STATUS| Sets attributes.|
<tdclass="cellrowborder"valign="top"width="25%"headers="mcps1.2.5.1.2 "><pid="p422655084417"><aname="p422655084417"></a><aname="p422655084417"></a><strongid="b25915520521"><aname="b25915520521"></a><aname="b25915520521"></a>pwm</strong>: structure pointer to the PWM controller at the core layer.</p>
<pid="p02275502443"><aname="p02275502443"></a><aname="p02275502443"></a><strongid="b138214155312"><aname="b138214155312"></a><aname="b138214155312"></a>config</strong>: structure pointer to the input attribute value.</p>
<tdclass="cellrowborder"valign="top"width="25%"headers="mcps1.2.5.1.2 "><pid="p2176941144314"><aname="p2176941144314"></a><aname="p2176941144314"></a><strongid="b53894825318"><aname="b53894825318"></a><aname="b53894825318"></a>pwm</strong>: structure pointer to the PWM controller at the core layer.</p>
<tdclass="cellrowborder"valign="top"width="25%"headers="mcps1.2.5.1.4 "><pid="p376133118453"><aname="p376133118453"></a><aname="p376133118453"></a>Starts the device.</p>
<tdclass="cellrowborder"valign="top"width="25%"headers="mcps1.2.5.1.2 "><pid="p1217694118437"><aname="p1217694118437"></a><aname="p1217694118437"></a><strongid="b839310895317"><aname="b839310895317"></a><aname="b839310895317"></a>pwm</strong>: structure pointer to the PWM controller at the core layer.</p>
<tdclass="cellrowborder"valign="top"width="25%"headers="mcps1.2.5.1.4 "><pid="p10893332114514"><aname="p10893332114514"></a><aname="p10893332114514"></a>Stops the device.</p>
</td>
</tr>
</tbody>
</table>
## How to Develop<a name="section967396342164144"></a>
The PWM module adaptation involves the following steps:
The PWM module adaptation involves the following steps:
1. Instantiate the driver entry.
1. Instantiate the driver entry.
- Instantiate the **HdfDriverEntry** structure.
- Instantiate the **HdfDriverEntry** structure.
- Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF.
- Call **HDF_INIT** to register the **HdfDriverEntry** instance with the HDF.
2. Configure attribute files.
2. Configure attribute files.
- Add the **deviceNode** information to the **device\_info.hcs** file.
- Add the **deviceNode** description to the **device_info.hcs** file.
-\(Optional\) Add the **pwm\_config.hcs** file.
- (Optional) Add the **pwm_config.hcs** file.
3. Instantiate the PWM controller object.
3. Instantiate the PWM controller object.
- Initialize **PwmDev**.
- Initialize **PwmDev**.
- Instantiate **PwmMethod** in the **PwmDev** object.
- Instantiate **PwmMethod** in the **PwmDev** object.
> For details about the functions in **PwmMethod**, see [Available APIs](#available-apis).
For details, see [Available APIs](#available-apis).
4. Debug the driver.
(Optional) For new drivers, verify the basic functions, such as the PWM status control and response to interrupts.
4.\(Optional\) Debug the driver.
For new drivers, verify the basic functions, such as the PWM control status and response to interrupts.
## Development Example
## Development Example<a name="section1883877829164144"></a>
The following uses **pwm_hi35xx.c** as an example to present the information required for implementing device functions.
The following uses **pwm\_hi35xx.c** as an example to present the contents that need to be provided by the vendor to implement 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, 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. 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.
Generally, HDF calls the **Bind** function and then the **Init** function to load a driver. If **Init** fails to be called, HDF calls **Release** to release driver resources and exits.
PWM driver entry example:
- PWM driver entry reference
```
```
struct HdfDriverEntry g_hdfPwm = {
struct HdfDriverEntry g_hdfPwm = {
...
@@ -107,8 +76,9 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
...
@@ -107,8 +76,9 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
HDF_INIT(g_hdfPwm);
HDF_INIT(g_hdfPwm);
```
```
2. Add the **deviceNode** information to the **device\_info.hcs** file and configure the device attributes in the **pwm\_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 **PwmDev** 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 corresponding device attributes to the **pwm\_config** file.
2. Add the **deviceNode** information to the **device_info.hcs** file and configure the device attributes in the **pwm_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 **PwmDev** 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 **pwm_config** file for each device.
-**device\_info.hcs** configuration reference
-**device_info.hcs** configuration example
```
```
root {
root {
...
@@ -116,15 +86,15 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
...
@@ -116,15 +86,15 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
platform :: host {
platform :: host {
hostName = "platform_host";
hostName = "platform_host";
priority = 50;
priority = 50;
device_pwm :: device {// Configure an HDF device node for each PWM controller. Set this parameter only when there are multiple PWM controllers.
device_pwm :: device {// Configure an HDF device node for each PWM controller.
device0 :: deviceNode {
device0 :: deviceNode {
policy = 1; // Publish kernel-mode services.
policy = 1; // Publish kernel-mode services.
priority = 80; // Driver startup priority
priority = 80; // Driver startup priority
permission = 0644; // Permission to create device nodes for the driver
permission = 0644; // Permission to create device nodes for the driver.
moduleName = "HDF_PLATFORM_PWM"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
moduleName = "HDF_PLATFORM_PWM"; // (Mandatory) Driver name, which must be the same as moduleName in the driver entry.
serviceName = "HDF_PLATFORM_PWM_0";// (Mandatory) Unique name of the service published by the driver
serviceName = "HDF_PLATFORM_PWM_0"; // (Mandatory) Unique name of the service published by the driver.
deviceMatchAttr = "hisilicon_hi35xx_pwm_0";// (Mandatory) Used to configure the private data of the controller. The value must be the same as the controller information in pwm_config.hcs.
deviceMatchAttr = "hisilicon_hi35xx_pwm_0";// (Mandatory) Used to configure the private data of the controller.
// For details about the controller information, see pwm_config.hcs.
// The value must be the same as the controller information in pwm_config.hcs.
}
}
device1 :: deviceNode {
device1 :: deviceNode {
policy = 1;
policy = 1;
...
@@ -139,23 +109,23 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
...
@@ -139,23 +109,23 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
}
}
}
}
```
```
-**pwm_config.hcs** configuration example
- **pwm\_config.hcs** configuration reference
```
```
root {
root {
platform {
platform {
pwm_config {
pwm_config {
template pwm_device {// (Mandatory) Template configuration. In the template, you can configure the common parameters shared by service nodes.
template pwm_device { // (Mandatory) Template configuration. In the template, you can configure the common parameters shared by service nodes.
serviceName = "";
serviceName = "";
match_attr = "";
match_attr = "";
num = 0; // (Mandatory) Device number
num = 0; // (Mandatory) Device number
base = 0x12070000; // (Mandatory) Used for address mapping
base = 0x12070000; // (Mandatory) Used for address mapping
}
}
device_0x12070000 :: pwm_device {
device_0x12070000 :: pwm_device { // Add the HDF node and device node information for each device.
match_attr = "hisilicon_hi35xx_pwm_0";// (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
match_attr = "hisilicon_hi35xx_pwm_0";// (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
}
}
device_0x12070020::pwm_device {// Set this parameter only when there are multiple devices.
device_0x12070020 :: pwm_device {
match_attr = "hisilicon_hi35xx_pwm_1";
match_attr = "hisilicon_hi35xx_pwm_1";
num = 1;
num = 1;
base = 0x12070020; // (Mandatory) Used for address mapping
base = 0x12070020; // (Mandatory) Used for address mapping
...
@@ -165,10 +135,11 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
...
@@ -165,10 +135,11 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
}
}
```
```
3. Initialize the **PwmDev** object at the core layer, including initializing the vendor custom structure \(transferring parameters and data\), instantiating **PwmMethod**\(used to call underlying functions of the driver\) in **PwmDev**, and implementing the **HdfDriverEntry** member functions \(**Bind**, **Init**, and **Release**\).
3. Initialize the **PwmDev** object at the core layer, including defining a custom structure (to pass parameters and data) and implementing the **HdfDriverEntry** member functions (**Bind**, **Init**, and **Release**) to instantiate **PwmMethod** in **PwmDev** (so that the underlying driver functions can be called).
- Custom structure reference
- Defining a custom structure
To the driver, the custom structure holds parameters and data. The **DeviceResourceIface** method provided by the HDF reads the values in the **pwm_config.hcs** file to initialize the members in the custom structure and passes important parameters, such as the device number, to the **GpioCntlr** object at the core layer.
To the driver, the custom structure carries parameters and data. The values in the **pwm\_config.hcs** file are read by HDF, and the structure members are initialized through **DeviceResourceIface**. Some important values, such as the device number, are also passed to the objects at the core layer.
```
```
struct HiPwm {
struct HiPwm {
...
@@ -178,7 +149,7 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
...
@@ -178,7 +149,7 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
bool supportPolarity;
bool supportPolarity;
};
};
// PwmDev is the controller structure at the core layer. Its members are assigned with values by using the Init function.
// PwmDev is the controller structure at the core layer. The Init function assigns values to the members of PwmDev.
struct PwmDev {
struct PwmDev {
struct IDeviceIoService service;
struct IDeviceIoService service;
struct HdfDeviceObject *device;
struct HdfDeviceObject *device;
...
@@ -190,9 +161,9 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
...
@@ -190,9 +161,9 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
void *priv; // Private data. Generally, the start address of the custom structure is stored to facilitate invoking of the structure.
void *priv; // Private data. Generally, the start address of the custom structure is stored to facilitate invoking of the structure.
};
};
struct PwmConfig {
struct PwmConfig {
uint32_t duty; // Time (in ns) when a signal is in the on state.
uint32_t duty // Time that a signal is in the ON state, in ns.
uint32_t period; // Regular interval (in ns) of PWM
uint32_t period; // Time for a signal to complete an on-and-off cycle, in ns.
uint32_t number; // Number of consecutive PWMs
uint32_t number; // Number of square waves to generate.
uint8_t polarity; // Polarity
uint8_t polarity; // Polarity
// ------------------- | --------------
// ------------------- | --------------
// PWM_NORMAL_POLARITY | Normal polarity
// PWM_NORMAL_POLARITY | Normal polarity
...
@@ -205,69 +176,39 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
...
@@ -205,69 +176,39 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
};
};
```
```
- Instantiate the callback function structure **PwmMethod** in **PwmDev**. Other members are initialized by using the **Init** function.
- Instantiating **PwmMethod** in **PwmDev** (other members are initialized by **Init**)
```
```
// Example in pwm_hi35xx.c: fill the hook function
// The following uses pwm_hi35xx.c as an example. Fill the hook function.
| HDF_ERR_MALLOC_FAIL | Failed to allocate memory.|
HDF\_STATUS \(The following table lists some status. For details about other status, see **HDF\_STATUS** in the **//drivers/framework/include/utils/hdf\_base.h** file.\)
if (PwmDeviceAdd(obj, &(hp->dev)) ) != HDF_SUCCESS) {// (Important) Call the core layer function to initialize the hp->dev devices and services.
if (PwmDeviceAdd(obj, &(hp->dev)) ) != HDF_SUCCESS) {// (Important) Call the core layer function to initialize hp->dev devices and services.
OsalIoUnmap((void *)hp->base);
OsalIoUnmap((void *)hp->base);
return HDF_FAILURE;
return HDF_FAILURE;
}
}
return HDF_SUCCESS;
return HDF_SUCCESS;
}
}
```
```
-**Release** function
- Release function
**Input parameter**:
Input parameters:
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information.
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
**Return value**:
Return values:
No value is returned.
–
**Function description**:
Function description:
Releases the memory and deletes the controller. This function assigns values to the **Release** function in the driver entry structure. If the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources.
Releases the memory and deletes the controller. This function assigns a value 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.
@@ -335,6 +276,6 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
...
@@ -335,6 +276,6 @@ The following uses **pwm\_hi35xx.c** as an example to present the contents that
hp = (struct HiPwm *)obj->service;// A forced conversion from HdfDeviceObject to HiPwm is involved.
hp = (struct HiPwm *)obj->service;// A forced conversion from HdfDeviceObject to HiPwm is involved.
...
...
PwmDeviceRemove(obj, &(hp->dev));// (Mandatory) Call the core layer functions to release PwmDev devices and services. A forced conversion from HiPwm to PwmDev is involved in the process.
PwmDeviceRemove(obj, &(hp->dev));// (Mandatory) Call the core layer functions to release PwmDev devices and services. A forced conversion from HiPwm to PwmDev is involved in the process.
The real-time clock (RTC) is a real-time clock device in the operating system. In the Hardware Driver Foundation (HDF), the RTC 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.
The real-time clock (RTC) is a real-time clock device in the operating system. In the Hardware Driver Foundation (HDF), the RTC 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, which increases memory usage.
**Figure 1** Independent service mode
**Figure 1** Independent service mode
...
@@ -192,7 +192,7 @@ The following uses **rtc_hi35xx.c** as an example to present the information req
...
@@ -192,7 +192,7 @@ The following uses **rtc_hi35xx.c** as an example to present the information req
