专栏目录：专栏目录传送门

平台	内核
i.MX8MP	5.15.71

pinctl的调用栈可以分为两类，一类是pinctl驱动初始化；另一类是其他子设备设置pinctl。对于第二种情况，pinctl的调用出现在 process_one_work阶段。

1.pinctl驱动初始化

在内核初始化过程中，do_one_initcall会扫描设备树添加设备，如果设备树节点和驱动匹配，则就去probe这个驱动，对于这里的pinctrl设备来说，就会进入到imx_pinctrl_probe函数中【i.MX8MP平台开发分享（IOMUX篇）- imx_pinctrl_probe函数梳理以及重要结构体】，设置pinctl的操作函数，比如怎么设置寄存器实现需要的mux功能，怎么配置PAD属性等函数。最后pinctrl_enable将这个设备添加pinctrl框架维护的设备列表。

其中在pinctrl_enable函数中呢，又会使用pinctrl_claim_hogs接口检索dts相关信息中是否存在default state。如果检测到default状态后，会将对应的pin脚在pinctrl driver中的相关管脚复用、上下拉等配置配置好。

kernel_init//start_kernel最后的函数
kernel_init_freeable//包含初始化总线模型
do_one_initcall //激活所有级别的驱动入口
<----------------------->
of_platform_default_populate_init //处理设备树
of_platform_bus_create
of_device_add //根据设备树的匹配信息，添加一个设备，这里添加的是pinctrl设备
device_add
device_initial_probe //probe设备
__device_attach //attach上这个设备
__device_attach_driver //将驱动绑定到这个设备上
driver_probe_device 
really_probe->platform_probe
<----------------------->
imx8mp_pinctrl_probe //probe pinctrl驱动
imx_pinctrl_probe
pinctrl_enable	//
pinctrl_commit_state
pinmux_enable_setting
imx_pmx_set

2.process_one_work阶段

有时候，驱动程序的probe顺序很重要，但是内核并不总是有驱动之间的依赖性关系，这意味着一些驱动程序会在它所依赖的资源可用之前被probe。 例如，一个SDHCI驱动可能首先需要一条来自i2c GPIO控制器的GPIO引脚，然后才能被初始化。 如果所需的资源还不可用，驱动程序可以通过从其probe函数返回-EPROBE_DEFER来请求推迟probe。

延迟probe维护两个设备列表，一个是pending列表，一个是active列表。 驱动程序返回-EPROBE_DEFER会导致设备被添加到pending列表中。 一旦出现一个成功的probe，将触发将其设备从pending列表移到active列表，这样工作队列最终会重试它们，也就是deferred_probe_work_func来处理未probe成功的驱动。【怎么理解一旦出现一个成功的probe？可能在这个probe之前，都是失败的probe，出现这个probe意味着大部分系统资源已经就绪】

内核中工作队列的线程初始化过程：

workqueue_init
->create_worker
	->worker_thread
    	->process_one_work
			->deferred_probe_work_func / other work

首先DECLARE_WORK定义了一个probe工作任务。

static DECLARE_WORK(deferred_probe_work, deferred_probe_work_func);

然后deferred_probe_initcall->driver_deferred_probe_trigger会将这个任务添加到system_unbound_wq队列中并唤醒线程，也就是执行deferred_probe_work_func函数。

queue_work(system_unbound_wq, &deferred_probe_work);

deferred_probe_work_func处理active链表中的每一个设备。其中的每一个设备都会从active链表中被移除，并且bus_probe_device()来重新probe该设备的驱动。这个函数会一直循环直到active链表中的每一个设备被移除。

bus_probe_device还是会使用device_initial_probe来调用各厂商定义的函数处理pinctl。

device_initial_probe
	->pinctrl_bind_pins
		->pinctrl_select_state
			->imx_pmx_set

3.疑问

为什么上面deferred_probe_work_func是处理active链表，那pending链表又起什么作用？它们两个有什么关系？

在内核启动初期，内核会尝试将所有匹配上的驱动probe一遍，如果返回-EPROBE_DEFER【驱动所需资源未就绪时】就会触发driver_deferred_probe_add将不成功的设备一个个添加到deferred_probe_pending_list链表中。在最后【7s级别】的initcall函数deferred_probe_initcall中driver_deferred_probe_trigger将所有pending链表中的设备转移到active链表，然后queue_work激活deferred_probe_work任务。于是deferred_probe_work_func就会一个个地从active链表中获取设备并重新probe它们。