📚 课程目录第3章 Linux内核设备模型基础

3、Linux内核设备模型基础：platform device、i2c client、device tree、probe流程

Linux内核的Camera子系统本质上是一组设备驱动程序的集合，而驱动程序的编写与运行，完全建立在Linux设备模型之上。对于Camera驱动开发者而言，理解设备模型并非为了学术研究，而是为了回答三个最实际的问题：我的设备在内核中如何被描述？驱动如何找到设备？probe函数何时被调用？本章将围绕platform device、i2c client、device tree和probe流程四个核心概念展开，帮助读者建立从硬件描述到驱动加载的完整认知链路。

3.1 设备模型的核心原理：设备、驱动与总线

Linux设备模型的核心思想是将硬件设备抽象为设备（device），将驱动逻辑抽象为驱动（driver），并通过总线（bus）将两者关联。设备与驱动之间通过匹配机制建立联系，一旦匹配成功，内核就会调用驱动的probe函数，完成设备的初始化和注册。这个模型看似简单，却解决了嵌入式系统中最棘手的问题：驱动代码如何与具体的硬件配置解耦。

在Camera子系统中，这种解耦尤为重要。一颗Camera Sensor可能被用在不同的主控平台上，而同一主控平台也可能接不同型号的Sensor。如果驱动代码中硬编码了寄存器地址、中断号、GPIO编号，那么每更换一次硬件平台，驱动就要大改一次。设备模型的引入，使得硬件资源描述从驱动代码中剥离出来，驱动只关心"如何操作这类设备"，而"设备在哪里、资源是什么"由设备树或板级文件描述。

模型要素	Camera子系统中的具体体现	关键数据结构
总线（Bus）	platform_bus_type、i2c_bus_type	struct bus_type
设备（Device）	platform_device（CSI控制器）、i2c_client（Sensor）	struct platform_device、struct i2c_client
驱动（Driver）	platform_driver（CSI驱动）、i2c_driver（Sensor驱动）	struct platform_driver、struct i2c_driver
匹配机制	compatible属性匹配、id_table匹配、ACPI匹配	of_match_table、id_table

对于Camera驱动开发者来说，最常见的两个设备类型是platform device和i2c client。前者用于描述SoC内部的控制器（如ISP、CSI主机控制器、DMA引擎），后者用于描述挂在I2C总线上的外部Sensor。两者在probe流程上遵循相同的"匹配→probe→初始化→注册"模式，但在资源获取和初始化细节上存在显著差异。

3.2 platform device与i2c client的工程识别

在实际开发中，判断一个设备应该注册为platform device还是i2c client，是驱动设计的第一步。判断依据并不复杂：看设备与CPU的连接方式。如果设备直接挂在CPU的内存总线上，通过寄存器访问控制，那么它就是platform device；如果设备挂在I2C总线上，通过I2C协议通信，那么它就是i2c client。

以典型的Camera子系统为例：SoC内部的ISP（图像信号处理器）和CSI（Camera Serial Interface）控制器，它们直接映射在CPU地址空间中，驱动通过ioremap访问其寄存器，因此是platform device。而外部的Camera Sensor（如OV5640、IMX219），它们通过I2C接口与SoC通信，驱动通过I2C读写寄存器，因此是i2c client。需要注意的是，一个Sensor可能同时涉及两种设备类型：Sensor本身是i2c client，但Sensor的电源控制、复位引脚、MCLK时钟等资源，往往由对应的platform device（或regulator、clk框架）来管理。

判断方法速查：

设备是否直接映射在CPU地址空间？ → 是：platform device
设备是否通过I2C/SPI等低速总线连接？ → 是：i2c client / spi device
设备是否通过USB/PCIe等热插拔总线连接？ → 是：usb_device / pci_dev
设备是否只是虚拟功能（如V4L2子设备）？ → 是：不直接对应物理设备

在设备树中，platform device通常表现为根节点下的子节点，带有compatible属性和reg属性（描述寄存器地址）。i2c client则挂在i2c总线节点下，除了compatible属性外，还需要reg属性指定I2C从机地址。下面是一个典型的设备树片段：

// 设备树中的platform device（CSI控制器）
csi_host: csi@1a0c0000 {
    compatible = "rockchip,rk3568-mipi-csi2";
    reg = <0x0 0x1a0c0000 0x0 0x1000>;
    interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&cru CLK_MIPI_CSI>;
    clock-names = "pclk";
    status = "disabled";
};

// 设备树中的i2c client（Camera Sensor）
i2c2: i2c@fe5c0000 {
    compatible = "rockchip,rk3568-i2c";
    reg = <0x0 0xfe5c0000 0x0 0x1000>;
    #address-cells = <1>;
    #size-cells = <0>;
    
    ov5640: ov5640@3c {
        compatible = "ovti,ov5640";
        reg = <0x3c>;  // I2C从机地址
        clocks = <&cru CLK_MIPI_CAMERAOUT>;
        clock-names = "xclk";
        pinctrl-names = "default";
        pinctrl-0 = <&cif_clk_pins>;
        reset-gpios = <&gpio2 RK_PB6 GPIO_ACTIVE_LOW>;
        powerdown-gpios = <&gpio2 RK_PB7 GPIO_ACTIVE_HIGH>;
        avdd-supply = <&vcc_avdd>;
        dvdd-supply = <&vcc_dvdd>;
        dovdd-supply = <&vcc_dovdd>;
        status = "disabled";
    };
};

3.3 device tree的解析与资源获取

设备树（Device Tree）是描述硬件资源的标准化语言，它解决了ARM Linux长期存在的"板级文件泛滥"问题。在Camera驱动开发中，设备树的核心作用有两个：一是提供设备与驱动的匹配信息（compatible属性），二是提供设备运行所需的资源清单（寄存器地址、中断、时钟、GPIO、电源等）。

当内核启动时，设备树被解析为struct device_node结构体树。当platform device或i2c device被创建时，内核会从设备树节点中提取资源，填充到对应的设备结构体中。驱动在probe函数中，通过一系列API获取这些资源：

platform_get_resource()：获取platform设备的IO资源（寄存器地址范围）
platform_get_irq()：获取中断号
devm_clk_get()：获取时钟句柄
devm_gpiod_get()：获取GPIO描述符
devm_regulator_get()：获取电源调节器
of_property_read_u32()：读取自定义属性

对于i2c client，资源获取方式略有不同。i2c client的寄存器地址由设备树中的reg属性自动填充到i2c_client.addr字段，驱动无需手动获取。但Sensor的GPIO、时钟、电源等资源，仍然需要通过上述API从设备树节点中获取。这里有一个重要的工程经验：尽量使用devm_系列API（设备资源管理），它们会在设备注销时自动释放资源，避免内存泄漏和资源泄漏。

经验提醒：在编写Camera Sensor驱动时，probe函数中获取资源的顺序建议为：先获取时钟和电源（保证芯片能工作），再获取GPIO（控制复位和上电时序），最后获取中断（确保中断源已就绪）。如果资源获取失败，应返回-EPROBE_DEFER，让内核在依赖资源就绪后重新尝试probe。

3.4 probe流程的完整拆解与实战案例

probe函数是驱动初始化的核心入口，它的执行质量直接决定了设备能否正常工作。以一颗典型的Camera Sensor（OV5640）为例，完整的probe流程可以分为五个阶段：匹配确认、资源获取、硬件初始化、V4L2子设备注册、media实体创建。下面通过一个实际案例来拆解这个过程。

案例：OV5640 Sensor驱动的probe流程

背景与约束：某项目使用Rockchip RK3568平台，外接OV5640 Sensor，通过MIPI CSI-2接口连接。Sensor的I2C地址为0x3C，使用24MHz外部时钟，需要AVDD 2.8V、DVDD 1.5V、DOVDD 1.8V三路电源。复位引脚GPIO2_B6低有效，PWDN引脚GPIO2_B7高有效。

初始现象：驱动加载后，dmesg中未出现probe成功日志，Sensor无法输出图像。通过调试发现，probe函数在获取时钟资源时返回-ENOENT，导致probe失败。

分析过程：检查设备树，发现时钟属性配置为clocks = <&cru CLK_MIPI_CAMERAOUT>，但RK3568的时钟驱动中该时钟并未被正确使能。进一步排查，发现该时钟的父时钟未在bootloader中初始化，导致时钟框架无法获取有效的时钟频率。

解决步骤：

在设备树中为Sensor添加assigned-clocks和assigned-clock-rates属性，强制指定时钟频率为24MHz：

assigned-clocks = <&cru CLK_MIPI_CAMERAOUT>;
assigned-clock-rates = <24000000>;

在probe函数中增加时钟频率校验，确保获取到的时钟频率在Sensor允许的范围内（OV5640允许6-27MHz）：

unsigned long xclk_rate = clk_get_rate(sensor->xclk);
if (xclk_rate < 6000000 || xclk_rate > 27000000) {
    dev_err(&client->dev, "Invalid xclk rate: %lu\n", xclk_rate);
    return -EINVAL;
}

重新编译内核和设备树，启动后probe成功，Sensor正常输出图像。

结果对比：修复前probe返回-ENOENT，设备无法注册；修复后probe成功，/dev/video0节点正常创建，通过v4l2-ctl可以采集到图像。

复盘经验：Camera Sensor的probe失败，60%以上与时钟和电源相关。建议在probe函数中增加详细的资源获取日志，并在设备树中明确指定时钟频率和电源电压。此外，-EPROBE_DEFER的使用要谨慎，如果依赖的资源永远无法就绪，会导致probe无限重试，此时应检查依赖资源的驱动是否加载成功。

3.5 常见误区与总结复盘

在设备模型和probe流程的学习中，开发者容易陷入以下几个误区：

误区一：混淆platform device和i2c client的probe时机。platform device的probe在设备树解析完成后立即执行，而i2c client的probe需要等待I2C总线驱动就绪。如果Sensor的probe依赖某个platform device提供的资源，必须使用-EPROBE_DEFER机制，而不是盲目重试。

误区二：忽略设备树中的status属性。设备树节点默认是"okay"状态，但如果节点被标记为"disabled"，内核不会创建设备，probe也不会被调用。在调试时，务必检查status属性。

误区三：在probe中直接使用GPIO编号而非GPIO描述符。现代内核推荐使用devm_gpiod_get()获取GPIO描述符，而不是通过gpio_request()加数字编号。前者支持设备树中的GPIO极性配置，且自动管理生命周期。

总结来看，Linux内核设备模型为Camera子系统提供了清晰的抽象层次：设备树描述硬件，platform device和i2c client承载设备，驱动通过匹配机制找到设备，probe函数完成初始化。掌握这一链路，是编写高质量Camera驱动的基石。在实际开发中，建议开发者养成"先看设备树，再看驱动probe，最后看内核日志"的调试习惯，这能大幅缩短问题定位时间。

调试场景	关键检查点	常用命令/工具
设备未创建	设备树status属性、compatible匹配	ls /sys/bus/platform/devices/
probe未调用	驱动是否注册、of_match_table是否匹配	dmesg \| grep -i probe
资源获取失败	时钟、电源、GPIO配置	cat /sys/kernel/debug/clk/clk_summary
Sensor无输出	MIPI信号、I2C通信、电源时序	i2cdetect -y 2、v4l2-ctl --list-devices