Linux pinctrl子系统分析之二 从数据结构关联理解pinctrl子系统

本文详细解析了Linux内核pinctrl子系统的架构,涵盖了数据结构关联、socpin与boardpin描述以及dev与pinctrl的关联,阐述了如何通过数据结构间的关联来理解pinctrl子系统的设计。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

     上一章我们对pinctrl子系统进行概述,说明了pinctrl子系统相关的概念、软件框架等内容,本章我们主要从pinctrl子系统数据结构间的关联,从而理解pinctrl子系统的设计。

 

 

 

pinctrl数据结构说明

      在上一章我们画出了pinctrl子系统的软件架构(如下图所示),而在linux内核的各子系统设计过程中,软件框架基本上就是由数据结构间关联以及对外接口实现子系统的设计,因此理解了一个子系统数据结构间的关联,基本上就掌握了一个子系统大致实现流程。在linux 内核中,当学习一个新的子系统中,先熟悉其数据结构,基本上可以做到事半功倍。

 

      我们首先理清数据结构间的关联。如下图,通过pinctrl子系统的数据结构、处理接口构建的pinctrl子系统框架。下面我们分类说明。

 

Soc pin 描述

       针对一款soc芯片,我们通过其数据手册,可以知道其提供的引脚个数、每一个引脚复用情况、每一个引脚的配置信息、每一个function包含的引脚使用组合(如iic0可以支持{pin8、pin9}、{pin20、pin21}两种group类型供选择,而基于该款soc设计的开发板,则需要针对iic0选择一组作为iic0的引脚。如开发板1基于该soc选择{pin8、pin9}作为iic0的引脚,而开发板2基于该soc选择{pin20、pin21}作为iic0的引脚)等信息。而针对soc芯片而言,其无需关注具体基于该soc的开发板的引脚复用,其只需要列出该soc芯片针对引脚配置的所有信息即可。

   在pinctrl子系统中,soc pin controller的描述通过数据结构struct pinctrl_dev描述,其包含如下信息:

  1. 存储该soc支持的所有引脚的描述,此处使用基数树pin_desc_tree存储所有struct pin_desc类型的变量,而struct pin_desc主要描述一个pin引脚,包括该引脚当前配置的引脚复用情况、引脚名称、引脚复用设置的次数,以及该引脚所属的pinctrl device;
  2. 存储该soc支持的所有group的描述(该项内容在4.4以后的内核版本中添加的,在之前的版本中,group与function的描述由各soc pin controller自行描述,struct pinctrl_dev中没有描述,pinctrl子系统只要求各soc pin controller driver提供group、function的访问方法即可,其不进行function与group的存储情况,而在4.4内核以后,pinctrl子系统提供了function与gropu的存储,均是通过基数树进行存储,并定义struct group_desc 、struct function_desc描述group、function ),新的内核版本将group、function也纳入pinctrl子系统的管理确实是一个大的提升,因为pinctrl子系统没有提供group、function存储时,各soc pin controller driver定义的group、function数据结构基本上是类似的,因此这些数据结构由pinctrl子系统接管是最好的。
  3. 存储该soc支持的所有function的描述;
  4. 提供引脚复用相关的操作接口(struct pinmux_ops定义的操作接口);
  5. 提供引脚配置相关的操作接口(struct pinconf_ops定义的操作接口)

 

       以上几点就完整的描述了soc pin controller相关的信息,包含哪些引脚、包含哪些可能的组合、包含哪些可能功能、引脚配置相关的操作接口、引脚复用相关的操作接口等信息。关于pinctrl dev及引脚配置、引脚复用相关的驱动均是由soc 厂家提供。soc厂家提供了进行引脚分配及复用的接口,而具体怎么用,则由使用该soc的厂商决定。

 

board pin 描述

      上面讲的pinctrl_dev对应的是soc pin controller,而此处介绍的board pin描述,则是针对使用soc芯片的board,其所对应的具体的引脚使用,这部分引脚使用由具体的开发板厂家分配,也就是我们大部分驱动工程师的工作。下面即介绍board pin描述相关的信息。

    在pinctrl 子系统中,使用数据结构struct pinctrl_maps描述一个board的引脚使用情况,包含引脚的复用以及引脚配置信息等。具体包含如下信息:

  1. 每一个struct pinctrl_map表示一个function在某一个状态下对应的引脚复用及引脚配置信息,包含:
    1. function名称、状态名称(default、sleep、idle等);
    2. 所属pinctrl dev的名称、dev名称(即该pinctrl_map所依附的设备名称,如iic1等)
    3. map类型(引脚复用、引脚配置、group配置等)。
    4. 针对引脚复用,则包含function名称、group名称,通过pinctrl dev名称、function名称、group名称即可查找具体的pins信息。
    5. 针对pin/group配置,则包含group或pin名称,引脚配置信息等内容。

 

       针对板级引脚描述而言,主要描述该board所需要设置的所有function对应的引脚复用、引脚配置信息。针对board pin描述而言,基本上就是我们大部分驱动工程师的工作。但针对现有的pinctrl子系统而言,我们也就只需要在dts中配置一下引脚复用及配置情况即可。若内核不支持设备树,则需要在板级文件中定义引脚复用情况,并调用pinctrl_register_maps将其注册到pinctrl子系统即可。

 

       以上soc pin以及board pin以及完成了soc pin controller、board pin config and pin mux的描述,那board pin config and pin mux是如何完成针对具体device的配置的呢?这就涉及dev与pinctrl之间的关联了。pinctrl子系统在设计时,为了让具体外设设备驱动开发者对pin ctrl子系统无感知,在struct device中实现了该device与具体引脚配置function的关联,并在设备驱动模型子系统的device_driver probe之前,完成引脚的配置(主要通过pinctrl_bind_pins函数实现)。下一个小节则介绍dev与pinctrl的关联。

 

Dev与pinctrl关联描述

      如下图所示,struct device总增加了struct dev_pin_info类型的数据结构,实现了dev与pinctrl子系统进行的关联。

struct dev_pin_info包含如下信息:

  1. 该device pin支持的状态,包括idle_state状态下的引脚配置参数、init state下的引脚配置参数、default_state状态下的引脚配置参数(大多数设备一般只需要定义一个default state即可。只有少数的设备,其正常工作状态下与sleep状态下,引脚复用不同,如在sleep状态下可以释放该引脚,由别的设备使用,一般的话只需要设置default_state即可);
  2. struct pinctrl表示一个设备针对引脚控制的holder,其包括
    1. 该device所支持的引脚控制状态(如支持default、sleep状态的引脚控制策略);
    2. 每一个状态通过struct pinctrl_state描述,一个pinctrl state中包含该state下需要进行的设置策略(可有多个设置策略,每一个设置策略对应一个struct pinctrl_setting类型的变量,设置策略包含引脚复用的设置策略、引脚的配置策略、group的配置策略,针对一个device的一个state,可以包含多个引脚复用、引脚配置的策略),而struct pinctrl_setting类型主要根据function、group名称

 

 

 

 

 

         通过上面的soc pin controller 描述、board pin 描述、dev与pinctrl关联描述,即可完成引脚复用的配置以及引脚的配置。通过soc pin controller描述,说明一个soc pin controller支持的所有引脚、group、function等描述;通过board pin描述,说明一个board对引脚功能、引脚配置、引脚复用的使用情况;最后借助dev与pinctrl子系统的关联,将board pin描述与soc pin controller描述关联,并完成引脚的具体配置操作。以上就是本篇文章的主要内容。我们通过数据结构之间的关联,说明pinctrl子系统的设计框架。下一章介绍具体的数据结构定义。

<think>嗯,用户想深入了解Linux驱动开发中的pinctrl子系统,这属于嵌入式Linux的核心内容。从用户提问的精准度看,应该是有一定驱动开发基础的技术人员,可能正在调试板级引脚配置。 用户提供的引用材料很全面,覆盖了pinctrl的架构设计、设备树集成、GPIO子系统联动等关键点。特别注意到引用[3]详细描述了pinctrl_dev结构体,这是理解子系统内部机制的重要突破口。用户可能最关心的是如何在实际驱动中正确应用pinctrl,而不仅是理论概念。 需要重点解释清楚三个层次:首先是子系统存在的必要性——为什么裸机寄存器操作被淘汰(如引用[5]对比的STM32/IMX6ULL案例);其次是设备树配置的实践细节(引用[1][2]强调的设备树依赖);最后是驱动代码中的API调用时机(引用[4]的LED控制示例很典型)。 用户可能隐含的需求是解决实际引脚冲突问题,比如某个GPIO无法正确复用为I2C功能。因此回复中要突出“状态切换”这个易错点,通过休眠/唤醒的状态机示例说明配置流程。对于结构体字段这类底层细节,采用表格对比更直观,但需控制深度避免信息过载。 最后生成的问题要引导用户向具体场景延伸:比如针对功耗优化场景询问pinctrl的省电配置,或者结合GPIO子系统讨论中断处理。这样既能检验理解程度,又切合实际开发需求。</think>好的,我们来详细解析 Linux 驱动开发中的 `pinctrl` 子系统。 ## 1. 为什么需要 `pinctrl` 子系统? 在现代复杂的系统级芯片(SoC)上,一个物理引脚(Pin)通常具有多种功能(复用功能)。例如,一个引脚可能可以被配置为: * 通用输入/输出引脚(GPIO) * I²C 总线的时钟线(SCL)或数据线(SDA) * SPI 总线的片选(CS)、时钟(SCK)、数据输入(MISO)或数据输出(MOSI) * UART 的发送(TX)或接收(RX) * PWM 输出 * 等等 同时,每个引脚可能还需要配置其电气特性,如上拉/下拉电阻、驱动强度(输出电流能力)、施密特触发器使能、输入/输出模式(开漏、推挽)等。 在 `pinctrl` 子系统出现之前,这些配置通常分散在板级支持包(BSP)代码、具体驱动代码或 `arch/` 目录下的平台相关代码中。这导致了: 1. **代码重复:** 不同驱动需要重复实现引脚配置逻辑。 2. **维护困难:** 引脚配置与具体驱动和平台代码耦合紧密,改动困难。 3. **缺乏抽象:** 没有统一的接口管理引脚复用和配置。 4. **板级定制麻烦:** 为不同开发板适配引脚配置需要修改多处代码。 `pinctrl` 子系统的引入就是为了**统一管理 SoC 引脚的复用(Multiplexing)和配置(Configuration)**,提供一套标准的、与具体硬件无关的接口给内核其他部分(尤其是设备驱动)使用,并将引脚配置信息从驱动代码中剥离出来,放入设备树(Device Tree),极大地提高了代码的可重用性和可维护性[^1][^2][^5]。 ## 2. `pinctrl` 子系统核心概念 理解 `pinctrl` 子系统需要掌握几个关键概念: 1. **Pin Controller Device (引脚控制器设备):** * 这是物理上控制 SoC 上引脚复用和配置的硬件模块(通常是一个寄存器块)。 * 在设备树中,它表现为一个节点(例如 `&iomuxc` 或 `&pinctrl`),描述了这个控制器所能控制的所有引脚以及这些引脚可用的功能组(Pin Groups)和状态(Pin States)。 * 一个 SoC 可能包含多个 Pin Controller(例如,一个负责 Bank A,一个负责 Bank B)。 2. **Client Device (客户端设备):** * 这是需要使用引脚的设备,如 I2C 控制器、SPI 控制器、UART 控制器、MMC/SD 控制器、GPIO 控制器本身,甚至是一个简单的 LED 设备。 * 在设备树中,它表现为一个设备节点(例如 `&i2c1`, `&usdhc1`)。 * 它通过 `pinctrl-` 属性(如 `pinctrl-0`, `pinctrl-1`, ... `pinctrl-names`)来引用 Pin Controller 中定义好的引脚状态(Pin States),告诉内核它需要哪种引脚配置。 3. **Pin State (引脚状态):** * 这是 `pinctrl` 子系统的核心抽象。它代表了一组引脚在某个特定时刻的配置集合。 * 在 Pin Controller 的设备树节点中,使用节点来定义不同的状态。常见的预定义状态名包括: * `default`: 设备正常操作时需要的状态。 * `init`: 设备初始化时可能需要的特殊状态(有时与 `default` 合并)。 * `sleep`, `idle`: 设备进入低功耗状态(睡眠、空闲)时需要的状态。 * 驱动也可以定义和使用自定义状态名(如 `active`, `inactive`)。 * 每个状态节点内部使用 `pinctrl` 绑定规定的属性(如 `fsl,pins`,具体属性名由 SoC 厂商的 Pin Controller 驱动定义)来描述该状态下涉及的**引脚组(Pin Group)**及其**复用功能**和**电气属性配置**。 4. **Pin Group (引脚组):** * 指逻辑上属于同一功能的一组引脚。例如,一个 UART 的 TX 和 RX 引脚可以组成一个名为 `uart1grp` 的组;一个 SPI 接口的 4 个引脚(CS, SCK, MISO, MOSI)可以组成名为 `spi0grp` 的组。 * 在 Pin Controller 设备树节点中定义的状态节点里,配置信息通常就是按组(或单个引脚)来指定的。组名通常作为状态节点的属性值出现。 5. **Pin Bank:** * 指物理上属于同一个寄存器块控制的一组引脚。通常一个 Pin Controller 可能管理多个 Bank。例如,一个 32 位寄存器控制 Bank A 的 32 个引脚,另一个 32 位寄存器控制 Bank B 的 32 个引脚。 * 这个概念更多存在于 Pin Controller 驱动实现的底层,对使用 `pinctrl` 的设备驱动通常是透明的[^1][^3]。 ## 3. `pinctrl` 子系统的工作原理与流程 1. **设备树描述:** * **Pin Controller 节点:** SoC 厂商或板级支持包(BSP)开发者在设备树(`.dtsi` 或 `.dts` 文件)中定义 Pin Controller 节点。在这个节点下,定义各种**状态节点**(如 `pinctrl_mydevice_default`),在每个状态节点内,使用 SoC 特定的属性(如 `fsl,pins`, `rockchip,pins`)列出该状态需要配置的**引脚组**(或单个引脚),并指定每个引脚的**复用功能编号**和**电气属性位掩码**。 * **Client Device 节点:** 设备驱动开发者或板级开发者在需要使用引脚的设备节点(如 `&i2c1`)中添加 `pinctrl-names` 和 `pinctrl-` 属性。例如: ```dts &i2c1 { pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_i2c1_default>; // 引用Pin Controller中定义的状态节点 pinctrl-1 = <&pinctrl_i2c1_sleep>; ... }; ``` 2. **内核启动/驱动加载:** * **Pin Controller 驱动注册:** 在内核启动过程中,特定 SoC 的 Pin Controller 驱动(通常是平台驱动)被加载。它解析设备树中对应的 Pin Controller 节点,创建并注册一个 `struct pinctrl_desc` 和 `struct pinctrl_dev` 结构体实例到 `pinctrl` 子系统核心[^3]。这个 `pinctrl_dev` 代表了物理的 Pin Controller 硬件。 * **状态解析与存储:** Pin Controller 驱动解析设备树中该 Pin Controller 节点下定义的所有状态节点,将配置信息存储在其私有数据结构中。 * **Client Device 驱动加载:** 当 Client Device 的驱动(如 `i2c-imx.c`)被加载时,其 `probe` 函数被调用。 * **获取 `pinctrl` 句柄:** 在 `probe` 函数中,驱动通常调用 `devm_pinctrl_get(dev)` 或 `pinctrl_get(dev)`。这个函数: * 根据设备节点(`dev->of_node`)查找 `pinctrl-names` 和 `pinctrl-` 属性。 * 找到关联的 Pin Controller (`pinctrl_dev`)。 * 遍历 `pinctrl-` 属性引用的所有状态节点(在 Pin Controller 节点下定义),并请求对应的 Pin Controller 驱动解析这些状态(如果还没解析的话)。 * 创建一个 `struct pinctrl` 对象来管理这个设备的所有状态,并返回一个 `struct pinctrl` 的句柄。 3. **状态选择与应用:** * **查找状态:** 驱动使用 `pinctrl_lookup_state(pinctrl, name)` 根据状态名(如 `"default"`)查找对应的 `struct pinctrl_state` 对象。 * **应用状态:** 驱动调用 `pinctrl_select_state(pinctrl, state)` 来应用该状态。这个函数最终会调用到关联的 Pin Controller 驱动注册的 `->set_state()` 或 `->set_mux()` / `->config_set()` 等操作函数。 * **硬件配置:** Pin Controller 驱动根据 `pinctrl_state` 中存储的配置信息(复用功能ID、电气属性掩码),操作 SoC 上实际的配置寄存器(MUX 寄存器、PAD 控制寄存器等),完成引脚复用功能和电气属性的设置[^3][^5]。 4. **状态切换(如休眠唤醒):** * 当设备需要进入低功耗状态(如 `suspend`)时,驱动(或 PM 子系统)会调用 `pinctrl_select_state(pinctrl, sleep_state)` 切换到休眠状态(如 `"sleep"`)。 * 当设备从低功耗状态恢复(`resume`)时,驱动会再次调用 `pinctrl_select_state(pinctrl, default_state)` 切换回默认状态。 ## 4. `pinctrl` 子系统与 GPIO 子系统的关系 这两个子系统紧密协作,但职责分明: * **`pinctrl` 子系统:** 负责引脚的**复用(Muxing)** 和 **配置(Configuration)**。它决定一个引脚当前是作为 GPIO 功能,还是作为某个特定外设(如 I2C、SPI)的功能。如果配置为 GPIO,它还负责设置该引脚作为 GPIO 时的基本电气属性(如上下拉、驱动强度)[^4][^5]。 * **GPIO 子系统:** 当引脚通过 `pinctrl` **配置为 GPIO 功能**后,GPIO 子系统负责提供 API 来**操作**这个 GPIO 引脚:设置方向(输入/输出)、读取输入电平、设置输出电平、申请/释放 GPIO、设置中断(如果该 GPIO 支持中断)等[^2][^4]。 **简单来说:`pinctrl` 决定了“这个引脚现在是什么(功能)”,GPIO 子系统决定了“当它是 GPIO 时,怎么操作它”。** 一个引脚必须先由 `pinctrl` 配置为 GPIO 功能,然后才能通过 GPIO 子系统 API 进行操作[^4][^5]。 ## 5. 关键数据结构(驱动开发者视角) 虽然驱动开发者通常不需要直接操作这些结构体内部,但了解它们有助于理解流程: 1. **`struct pinctrl_dev`:** * 代表一个注册到内核的 Pin Controller 硬件实例。 * 包含指向 `pinctrl_desc` 的指针、管理的引脚描述树、GPIO 范围列表、私有数据指针等[^3]。 * 由 SoC 厂商的 Pin Controller 驱动创建和注册。 2. **`struct pinctrl_desc`:** * 描述 Pin Controller 的能力和操作函数集。由 Pin Controller 驱动填充并传递给 `pinctrl_register()`。 * 关键成员: * `name`: 控制器名称。 * `pins`: `struct pinctrl_pin_desc` 数组,描述该控制器管理的所有物理引脚(名称、编号)。 * `npins`: `pins` 数组的大小。 * `pctlops`: `struct pinctrl_ops`,提供引脚/组枚举等操作。 * `pmxops`: `struct pinmux_ops`,提供引脚复用操作(核心)。 * `confops`: `struct pinconf_ops`,提供引脚配置操作(核心)。 * `owner`: 通常是 `THIS_MODULE`。 3. **`struct pinctrl`:** * 代表一个 Client Device 与 `pinctrl` 子系统关联。通过 `devm_pinctrl_get()` 或 `pinctrl_get()` 获得。 * 包含该设备在设备树中引用的所有状态。 4. **`struct pinctrl_state`:** * 代表一个引脚配置状态(如 `"default"`, `"sleep"`)。 * 包含该状态下需要应用的配置设置列表(指向底层 Pin Controller 驱动存储的实际配置数据)。 * 通过 `pinctrl_lookup_state()` 获得。 5. **`struct pinctrl_setting`:** * `pinctrl_state` 内部包含一个或多个 `pinctrl_setting`。 * 每个 `setting` 代表一个具体的操作:复用(`PIN_MAP_TYPE_MUX_GROUP`)或配置(`PIN_MAP_TYPE_CONFIGS_*`)一个引脚组。 ## 6. 在 Client Device 驱动中使用 `pinctrl`(典型代码片段) ```c #include <linux/pinctrl/consumer.h> // 必须包含 static int my_driver_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct pinctrl *pinctrl; struct pinctrl_state *default_state, *sleep_state; int ret; /* 1. 获取该设备的 pinctrl 句柄 */ pinctrl = devm_pinctrl_get(dev); if (IS_ERR(pinctrl)) { ret = PTR_ERR(pinctrl); dev_err(dev, "Failed to get pinctrl: %d\n", ret); return ret; // 或 probe deferral } /* 2. 查找需要的状态 */ default_state = pinctrl_lookup_state(pinctrl, PINCTRL_STATE_DEFAULT); // "default" if (IS_ERR(default_state)) { ret = PTR_ERR(default_state); dev_err(dev, "Failed to get default pinctrl state: %d\n", ret); goto err_pinctrl; } sleep_state = pinctrl_lookup_state(pinctrl, PINCTRL_STATE_SLEEP); // "sleep" if (IS_ERR(sleep_state)) { dev_warn(dev, "No sleep pinctrl state defined, ignoring\n"); sleep_state = NULL; // 不是所有设备都需要sleep状态 } /* 3. 应用默认状态 (通常在probe早期应用) */ ret = pinctrl_select_state(pinctrl, default_state); if (ret) { dev_err(dev, "Failed to apply default pinctrl state: %d\n", ret); goto err_pinctrl; } /* ... 驱动其他初始化代码 ... */ /* 存储 pinctrl 和 states 以备后用 (例如在 suspend/resume 中) */ my_priv_data->pinctrl = pinctrl; my_priv_data->default_state = default_state; my_priv_data->sleep_state = sleep_state; return 0; err_pinctrl: devm_pinctrl_put(pinctrl); // 如果使用 pinctrl_get() 则需要手动调用 return ret; } static int my_driver_suspend(struct device *dev) { struct my_priv_data *priv = dev_get_drvdata(dev); int ret = 0; if (priv->sleep_state) { ret = pinctrl_select_state(priv->pinctrl, priv->sleep_state); if (ret) dev_warn(dev, "Failed to apply sleep pinctrl state: %d\n", ret); } /* ... 其他 suspend 操作 ... */ return ret; } static int my_driver_resume(struct device *dev) { struct my_priv_data *priv = dev_get_drvdata(dev); int ret = 0; /* ... 其他 resume 操作 ... */ ret = pinctrl_select_state(priv->pinctrl, priv->default_state); if (ret) { dev_err(dev, "Failed to apply default pinctrl state on resume: %d\n", ret); return ret; } return 0; } static const struct dev_pm_ops my_driver_pm_ops = { .suspend = my_driver_suspend, .resume = my_driver_resume, // 可能还有 .suspend_noirq, .resume_noirq 等 }; ``` ## 7. 总结 * `pinctrl` 子系统Linux 内核中**统一管理 SoC 引脚复用和配置**的核心框架。 * 它通过**设备树**描述硬件引脚资源和设备所需的引脚状态(`default`, `sleep` 等),实现了**配置与驱动代码的分离**。 * 核心概念包括 **Pin Controller**、**Client Device**、**Pin State**、**Pin Group**。 * Client Device 驱动通过 `pinctrl_get()` / `devm_pinctrl_get()` 获取句柄,通过 `pinctrl_lookup_state()` 查找状态,通过 `pinctrl_select_state()` 应用状态。 * 状态切换(如休眠唤醒)是 `pinctrl` 的关键应用场景之一。 * `pinctrl` 负责**决定引脚功能(复用)和基本配置**,**GPIO 子系统**负责**操作配置为 GPIO 功能的引脚**,两者分工明确,协同工作[^4][^5]。 理解并正确使用 `pinctrl` 子系统是编写可移植、易维护的现代 Linux 设备驱动(尤其是涉及外设接口的驱动)的基础。
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值