DM模型probe的调用时机

最新推荐文章于 2024-03-05 18:14:48 发布

bashell

最新推荐文章于 2024-03-05 18:14:48 发布

阅读量879

点赞数

分类专栏： uboot 文章标签： uboot

本文链接：https://blog.youkuaiyun.com/bashell/article/details/114624210

版权

uboot 专栏收录该内容

2 篇文章

订阅专栏

版本：uboot2019
平台：arm926

背景：最近调试gpio驱动发现一直没有进入.probe()，已经确认compatible匹配ok，driver和device已经关联上。但是很艰难才找到调用.probe()的位置。

在此记录gpio驱动调用.probed()的流程：

gpio_request->
gpio_to_device->
uclass_first_device->
uclass_get_device_tail->
device_probe->
uclass_get_device_by_seq->
uclass_get_device_tail->
device_probe->
xxxx_gpio_probe

可以推断很多模块的probe都是在确认系统被使用的时候才会调用.probe()。
由于原系统没有调用gpio_request()所以不会调用gpio.probe()，因此豁然开朗。

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

bashell

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

Linux驱动：probe函数何时被调用

weixin_44498318的博客

06-03

2890

linux中 probe函数何时调用的所以的驱动教程上都说：只有设备和驱动的名字匹配，BUS就会调用驱动的probe函数，但是有时我们要看看probe函数里面到底做了什么，还有传递给probe函数的参数我们就不知道在哪定义（反正不是我们在驱动里定义的），如果不知道传递进的参数，去看probe函数总是感觉不求甚解...

uboot 驱动模型框架分析(DM)

zhangjianjun521的博客

04-15

2608

本文只是简单记录自己对uboot 驱动模型框架的梳理，这些东西比较琐碎，由于时间原因，没有整理成为一个系统的东西，可以理解为一个笔记在uboot驱动模型中，有uclass，uclass driver，udevice， udevice driver结构体，每一个具体的设备，使用udevice结构体描述，udevice设备对应的驱动为driver。 uclass描述一种设备类型的集合，udevice挂载uclass上，uclass driver为uclass对应的驱动。代码上，uclass，uc.

参与评论您还未登录，请先登录后发表或查看评论

probe 调用流程

Yasin Lee

08-05

2080

这是目前讲的最清楚的一个了。。。。。 最近小小的接触了下usb的驱动, 想搞清楚probe的调用机制, 不过懒人一个, 懒得去看源码, 在Google搜了下, 果然有结果, 引用过来, 留作纪念!!!! ============== 本文将详细讲述2.6.22下的一个USB设备插上linux系统的PC后是如何一步一步调到我们的usb设备驱动的probe函数的,我们知道我们的USB驱动的probe函数中的一个参数是i

uboot移植和驱动开发的知识点

Answer的博客

11-19

405

uboot 的移植并不是说我们完完全全的从零开始将 uboot 移植到我们现在所使用的开发板或者开发平台上。半导体厂商负责将 uboot 移植到他们的芯片上，因此半导体厂商都会自己做一个开发板，这个开发板就叫做原厂开发板，比如大家学习 STM32的时候听说过的discover 开发板就是ST自己做的。

linux driver probe 调用时机

piaomiaoju的专栏

07-02

1542

1、platform 设备创建时候，device_register->bus_probe_devce->device_attt

u-boot下的DM驱动模型

iysheng的博客

04-12

8118

uboot中添加自己的驱动（misc）

lkdom

07-22

3920

在项目中我们时常遇到需要天气控制的GPIO，需要在UBOOT中就将IO控制起来，所以针对这个问题我写了这篇博文来分享我在项目中是怎么在uboot中添加我们自己的驱动的，并且通过驱动去获取我们在设备树中添加的设备属性，获取IO属性，并且操控我们的GPIO而今天我们的猪脚就是上面的这个节点，我们要去控制eeprom_wp中的这个IO，通过控制这个IO展开分享。这样在启动的时候就会去调用我们自己创建的函数了。......

【u-boot】u-boot源码分析笔记（07）| u-boot驱动模型分析_01

iriczhao的博客

08-06

1622

u-boot有一个功能强大的驱动模型，这一点与linux内核一致。驱动模型对设备驱动相关操作做了一个抽象：使用来描述设备类，使用来描述驱动，使用来描述设备。（1-1）uclassuclass表示以相同特征方式运行的一组device。uclass提供一种以相同接口方式访问组内单个设备的方式。例如：GPIO类提供了get/set值的操作。一个I2C类可能有10个I2C端口，其中4个用于一个驱动程序，6个用于另一个驱动程序。该结构由表示（/include/dm/uclass.h）：（1-2）driver用于提供

uboot 驱动模型

qq_41483419的博客

03-08

1534

UBOOT驱动模型

详解Linux驱动中，probe函数何时被调用

01-10

最近看到linux的设备驱动模型，关于Kobject、Kset等还不是很清淅。看到了struct device_driver这个结构时，想到一个问题：它的初始化函数到底在哪里调用呢？以前搞PCI驱动时用pci驱动注册函数就可以调用它，搞s3c...

pci设备probe函数的调用时机

liuqiang_mail的专栏

08-21

1910

int __init wwinit(void){ int ret; printk(KERN_ALERT \"\\n\\n\\n\\n\"); wwlogk(\"wwinit: entering - VID=0x%x, DID=0x%x\\n\", WWVID, WWDID); //###############1 ww_init(); ret = all

【uboot】uboot 2020.04 DM驱动模式 -- Demo体验

ZHONGCAI0901的博客

06-05

2378

文章目录1. 前言2. uboot的驱动模型简介 1. 前言本篇文章是基于IMX6ULL平台uboot 2020.04源码分析DM驱动模式是如何使用的。IMX6ULL平台uboot源码下载可以参考这篇文章《【uboot】imx6ull uboot 2020.04源码下载和编译环境配置》。 2. uboot的驱动模型简介 uboot引入了驱动模型（driver model）简称为DM，这种驱动模型为驱动的定义和访问接口提供了统一的方法。提高了驱动之间的兼容性以及访问的标准型。 uboot官网有对DM的使用介

u-boot的DM驱动模型

个人学习记录

03-05

1782

驱动平台私有数据，在设备匹配时会自动为私有数据分配空间；这部分一般不用开发者编写，这里主要是为了梳理DM的流程。：和设备树匹配后，会进入这个函数；的设备，驱动和上层之间的桥梁是通过。：为u-boot上层提供统一接口。：指明驱动的类型，用于匹配。：获取设备树的属性的函数；是注册硬件驱动的接口；

工程分析 - u-boot

uncle103的博客

01-21

1164

uboot 编译环境 qemu 学习资料 vexpress a9 学习资料 3.1 qemu 对 vexpress的介绍：mothter board + daughter card 3.2 Versatile Express 的一篇wiki 使用uboot编译vexpress 4.1 编译方法1 4.2 编译方法2

[uboot] （番外篇）uboot dm-gpio使用方法以及工作流程

最新发布

03-19

<think>好的，我现在需要帮助用户了解如何激活U-Boot中的probe函数。用户之前已经询问过probe和ofdata_to_platdata函数的区别及调用时机，现在他们想知道如何具体激活probe函数。首先，我得回忆一下之前的回答。之前提到过probe函数是在设备激活时被调用的，通常在board_init阶段，调用路径是device_probe() -> drv->probe()。用户现在可能是在实际开发中遇到了probe没有被执行的情况，需要知道如何触发它的执行。接下来，我需要详细解释激活probe的条件和步骤。可能的要点包括设备与驱动的正确绑定、设备树节点的正确配置、U-Boot的初始化流程，以及手动触发的方法。用户可能对设备树的配置不太清楚，比如compatible属性是否正确匹配驱动中的of_match。这时候需要举例说明设备树节点的写法，确保compatible字符串与驱动中的一致。同时，要提到检查U-Boot是否启用了设备树（OF_CONTROL）和对应的驱动是否被编译进去。另外，U-Boot的初始化流程中，dm_init_and_scan会在relocation之后扫描设备树并绑定驱动，这时候会触发ofdata_to_platdata，之后在设备探测阶段调用probe。用户可能需要知道这些阶段是如何衔接的，或者是否有必要在特定阶段手动调用device_probe()。还有，用户可能遇到设备状态的问题，比如设备没有被正确标记为激活状态，或者依赖的其他驱动没有先初始化。这时候需要说明检查设备状态的方法，比如使用dm命令查看设备状态，或者确保依赖关系正确。手动触发的情况，比如在命令行通过dm命令调用probe，或者在代码中主动调用device_probe(dev)，这也是一个可能的解决方案，适用于调试或者特定需求。需要考虑用户的潜在问题，比如设备树配置错误、驱动未正确注册、编译选项未开启等。因此，在回答中需要涵盖这些检查点，并提供示例代码或命令帮助用户验证。最后，总结激活probe的关键步骤，确保用户能按顺序排查问题，从设备树配置到驱动匹配，再到初始化流程和手动触发方法，逐步解决问题。</think>在U-Boot驱动框架中，`probe`函数的激活需要满足**设备驱动绑定成功**和**设备初始化触发条件**。以下是具体步骤和原理： --- ### 一、激活`probe`函数的核心条件 1. **驱动与设备绑定成功** - 设备树（DeviceTree）中存在与驱动`of_match`兼容的节点（即`compatible`属性匹配）。 - 驱动通过`U_BOOT_DRIVER`宏正确注册到U-Boot驱动模型（Driver Model, DM）。 2. **设备初始化流程触发** - U-Boot启动时自动激活（默认流程）。 - 手动调用设备探测接口（调试或特殊场景）。 --- ### 二、自动激活流程（默认场景） #### 1. **U-Boot初始化阶段** - **触发时机**：在`board_init()`或`board_init_r()`阶段，通过以下流程激活： ```text board_init() → dm_init_and_scan() → dm_extended_scan_fdt() → device_probe() ``` - **关键步骤**： 1. **设备树扫描**：解析设备树，匹配驱动与设备节点（通过`compatible`属性）。 2. **设备绑定驱动**：调用`device_bind_driver()`绑定驱动，触发`ofdata_to_platdata`。 3. **设备激活**：最终调用`device_probe()`执行`probe`函数。 #### 2. **依赖的编译配置** - 确保驱动代码被编译进U-Boot镜像（检查Kconfig或Makefile）。 - 启用设备树支持（`CONFIG_OF_CONTROL=y`）。 - 驱动声明了正确的`U_BOOT_DRIVER`结构（包含`.probe`函数指针）。 --- ### 三、手动激活方法（调试或特殊需求） #### 1. **命令行触发（U-Boot Shell）** - 使用`dm`命令手动探测设备： ```bash # 查看所有设备状态 dm tree # 手动触发指定设备的probe dm probe <device-name> ``` - 示例：激活名为`mmc@12345678`的设备： ```bash dm probe mmc@12345678 ``` #### 2. **代码中主动调用** - 在自定义初始化代码中调用`device_probe()`： ```c struct udevice *dev; int ret = uclass_get_device_by_name(UCLASS_MMC, "mmc@12345678", &dev); if (!ret) ret = device_probe(dev); // 手动触发probe ``` --- ### 四、常见问题排查如果`probe`未执行，需检查以下内容： 1. **设备树配置** - 设备节点的`compatible`属性是否与驱动`of_match`完全匹配。 - 示例：驱动定义： ```c static const struct udevice_id my_driver_ids[] = { { .compatible = "vendor,my-device" }, // 必须与设备树一致 { } }; ``` - 设备树节点需包含： ```dts my_device: my-device@0 { compatible = "vendor,my-device"; // 字符串匹配 reg = <0x0 0x1000>; }; ``` 2. **驱动注册状态** - 检查驱动是否通过`U_BOOT_DRIVER`宏注册，且未被条件编译排除。 - 确认`.probe`函数指针已赋值（例如：`.probe = my_probe`）。 3. **设备状态检查** - 使用`dm tree`命令查看设备是否处于`active`状态。 - 若设备状态为`inactive`，可能是依赖的父设备未初始化。 --- ### 五、流程图解 ```text 启动U-Boot → 解析设备树 → 绑定驱动（ofdata_to_platdata） → 设备激活（probe） ↑ ↑ | | 手动调用dm probe或device_probe()—————┘ ``` --- ### 六、总结 - **自动激活**：依赖U-Boot标准初始化流程，需确保设备树和驱动配置正确。 - **手动激活**：通过命令行或代码主动触发，适用于调试或复杂初始化场景。 - **关键检查点**：设备树兼容性、驱动注册状态、设备依赖关系。