• Home
Name
Date
Size
#Lines
LOC

..--

adapter/12-May-2024-78,64859,702

figures/12-May-2024-

framework/12-May-2024-254,613197,742

interfaces/inner_api/12-May-2024-8,1882,392

.clang-formatD12-May-2024892 2928

CODEOWNERSD12-May-20241.4 KiB3935

LICENSED12-May-202412.9 KiB235200

OAT.xmlD12-May-20249.3 KiB11666

README.mdD12-May-202410.4 KiB174125

README_zh.mdD12-May-202410.1 KiB182129

bundle.jsonD12-May-20246.2 KiB157157

README.md

1# HDF<a name="EN-US_TOPIC_0000001078041442"></a>
2
3-   [Introduction](#section11660541593)
4-   [Directory Structure](#section161941989596)
5-   [Usage](#section1312121216216)
6    -   [HDF](#section129654513264)
7    -   [Sensor](#section188637474417)
8    -   [Display](#section161502341317)
9    -   [Input](#section12629164020115)
10    -   [WLAN](#section11408103183114)
11
12-   [Repositories Involved](#section1371113476307)
13
14## Introduction<a name="section11660541593"></a>
15
16This repository stores the core source code information of the OpenHarmony driver subsystem, including the driver framework, configuration management, configuration parsing, universal framework model, and unified hardware driver interfaces. It is designed to provide a more precise and efficient development environment, where you can perform one-time development for multi-system deployment.
17
18**Figure  1**  Architecture of the HDF<a name="fig19330181162816"></a>
19![](figures/architecture-of-the-hdf.png)
20
21## Directory Structure<a name="section161941989596"></a>
22
23```
24/drivers/hdf_core/framework
25├── core           # Core code for implementing the HDF
26│   ├── adapter    # Kernel adaptation layer
27│   ├── common     # Common basic code
28│   ├── host       # Driver host environment module
29│   ├── manager    # Management module
30│   └── shared     # Code shared by the host and manager modules
31├── include        # Header files for the HDF to provide capabilities externally
32│   ├── audio      # Header files related to audio operations
33│   ├── bluetooth  # Header files related to bluetooth operations
34│   ├── core       # Header files exposed externally
35│   ├── ethernnet  # Header files related to ethernnet operations
36│   ├── net        # Header files related to network operations
37│   ├── osal       # Header files of the OS adaptation layer
38│   ├── platform   # Header files declaring platform APIs
39│   ├── utils      # Header files declaring common capabilities
40│   └── wifi       # Header files for the WLAN module to provide capabilities externally
41├── model          # Universal framework module for drivers
42│   ├── audio      # Audio framework module
43│   ├── display    # Display framework module
44│   ├── input      # Input framework module
45│   ├── misc       # Misc framework module, including dsoftbus, light, vibrator
46│   ├── network    # WLAN framework module
47│   └── sensor     # Sensor driver module
48│   └── storage    # Storage driver module
49│   └── usb        # Usb driver module
50├── sample         # Sample code
51├── support        # Basic capabilities
52│   └── platform   # Platform driver framework and APIs, including GPIO, I2C, and SPI
53│   └── posix      # Posix APIs, including Mem, Mutex, Sem, Spinlock, Thread and Time
54├── test           # Testcase
55├── tools          # Source code related to the tools of the HDF
56│   └── hc-gen     # Source code of the configuration management tool
57│   └── hcs-view   #
58│   └── hdf-dbg    #
59│   └── hdf-dev_eco_tool #
60│   └── hdf-gen    #
61│   └── idl-gen    #
62│   └── leagecy    #
63└── utils          # Basic data structures and algorithms
64```
65
66## Usage<a name="section1312121216216"></a>
67
68### HDF<a name="section129654513264"></a>
69
70To develop a driver based on the HDF, you only need to register and configure required APIs. The driver framework will load and initialize the driver based on the parsing content.
71
72Driver development based on the HDF consists of the following three parts:
73
74-   Driver: Develop the functions.
75
76-   Information configuration: Present the loading information of the driver.
77
78-   Resource configuration: Configure the hardware information of the driver.
79
80You need to complete the logic code for the functions of a driver by the following APIs.
81
82The first part that catches your eyes is the driver entry, which is described through  **DriverEntry**.
83
84Three APIs are available, namely  **Bind**,  **Init**, and  **Release**.
85
86```
87struct HdfDriverEntry g_deviceSample = {
88    .moduleVersion = 1,
89    .moduleName = "sample_driver",
90    .Bind = SampleDriverBind,
91    .Init = SampleDriverInit,
92    .Release = SampleDriverRelease,
93};
94```
95
96**Bind**: This API is used to bind driver devices and its functions.
97
98```
99int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject)
100{
101    return HDF_SUCCESS;
102}
103```
104
105**Init**: When devices are successfully bound, the HDF calls  **Init**  to initialize the driver. After initialization is complete, the HDF will determine whether to create external service interfaces based on the configuration file. If the driver fails to be initialized, the driver framework will automatically release the created device interface.
106
107```
108int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject)
109{
110    return HDF_SUCCESS;
111}
112```
113
114**Release**: When you need to uninstall a driver, the HDF calls this function to release the driver resources. Then, other internal resources will be released.
115
116```
117void SampleDriverRelease(struct HdfDeviceObject *deviceObject)
118{
119    // Release all resources.
120    return;
121}
122```
123
124For details, see  [HDF Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-hdf-development.md).
125
126### Sensor<a name="section188637474417"></a>
127
128The sensor driver module is developed based on the HDF and supports functions such as cross-OS migration and differentiated device configuration.
129
130-   APIs for implementing sensor driver module capabilities: Implement the capabilities of registering, loading, and deregistering sensor drivers as well as detecting sensor device depending on the HDF, normalize APIs for sensor devices of the same type, and offer APIs for parsing register configurations, abstract APIs for bus access, and abstract platform APIs.
131-   APIs to be implemented by developers: Based on the HDF Configuration Source \(HCS\), implement differentiated configuration for sensors of the same type and serialized configuration of sensor device parameters, and offer APIs for some sensor device operations to simplify the sensor driver development.
132
133For details, see  [Sensor Driver Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-sensor-des.md).
134
135### Display<a name="section161502341317"></a>
136
137The display driver model that is developed based on the HDF shields the differences among chip platforms, achieving cross-platform migration of the OS. It also abstracts the common service logic of peripherals and configures differentiated adaptation APIs so that a driver model can be compatible with different peripheral. In this way, third-party vendors can efficiently access the OpenHarmony driver ecosystem.
138
139-   APIs for implementing display driver module capabilities: Implement the Hardware Driver Interfaces \(HDIs\) and their adaptation with the chip platform. In addition, the kernel-mode driver abstracts the common services of the panel driver and provides capabilities of initializing the panel, obtaining the panel configuration, powering on/off the panel, and implementing the backlight control.
140-   APIs to be implemented by developers: Complete the board-level HCS configuration and private data configuration of the panel, or offer differentiated APIs for some components to ensure efficient development of the display driver.
141
142For details, see  [LCD Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-lcd-des.md).
143
144### Input<a name="section12629164020115"></a>
145
146The input driver model is developed based on the HDF, provides unified driver APIs for upper-layer input services, and is decoupled from the chip platform. In addition, it abstracts several types of common platform drivers based on different input devices and is compatible with those input devices through configuration and differentiated peripheral APIs.
147
148-   APIs for implementing input driver module capabilities: Implement the HDIs and provide capabilities of managing devices, controlling services, and reporting data. Besides, the input driver model provides a unified driver for different input devices and the capabilities of registering/unregistering an input device, reporting event data, parsing configuration, and loading a common driver.
149-   APIs to be implemented by developers: Based on the provided platform driver, add the device descriptions as well as private configuration of the input device and implement differentiated APIs to greatly shorten the time required for developing input drivers.
150
151For details, see  [Touchscreen Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-touch-des.md).
152
153### WLAN<a name="section11408103183114"></a>
154
155The WLAN module is developed based on the HDF and supports cross-OS migration, component adaptation, and modular assembly and compilation. Based on the unified APIs provided by the WLAN module, driver developers of WLAN vendors can adapt their driver code and developers of the Hardware Driver Interfaces \(HDIs\) are capable of creating, disabling, scanning, and connecting to WLAN hotspots.
156
157-   APIs for implementing WLAN driver module capabilities: Implement the APIs of the WLAN HDI layer and provide capabilities of setting/obtaining the MAC address, obtaining the feature type, and setting the transmit power for upper-layer input services, as well as the capabilities of creating/releasing a  **WifiModule**, connecting to/disconnecting from a WLAN hotspot, and applying for/releasing a  **NetBuf**  for developers.
158-   APIs to be implemented by developers: Based on the provided platform driver, complete the board-level HCS configuration as well as the differentiated WLAN configuration, and offer APIs for initializing, deregistering, enabling, and disabling a network device.
159
160For details, see  [WLAN Overview](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-external-des.md).
161
162## Repositories Involved<a name="section1371113476307"></a>
163
164[Driver subsystem](https://gitee.com/openharmony/docs/blob/master/en/readme/driver.md)
165
166[drivers\_framework](https://gitee.com/openharmony/drivers_framework/blob/master/README.md)
167
168[drivers\_adapter](https://gitee.com/openharmony/drivers_adapter/blob/master/README.md)
169
170[drivers\_adapter\_khdf\_linux](https://gitee.com/openharmony/drivers_adapter_khdf_linux/blob/master/README.md)
171
172[drivers\_peripheral](https://gitee.com/openharmony/drivers_peripheral/blob/master/README.md)
173
174

README_zh.md

1# Hdf Framework<a name="ZH-CN_TOPIC_0000001078041442"></a>
2
3-   [简介](#section11660541593)
4-   [目录](#section161941989596)
5-   [说明](#section1312121216216)
6    -   [驱动框架使用说明](#section129654513264)
7    -   [Sensor框架模型说明](#section188637474417)
8    -   [Display框架模型说明](#section161502341317)
9    -   [Input框架模型说明](#section12629164020115)
10    -   [WLAN框架模型说明](#section11408103183114)
11
12-   [相关仓](#section1371113476307)
13
14## 简介<a name="section11660541593"></a>
15
16该仓主要存放OpenHarmony驱动子系统核心源码信息（包括驱动框架、配置管理、配置解析、驱动通用框架模型、硬件通用平台能力接口等），旨在为开发者提供更精准、更高效的开发环境，力求做到一次开发，多系统部署。
17
18**图 1**  驱动框架架构图<a name="fig1181155517618"></a>
19![](figures/architecture-of-the-hdf.png)
20
21## 目录<a name="section161941989596"></a>
22
23```
24/drivers/hdf_core/framework
25├── core           #实现驱动框架的核心代码
26│   ├── adapter    #实现对内核操作接口适配，提供抽象化的接口供开发者使用
27│   ├── common     #驱动框架公共基础代码
28│   ├── host       #驱动宿主环境模块
29│   ├── manager    #驱动框架管理模块
30│   └── shared     #host和manager共享模块代码
31├── include        #驱动框架对外提供能力的头文件
32│   ├── audio      #AUDIO对外提供能力的头文件
33│   ├── bluetooth  #蓝牙对外提供能力的头文件
34│   ├── core       #驱动框架对外提供的头文件
35│   ├── ethernnet  #以太网操作相关的头文件
36│   ├── net        #网络数据操作相关的头文件
37│   ├── osal       #系统适配相关接口的头文件
38│   ├── platform   #平台设备相关接口的头文件
39│   ├── utils      #驱动框架公共能力的头文件
40│   └── wifi       #WLAN对外提供能力的头文件
41├── model          #提供驱动通用框架模型
42│   ├── audio      #AUDIO框架模型
43│   ├── display    #显示框架模型
44│   ├── input      #输入框架模型
45│   ├── misc       #杂项设备框架模型，包括dsoftbus、light、vibrator
46│   ├── network    #WLAN框架模型
47│   └── sensor     #Sensor驱动模型
48│   └── storage    #存储驱动模型
49│   └── usb        #USB驱动模型
50├── sample         #HCS配置描述示例及HDF驱动示例
51├── support        #提系统的基础能力
52│   └── platform   #平台设备驱动框架及访问接口，范围包括GPIO、I2C、SPI等
53│   └── posix      #posix框架及访问接口，范围包括Mem、Mutex、Sem、Spinlock、Thread、Time等
54├── test           #测试用例
55├── tools          #hdf框架工具相关的源码
56│   └── hc-gen     #配置管理工具源码
57│   └── hcs-view   #
58│   └── hdf-dbg    #
59│   └── hdf-dev_eco_tool #
60│   └── hdf-gen    #
61│   └── idl-gen    #
62│   └── leagecy    #
63└── utils          #提供基础数据结构和算法等
64```
65
66## 说明<a name="section1312121216216"></a>
67
68### 驱动框架使用说明<a name="section129654513264"></a>
69
70基于HDF框架开发驱动，开发者只需注册所需接口和配置，驱动框架就会解析配置内容，完成驱动加载和初始化动作。
71
72HDF驱动框架主要包含三部分：
73
741、驱动程序部分----完成驱动的功能逻辑。
75
762、驱动配置信息----指示驱动的加载信息内容。
77
783、驱动资源配置----配置驱动的硬件配置信息。
79
80驱动程序主要是完成驱动功能的逻辑代码：
81
82对于开发者首先看到的是驱动入口部分，驱动入口通过结构体DriverEntry进行描述。
83
84其中主要包含Bind, Init 和Release三个接口。
85
86```
87struct HdfDriverEntry g_deviceSample = {
88    .moduleVersion = 1,
89    .moduleName = "sample_driver",
90    .Bind = SampleDriverBind,
91    .Init = SampleDriverInit,
92    .Release = SampleDriverRelease,
93};
94```
95
96Bind接口描述：该接口的作用主要是完成驱动设备和设备服务接口的bind动作。
97
98```
99int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject)
100{
101    return HDF_SUCCESS;
102}
103```
104
105Init接口描述：当框架完成设备绑定动作后，就开始调用驱动初始化接口，初始化成功后，驱动框架根据配置文件决定是对外创建设备服务接口，还是接口只对当前服务可见。如果Init初始化失败，驱动框架就会主动释放创建的设备接口等信息。
106
107```
108int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject)
109{
110    return HDF_SUCCESS;
111}
112```
113
114Release接口描述：当用户需要卸载驱动时，驱动框架先通过该接口通知驱动程序释放资源，然后再释放其他内部资源。
115
116```
117void SampleDriverRelease(struct HdfDeviceObject *deviceObject)
118{
119    // Release all resources.
120    return;
121}
122```
123
124HDF驱动框架详细开发请参考[驱动开发指南](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/driver-hdf-development.md)。
125
126### Sensor框架模型说明<a name="section188637474417"></a>
127
128基于HDF（**H**ardware  **D**river  **F**oundation）驱动框架的Sensor驱动模型，可实现跨操作系统迁移、器件差异配置等功能。
129
130Sensor驱动模型主要由以下两部分组成：
131
132-   基础能力部分：依赖HDF驱动框架实现Sensor器件驱动的注册、加载、去注册、器件探测等能力，提供同一类型Sensor器件的驱动归一接口、寄存器配置解析操作接口、总线访问抽象接口和平台抽象接口。
133-   开发者实现部分：依赖HDF驱动框架的HCS\(**H**DF  **C**onfiguration  **S**ource\)配置管理，根据同类型Sensor差异化配置，实现Sensor器件参数序列化配置和器件部分操作接口。
134
135基于Sensor驱动模型开发Sensor器件驱动请参考[Sensor驱动开发指南](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/driver-peripherals-sensor-des.md)。
136
137### Display框架模型说明<a name="section161502341317"></a>
138
139基于OpenHarmony驱动框架的Display驱动模型，对下屏蔽了芯片平台差异，方便操作系统跨平台迁移；向上抽象了外设驱动公共业务逻辑，通过配置或差异化适配接口，实现了一套驱动模型兼容不同的外设器件，使得三方厂商可以高效、便捷的切入鸿蒙驱动生态。
140
141Display驱动模型主要由以下两部分组成：
142
143-   基础能力部分：包括HDI（**H**ardware  **D**river  **I**nterfaces）接口的定义及实现框架，以及芯片平台对HDI接口的适配实现；内核驱动部分抽象了Panel驱动的公共业务，提供了Panel初始化、器件配置信息获取、上下电、背光设置等公共流程。
144-   开发者实现部分：需要完成板级HCS配置及Panel私有数据配置，实现部分器件差异化接口。
145
146基于Display驱动模型开发LCD器件驱动请参考[LCD驱动开发指南](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/driver-peripherals-lcd-des.md)。
147
148### Input框架模型说明<a name="section12629164020115"></a>
149
150基于OpenHarmony驱动框架的Input驱动模型，不依赖于芯片平台，对上层输入服务提供统一的驱动接口；在具体的驱动模型实现中，针对不同类别的输入设备，抽象出几类公共的平台驱动，通过配置及差异化的适配接口，使得驱动模型可兼容不同的输入设备。借由此驱动模型，可大幅缩减Input设备驱动的开发周期。
151
152Input驱动模型主要有以下两部分组成：
153
154-   基础能力部分：包括Input HDI层的接口定义及公共实现，对上层输入服务提供设备管理、业务控制、数据上报等驱动能力接口；而Input驱动模型提供不同类型Input设备的归一化驱动, 包括输入设备的注册和注销、event数据的上报通道、配置信息的解析、公共驱动的加载等能力。
155-   开发者实现部分：需根据驱动模型提供的平台驱动，完成设备描述配置及器件私有配置，实现预留的器件差异化接口。
156
157基于Input驱动模型开发Touchscreen器件驱动请参考[Touchscreen驱动开发指南](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/driver-peripherals-touch-des.md)。
158
159### WLAN框架模型说明<a name="section11408103183114"></a>
160
161基于OpenHarmony驱动框架的WLAN驱动模型，可实现跨操作系统迁移，自适应器件差异，模块化拼装编译等功能。各WLAN厂商驱动开发人员可根据WLAN模块提供的向下统一接口适配各自的驱动代码，HDI层开发人员可根据WLAN模块提供的向上统一接口获取如下能力：建立/关闭WLAN热点、扫描、关联WLAN热点等。
162
163WLAN驱动模型主要有以下两部分组成：
164
165-   基础能力部分：包括WLAN HDI层的接口定义及公共实现，对上层输入服务提供如设置MAC地址，获取设备MAC地址，获取特性类型，设置发射功率等能力；对驱动开发者提供创建/释放WifiModule、关联/取消关联、申请/释放NetBuf等能力。
166-   开发者实现部分：需根据驱动模型提供的平台驱动，完成板级的HCS配置及WLAN芯片的私有配置，实现预留的初始化/注销网络设备、打开/关闭网络设备等相关接口。
167
168基于WLAN驱动模型开发WLAN器件驱动请参考[WLAN驱动开发指南](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/driver-peripherals-external-des.md)。
169
170## 相关仓<a name="section1371113476307"></a>
171
172[驱动子系统](https://gitee.com/openharmony/docs/blob/master/zh-cn/readme/%E9%A9%B1%E5%8A%A8%E5%AD%90%E7%B3%BB%E7%BB%9F.md)
173
174[drivers\_framework](https://gitee.com/openharmony/drivers_framework/blob/master/README.md)
175
176[drivers\_adapter](https://gitee.com/openharmony/drivers_adapter/blob/master/README_zh.md)
177
178[drivers\_adapter\_khdf\_linux](https://gitee.com/openharmony/drivers_adapter_khdf_linux/blob/master/README_zh.md)
179
180[drivers\_peripheral](https://gitee.com/openharmony/drivers_peripheral/blob/master/README_zh.md)
181
182