@@ -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,17 +121,17 @@ struct HdmiCntlrOps {
...
@@ -121,17 +121,17 @@ 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.
- Initialize **HdmiCntlr**.
- Instantiate **HdmiCntlrOps** in **HdmiCntlr**.
- Instantiate the HDMI controller object.
### Development Example
- Initialize **HdmiCntlr**.
- Instantiate **HdmiCntlrOps** in **HdmiCntlr**.
1. Instantiate the driver entry.
1. Instantiate the driver entry.
...
@@ -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.
```c
```c
struct HdmiAdapterHost {
struct HdmiAdapterHost {
...
@@ -403,15 +403,15 @@ The HDMI module adaptation involves the following steps:
...
@@ -403,15 +403,15 @@ The HDMI module adaptation involves the following steps:
**Input parameter**:
**Input parameter**:
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information.
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information.
**Return value**:
**Return value**:
No value is returned.
No value is returned.
**Function description**:
**Function description**:
Releases the memory and deletes the controller. This function assigns values to the **Release** callback 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 values to the **Release** callback 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.
@@ -422,6 +422,6 @@ The HDMI module adaptation involves the following steps:
...
@@ -422,6 +422,6 @@ The HDMI module adaptation involves the following steps:
HimciDeleteHost((struct HimciAdapterHost *)cntlr->priv);// Customized memory release function. A forced conversion from HdmiCntlr to HimciAdapterHost is involved in the process.
HimciDeleteHost((struct HimciAdapterHost *)cntlr->priv);// Customized memory release function. A forced conversion from HdmiCntlr to HimciAdapterHost is involved in the process.
> All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
> All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
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>
```
int32_t ret;
struct MipiCfg cfg = {0};
/* 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>
</td>
</tr>
</tbody>
</table>
```
### Setting MIPI DSI Attributes
int32_t ret;
struct MipiCfg cfg;
memset(&cfg, 0, sizeof(struct MipiCfg));
ret = MipiDsiGetCfg(mipiDsiHandle, &cfg);
if (ret != HDF_SUCCESS) {
HDF_LOGE("%s: GetMipiCfg fail!\n", __func__);
return HDF_FAILURE;
}
```
### Sending/Receiving the Pointer to a Command<a name="section199401342173415"></a>
- Call **MipiDsiSetCfg()** to set MIPI DSI attributes.
- Send the pointer to a specified command by calling the following function:
<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.
<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:
1. Instantiate the driver entry.
- Instantiate the **HdfDriverEntry** structure.
- Call **HDF\_INIT** to register the **HdfDriverEntry** instance with the HDF framework.
2. Configure attribute files.
- Add the **deviceNode** information to the **device\_info.hcs** file.
-\(Optional\) Add the **mipidsi\_config.hcs** file.
3. Instantiate the MIPI DSI controller object.
- Initialize **MipiDsiCntlr**.
- Instantiate **MipiDsiCntlrMethod** in the **MipiDsiCntlr** object.
For details, see [Available APIs](#available-apis).
| setCntlrCfg | **cntlr**: structure pointer to the MIPI DSI controller.| –| HDF_STATUS| Sets controller parameters.|
| 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.|
| 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.|
| toHs | **cntlr**: structure pointer to the MIPI DSI controller.| –| HDF_STATUS| Sets the high speed (HS) mode.|
| toLp | **cntlr**: structure pointer to the MIPI DSI controller.| –| HDF_STATUS| Sets the low power (LP) mode.|
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.
## How to Develop
The MIPI DSI module adaptation involves the following steps:
## Development Example<a name="section1167576616161538"></a>
1. Instantiate the driver entry.
- Instantiate the **HdfDriverEntry** structure.
- Call **HDF_INIT** to register the **HdfDriverEntry** instance with the HDF.
2. Configure attribute files.
- Add the **deviceNode** description to the **device_info.hcs** file.
- (Optional) Add the **mipidsi_config.hcs** file.
3. Instantiate the MIPI DSI controller object.
- Initialize **MipiDsiCntlr**.
- Instantiate **MipiDsiCntlrMethod** in the **MipiDsiCntlr** object.
> For details about the functions in **MipiDsiCntlrMethod**, 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.
## Development Example
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.
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.
**device_info.hcs** configuration example:
```
root {
device_info {
match_attr = "hdf_manager";
platform :: host {
hostName = "platform_host";
priority = 50;
device_mipi_dsi:: device {
device0 :: deviceNode {
policy = 0;
priority = 150;
permission = 0644;
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.
}
}
}
}
}
```
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.
- MIPI DSI driver entry example
```
struct HdfDriverEntry g_mipiTxDriverEntry = {
.moduleVersion = 1,
.Init = Hi35xxMipiTxInit, // See the Init 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.
};
HDF_INIT(g_mipiTxDriverEntry); // Call HDF_INIT to register the driver entry with the HDF.
```
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.
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).
- Defining a custom structure
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.
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**.
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.
```
typedef struct {
unsigned int devno; // Device number
short laneId[LANE_MAX_NUM]; // Lane ID
OutPutModeTag outputMode; // Output mode, which can be CSI mode, DSI Video mode, or DSI Command mode.
VideoModeTag videoMode; // Synchronization mode of the display device
OutputFormatTag outputFormat; // Format of the output DSI image, which can be RGB or YUV.
SyncInfoTag syncInfo; // Settings related to timing
unsigned int phyDataRate; // Data rate, in Mbit/s
unsigned int pixelClk; // Clock, in kHz
} ComboDevCfgTag;
// MipiDsiCntlr is the controller structure at the core layer. The Init function assigns values to the members of MipiDsiCntlr.
struct MipiDsiCntlr {
struct IDeviceIoService service;
struct HdfDeviceObject *device;
unsigned int devNo; // Device number
struct MipiCfg cfg;
struct MipiDsiCntlrMethod *ops;
struct OsalMutex lock;
void *priv;
};
```
- Instantiating **MipiDsiCntlrMethod** in **MipiDsiCntlr** (other members are initialized by **Init**)
- **device\_info.hcs** configuration reference
```
static struct MipiDsiCntlrMethod g_method = {
.setCntlrCfg = Hi35xxSetCntlrCfg,
.setCmd = Hi35xxSetCmd,
.getCmd = Hi35xxGetCmd,
.toHs = Hi35xxToHs,
.toLp = Hi35xxToLp,
};
```
-**Init** function
```
**Input parameter**:
root {
device_info {
match_attr = "hdf_manager";
platform :: host {
hostName = "platform_host";
priority = 50;
device_mipi_dsi:: device {
device0 :: deviceNode {
policy = 0;
priority = 150;
permission = 0644;
moduleName = "HDF_MIPI_TX"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
serviceName = "HDF_MIPI_TX";// (Mandatory) Unique name of the service published by the driver
}
}
}
}
}
```
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.
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs information.
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.
**Return value**:
- MIPI DSI driver entry reference
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.
```
struct HdfDriverEntry g_mipiTxDriverEntry = {
| Status| Description|
.moduleVersion = 1,
| -------- | -------- |
.Init = Hi35xxMipiTxInit, // See the Init function.
| HDF_ERR_INVALID_OBJECT | Invalid object.|
.Release = Hi35xxMipiTxRelease, //See the Release function.
| HDF_ERR_MALLOC_FAIL | Failed to allocate memory.|
.moduleName = "HDF_MIPI_TX", // (Mandatory) The value must be the same as that in the device_info.hcs file.
| HDF_ERR_INVALID_PARAM | Invalid parameter.|
};
| HDF_ERR_IO | I/O error.|
HDF_INIT(g_mipiTxDriverEntry); // Call HDF_INIT to register the driver entry with the HDF framework.
| HDF_SUCCESS | Operation successful.|
```
| HDF_FAILURE | Operation failed.|
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**\).
**Function description**:
- Custom structure reference
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**.
Attaches the **MipiDsiCntlrMethod** instance, calls **MipiDsiRegisterCntlr**, and performs other vendor-defined initialization operations.
```
typedef struct {
unsigned int devno; // Device number
short laneId[LANE_MAX_NUM]; // Lane ID
OutPutModeTag outputMode; // Output mode, which can be CSI mode, DSI Video mode, or DSI Command mode.
VideoModeTag videoMode; // Synchronization mode of the display device
OutputFormatTag outputFormat; // Format of the output DSI image, which can be RGB or YUV.
SyncInfoTag syncInfo; // Settings related to timing
unsigned int phyDataRate; // mbps
unsigned int pixelClk; // KHz
} ComboDevCfgTag;
// MipiDsiCntlr is the controller structure at the core layer. Its members are assigned with values by using the Init function.
struct MipiDsiCntlr {
struct IDeviceIoService service;
struct HdfDeviceObject *device;
unsigned int devNo; // Device number
struct MipiCfg cfg;
struct MipiDsiCntlrMethod *ops;
struct OsalMutex lock;
void *priv;
};
```
- Instantiate the callback function structure **MipiDsiCntlrMethod** in **MipiDsiCntlr**. Other members are initialized by using the Init function.
```
static struct MipiDsiCntlrMethod g_method = {
.setCntlrCfg = Hi35xxSetCntlrCfg,
.setCmd = Hi35xxSetCmd,
.getCmd = Hi35xxGetCmd,
.toHs = Hi35xxToHs,
.toLp = Hi35xxToLp,
};
```
- 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.
// static struct MipiDsiCntlr g_mipiTx {
// .devNo=0
// };
g_mipiTx.ops = &g_method;// Connect to 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.
...
return MipiTxDrvInit(0); // (Mandatory) Device initialization customized by the vendor.
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.
...
return MipiTxDrvInit(0); // (Mandatory) Device initialization customized by the vendor.
cntlr->device = device; // Prerequisites for conversion between HdfDeviceObject and MipiDsiHandle.
device->service = &(cntlr->service); // Prerequisites for conversion between HdfDeviceObject and MipiDsiHandle.
cntlr->priv = NULL;
...
return HDF_SUCCESS;
}
...
return HDF_FAILURE;
}
```
-**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 corresponding value assignment operations.
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return values:
–
Function description:
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, see [Available APIs](#available-apis).
> For details about the functions in **PwmMethod**, see [Available APIs](#available-apis).
4.\(Optional\)Debug the driver.
4. Debug the driver.
For new drivers, verify the basic functions, such as the PWM control status and response to interrupts.
(Optional) For new drivers, verify the basic functions, such as the PWM status control and response to interrupts.
## Development Example<a name="section1883877829164144"></a>
## Development Example
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.
The following uses **pwm_hi35xx.c** as an example to present the information required for implementing device functions.
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.
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, 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.
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.
- PWM driver entry reference
PWM driver entry example:
```
```
struct HdfDriverEntry g_hdfPwm = {
struct HdfDriverEntry g_hdfPwm = {
.moduleVersion = 1,
.moduleVersion = 1,
.moduleName = "HDF_PLATFORM_PWM",// (Mandatory) The value must be the same as that of moduleName in the .hcs file.
.moduleName = "HDF_PLATFORM_PWM",// (Mandatory) The value must be the same as that of moduleName in the .hcs file.
.Bind = HdfPwmBind,
.Bind = HdfPwmBind,
.Init = HdfPwmInit,
.Init = HdfPwmInit,
.Release = HdfPwmRelease,
.Release = HdfPwmRelease,
};
};
// Call HDF_INIT to register the driver entry with the HDF.
// Call HDF_INIT to register the driver entry with the HDF.
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 {
```
device_info {
root {
platform :: host {
device_info {
hostName = "platform_host";
platform :: host {
priority = 50;
hostName = "platform_host";
device_pwm :: device {// Configure an HDF device node for each PWM controller. Set this parameter only when there are multiple PWM controllers.
priority = 50;
device0 :: deviceNode {
device_pwm :: device {// Configure an HDF device node for each PWM controller.
policy = 1; // Publish kernel-mode services.
device0 :: deviceNode {
priority = 80; // Driver startup priority
policy = 1; // Publish kernel-mode services.
permission = 0644; // Permission to create device nodes for the driver
priority = 80; // Driver startup priority
moduleName = "HDF_PLATFORM_PWM"; // (Mandatory) Driver name, which must be the same as the moduleName in the driver entry.
permission = 0644; // Permission to create device nodes for the driver.
serviceName = "HDF_PLATFORM_PWM_0";// (Mandatory) Unique name of the service published by the driver
moduleName = "HDF_PLATFORM_PWM"; // (Mandatory) Driver name, which must be the same as moduleName in the driver entry.
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.
serviceName = "HDF_PLATFORM_PWM_0"; // (Mandatory) Unique name of the service published by the driver.
// For details about the controller information, see pwm_config.hcs.
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.
device1 :: deviceNode {
}
policy = 1;
device1 :: deviceNode {
priority = 80;
policy = 1;
permission = 0644;
priority = 80;
moduleName = "HDF_PLATFORM_PWM";
permission = 0644;
serviceName = "HDF_PLATFORM_PWM_1";
moduleName = "HDF_PLATFORM_PWM";
deviceMatchAttr = "hisilicon_hi35xx_pwm_1";
serviceName = "HDF_PLATFORM_PWM_1";
}
deviceMatchAttr = "hisilicon_hi35xx_pwm_1";
}
}
}
}
}
}
}
}
```
}
```
- **pwm\_config.hcs** configuration reference
-**pwm_config.hcs** configuration example
```
root {
```
platform {
root {
pwm_config {
platform {
template pwm_device {// (Mandatory) Template configuration. In the template, you can configure the common parameters shared by service nodes.
pwm_config {
serviceName = "";
template pwm_device { // (Mandatory) Template configuration. In the template, you can configure the common parameters shared by service nodes.
match_attr = "";
serviceName = "";
num = 0; // (Mandatory) Device number
match_attr = "";
base = 0x12070000; // (Mandatory) Used for address mapping
num = 0; // (Mandatory) Device number
}
base = 0x12070000; // (Mandatory) Used for address mapping
device_0x12070000 :: pwm_device {
}
match_attr = "hisilicon_hi35xx_pwm_0";// (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
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.
device_0x12070020::pwm_device {// Set this parameter only when there are multiple devices.
}
match_attr = "hisilicon_hi35xx_pwm_1";
device_0x12070020 :: pwm_device {
num = 1;
match_attr = "hisilicon_hi35xx_pwm_1";
base = 0x12070020; // (Mandatory) Used for address mapping
num = 1;
}
base = 0x12070020; // (Mandatory) Used for address mapping
}
}
}
}
}
}
```
}
```
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 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.
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.
**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.\)
| HDF_ERR_MALLOC_FAIL | Failed to allocate memory.|
| HDF_ERR_INVALID_PARAM | Invalid parameter.|
| HDF_ERR_IO | I/O error.|
| HDF_SUCCESS | Initialization successful.|
| HDF_FAILURE | Initialization failed.|
Function description:
**Function description**:
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.
Initializes the custom structure object and **PwmDev**, and calls the **PwmDeviceAdd** function at the core layer.
hp = (struct HiPwm *)obj->service;// A forced conversion from HdfDeviceObject to HiPwm is involved.
(void)obj;
...
return HDF_SUCCESS;
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.
if (PwmDeviceAdd(obj, &(hp->dev)) ) != HDF_SUCCESS) {// (Important) Call the core layer function to initialize hp->dev devices and services.
OsalIoUnmap((void *)hp->base);
return HDF_FAILURE;
}
return HDF_SUCCESS;
}
```
-**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** 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.
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.
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
