For details, 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, verify the information returned after the connect operation and whether the signal collection is successful.
4.\(Optional\) Debug the driver.
For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether the signal collection is successful.
## Development Example<a name="section1745221471165048"></a>
...
...
@@ -415,6 +412,3 @@ The following uses **adc\_hi35xx.c** as an example to present the contents tha
@@ -42,7 +42,8 @@ The DAC module is divided into the following layers:
- The core layer provides the capabilities of binding, initializing, and releasing devices.
- The adaptation layer implements other functions.
NOTE<br/>The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer.
>The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer.
@@ -36,7 +36,8 @@ The DAC module is divided into the following layers:
- The core layer provides the capabilities of binding, initializing, and releasing devices.
- The adaptation layer implements other functions.
NOTE<br/>The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer.
>The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer.
**Figure 1** Unified service mode<aname="fig14423182615525"></a>
...
...
@@ -283,8 +284,8 @@ The DAC module adaptation procedure is as follows:
-High-definition multimedia interface (HDMI) is an interface for transmitting audio and video data from a source device, such as a DVD player or set-top box (STB), to a sink device, such as a TV or display.
- HDMI works in master/slave mode and usually has a source and a sink.
-The HDMI APIs provide a set of common functions for HDMI transmission, including:
- Opening and closing an HDMI controller
- Starting and stopping HDMI transmission
- Setting audio, video, and High Dynamic Range (HDR) attributes, color depth, and AV mute
- Reading the raw Extended Display Identification Data (EDID) from a sink
- Registering and unregistering a callback for HDMI hot plug detect (HPD).
High-definition multimedia interface (HDMI) is an interface for transmitting audio and video data from a source device, such as a DVD player or set-top box (STB), to a sink device, such as a TV or display.
HDMI works in primary/secondary mode and usually has a source and a sink.
The HDMI APIs provide a set of common functions for HDMI transmission, including:
- Opening and closing an HDMI controller
- Starting and stopping HDMI transmission
- Setting audio, video, and High Dynamic Range (HDR) attributes, color depth, and AV mute
- Reading the raw Extended Display Identification Data (EDID) from a sink
- Registering and unregistering a callback for HDMI hot plug detect (HPD).
For details, see [Available APIs](#available-apis).
>For details, see [Available APIs](#available-apis).
4.\(Optional\) Debug the driver.
4. Debug the driver.
-\(Optional\) For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
For new drivers, verify basic functions, for example, verify the information returned after the connect operation and whether data is successfully transmitted.
...
...
@@ -395,6 +393,3 @@ The following uses **i2c\_hi35xx.c** as an example to present the contents tha
Defined by the Mobile Industry Processor Interface \(MIPI\) Alliance, the Camera Serial Interface \(CSI\) is a specification that allows data to be transmitted from the camera to the host processor on mobile platforms. In the Hardware Driver Foundation \(HDF\), the MIPI CSI 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 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.
...
...
@@ -213,12 +208,10 @@ The MIPI CSI module adaptation involves the following steps:
- Initialize **MipiCsiCntlr**.
- Instantiate **MipiCsiCntlrMethod** in the **MipiCsiCntlr** object.
>For details, 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, verify the information returned after the connect operation 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<a name="section2049027816170128"></a>
...
...
@@ -408,9 +401,9 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
HDF_LOGI("%s: enter!", __func__);
g_mipiCsi.priv = NULL; // g_mipiTx is a global variable defined.
//static struct MipiCsiCntlr g_mipiCsi = {
//.devNo = 0
//};
//static struct MipiCsiCntlr g_mipiCsi = {
//.devNo = 0
//};
g_mipiCsi.ops = &g_method; // Connect to the MipiCsiCntlrMethod instance.
#ifdef CONFIG_HI_PROC_SHOW_SUPPORT
g_mipiCsi.debugs = &g_debugMethod;
...
...
@@ -484,7 +477,7 @@ The following uses **mipi\_rx\_hi35xx.c** as an example to present the content
struct MipiCsiCntlr *cntlr = NULL;
...
cntlr = MipiCsiCntlrFromDevice(device); // A forced conversion from HdfDeviceObject to MipiCsiCntlr is involved.
-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.
-[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.
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.
[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>
For details, 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, verify the information returned after the connect operation 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.
...
...
@@ -273,9 +270,9 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
{
int32_t ret;
g_mipiTx.priv = NULL; // g_mipiTx is a global variable.
//static struct MipiDsiCntlr g_mipiTx {
//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.
...
...
...
@@ -332,6 +329,3 @@ The following uses **mipi\_tx\_hi35xx.c** as an example to present the content
For details, 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, verify the information returned after the mount operation and whether the device starts successfully.
4.\(Optional\) Debug the driver.
For new drivers, verify basic functions, for example, verify the information returned after the mount operation and whether the device starts successfully.
## Development Example<a name="section1220893490162704"></a>
...
...
@@ -551,6 +548,3 @@ The following uses **himci.c** as an example to present the contents that need
HimciDeleteHost((struct HimciHost *)cntlr->priv);// Memory release function customized by the vendor. A forced conversion from MmcCntlr to HimciHost is involved in the process.
