linux驱动学习-Linux驱动中的Core、Bus与Driver是什么关系

Driver Core: Linux通用设备模型

Driver Core 是 Linux 通用设备模型的基础设施，很多 bus、device、driver、class 以及 bind/probe/sysfs 机制都建立在它之上。

Driver Core
│
├─ device
├─ driver
├─ bus
├─ class
├─ bind / unbind
├─ probe
└─ sysfs

Driver Core 管匹配流程，Bus 决定匹配规则。

不同的bus有不同的匹配方法，比如platform、USB、I2C的匹配机制如下：

platform
→ compatible / name / ACPI

USB
→ VID / PID / Class / Interface

I2C
→ compatible / id 等

最基础的 cdev 本身不要求存在 bus/device/driver 的匹配过程。

如果把字符设备放进 platform_driver 中，则先由 platform bus 完成匹配并进入 probe，再在 probe 中注册 cdev。

由此引出了一个结论，bus不管它是不是有真实的硬件，有device和driver，以及match就会做匹配，即使是架空的字符设备。

纯 cdev
≠ 必须有 bus/device/driver match

platform + cdev
→ 有 platform bus match
→ probe 以后再注册 cdev

这一层就是具体到某一个功能的总管理层了，主要是涉及功能实现。例如gpio

GPIO Core:
gpio_chip、gpio_desc、consumer查找、set/get、driction等

而具体的gpio driver只是硬件上的差异，于是有：

consumer
↓
GPIO API
↓
GPIO Core
↓
gpio_chip->set()
↓
具体的GPIO driver
↓
寄存器

以前做了v4l2的仿写，但是对于实际它的上下流程不太清楚。经过学习后发现还不跟常规的一样。一个uvcvideo同时连接了两个系统。下面是它建立流程:

USB Camera
↓
USB Core
↓
USB bus匹配
↓
uvcvideo
↓
注册 video_device
↓
V4L2 Core
↓
/dev/video0

从上面可见，它经过了USB bus的匹配，但是没有经过V4L2 bus的匹配，或者说根本没有这个bus。但确实v4l2也有自己的子系统。

它的使用也很简单，用户通过调用/dev/video0，可以直接操作->V4L2 Core->uvcvideo(上至V4L2接口，下至USB传输)->USB Core->USB Controller->USB Camera

下面具体到某一个i2c的v4l2设备IMX415，它的情况甚至还完全不一样：

IMX415 sensor
↓
创建 i2c_client
↓
I2C bus 匹配
↓
imx415 driver
↓
注册 v4l2_subdev
↓
进入 V4L2 / Media 子系统

I2C 本身不是 USB 那种 self-enumerating bus。

所以系统通常要通过 DT / ACPI / board info 等先创建 i2c_client，之后 I2C bus 还是会正常完成 driver matching。

但通过i2c创建的这个driver本身并不会生成/dev/video0，只是负责控制Camera设备。

sensor driver 通常只注册 v4l2_subdev；最终 /dev/videoX 一般由整个 SoC capture/media pipeline 中的视频采集端产生。

无