【嵌入式Linux内核驱动】Pinctrl子系统

原创 已于 2023-07-14 22:15:10 修改 · 751 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#linux #单片机 #嵌入式 #Pinctrl

于 2023-05-29 22:26:38 首次发布

Pinctrl子系统

暴露到应用层

$ cat  /sys/kernel/debug/gpio  //查看gpio 暴露的调试信息
$ cat  /sys/kernel/debug/tegra_pinctrl_reg
$ ls   /sys/kernel/debug/pinctrl/
$ cat  /sys/kernel/debug/pinctrl/pinctrl-handles //查看pinmux map对应的处理函数
GPIO当前配置情况
//注： gpio-79： 是内核gpio子系统里，对管脚的编号（是经过映射转化的）
//     I2S0_SCLK ： 是该管脚在电路图上的标号
gpiochip0: GPIOs 0-255, parent: platform/6000d000.gpio, tegra-gpio:
内核里编号 电路图标号            |当前使用者           输出 高电平
 gpio-0   (                    )
 gpio-1   (                    )
 gpio-2   (                    |pcie_wake           ) in  hi    
 gpio-3   (                    )
 ...
 gpio-6   (                    |system-suspend-gpio ) out hi    
 ...
 gpio-11  (                    )
 gpio-12  (SPI1_MOSI           )
 gpio-13  (SPI1_MISO           )
 gpio-14  (SPI1_SCK            )
 gpio-15  (SPI1_CS0            )
 gpio-16  (SPI0_MOSI           )
 gpio-17  (SPI0_MISO           )
 gpio-18  (SPI0_SCK            )
 gpio-19  (SPI0_CS0            )
 gpio-20  (SPI0_CS1            )
 ...
 gpio-38  (GPIO13              )
 ...
 gpio-50  (UART1_RTS           )
 gpio-51  (UART1_CTS           )
 ...
 gpio-64  (                    |i2c-mux-gpio        ) out hi
 ...
 gpio-76  (I2S0_FS             )
 gpio-77  (I2S0_DIN            )
 gpio-78  (I2S0_DOUT           )
 gpio-79  (I2S0_SCLK           |?                   ) out hi   
 ... 
 gpio-149 (GPIO01              )
 gpio-150 (                    )
 gpio-151 (                    |cam_reset_gpio      ) out lo
 ...
 gpio-168 (GPIO07              )
 ...
 gpio-187 (                    |?                   ) out hi
 gpio-188 (                    )
 gpio-189 (                    |Power               ) in  hi IRQ
 gpio-190 (                    |Forcerecovery       ) in  hi IRQ
 ...
 gpio-194 (GPIO12              )
 ...
 gpio-200 (GPIO11              )
 gpio-201 (                    |cd                  ) in  lo IRQ
 gpio-202 (                    )
 gpio-203 (                    |vdd-3v3-sd          ) out hi
 ...
 gpio-216 (GPIO09              )
 ...
 gpio-239 (                    )
gpiochip1: GPIOs 504-511, parent: platform/max77620-gpio, max77620-gpio, can sleep:
 gpio-505 (                    |spmic-default-output) out hi
 gpio-507 (                    |vdd-3v3-sys         ) out hi
 gpio-510 (                    |enable              ) out lo
 gpio-511 (                    |avdd-io-edp-1v05    ) out lo
管脚复用寄存器的值
Bank: 1 Reg: 0x70003000 Val: 0x00003040 -> sdmmc1_clk_pm0
Bank: 1 Reg: 0x70003004 Val: 0x00003048 -> sdmmc1_cmd_pm1
Bank: 1 Reg: 0x70003008 Val: 0x00003048 -> sdmmc1_dat3_pm2
Bank: 1 Reg: 0x7000300c Val: 0x00003048 -> sdmmc1_dat2_pm3
Bank: 1 Reg: 0x70003010 Val: 0x00003048 -> sdmmc1_dat1_pm4
Bank: 1 Reg: 0x70003014 Val: 0x00003048 -> sdmmc1_dat0_pm5
Bank: 1 Reg: 0x700032b4 Val: 0x00000000 -> sdmmc2_clk
Bank: 1 Reg: 0x700032b8 Val: 0x00000000 -> sdmmc2_clkb
Bank: 1 Reg: 0x700032bc Val: 0x00000000 -> sdmmc2_cmd
Bank: 1 Reg: 0x70003294 Val: 0x00000000 -> sdmmc2_dat0
Bank: 1 Reg: 0x70003298 Val: 0x00000000 -> sdmmc2_dat1
Bank: 1 Reg: 0x7000329c Val: 0x00000000 -> sdmmc2_dat2
Bank: 1 Reg: 0x700032a0 Val: 0x00000000 -> sdmmc2_dat3
Bank: 1 Reg: 0x700032a4 Val: 0x00000000 -> sdmmc2_dat4
Bank: 1 Reg: 0x700032a8 Val: 0x00000000 -> sdmmc2_dat5
Bank: 1 Reg: 0x700032ac Val: 0x00000000 -> sdmmc2_dat6
Bank: 1 Reg: 0x700032b0 Val: 0x00000000 -> sdmmc2_dat7
Bank: 1 Reg: 0x700032c0 Val: 0x00000000 -> sdmmc2_dqs
Bank: 1 Reg: 0x700032c4 Val: 0x00000000 -> sdmmc2_dqsb
Bank: 1 Reg: 0x7000301c Val: 0x00002040 -> sdmmc3_clk_pp0
Bank: 1 Reg: 0x70003020 Val: 0x00002048 -> sdmmc3_cmd_pp1
Bank: 1 Reg: 0x70003024 Val: 0x00002048 -> sdmmc3_dat0_pp5
Bank: 1 Reg: 0x70003028 Val: 0x00002048 -> sdmmc3_dat1_pp4
Bank: 1 Reg: 0x7000302c Val: 0x00002048 -> sdmmc3_dat2_pp3
Bank: 1 Reg: 0x70003030 Val: 0x00002048 -> sdmmc3_dat3_pp2
Bank: 1 Reg: 0x70003038 Val: 0x00000400 -> pex_l0_rst_n_pa0
Bank: 1 Reg: 0x7000303c Val: 0x00000450 -> pex_l0_clkreq_n_pa1
Bank: 1 Reg: 0x70003040 Val: 0x00000440 -> pex_wake_n_pa2
Bank: 1 Reg: 0x70003044 Val: 0x00000400 -> pex_l1_rst_n_pa3
Bank: 1 Reg: 0x70003048 Val: 0x00000440 -> pex_l1_clkreq_n_pa4
Bank: 1 Reg: 0x7000304c Val: 0x00000049 -> sata_led_active_pa5
Bank: 1 Reg: 0x7000304c Val: 0x00000049 -> pa5
Bank: 1 Reg: 0x70003050 Val: 0x0000e015 -> spi1_mosi_pc0
Bank: 1 Reg: 0x70003054 Val: 0x0000e015 -> spi1_miso_pc1
Bank: 1 Reg: 0x70003058 Val: 0x0000e015 -> spi1_sck_pc2
Bank: 1 Reg: 0x7000305c Val: 0x0000e015 -> spi1_cs0_pc3
Bank: 1 Reg: 0x70003060 Val: 0x0000e015 -> spi1_cs1_pc4
Bank: 1 Reg: 0x70003064 Val: 0x00006016 -> spi2_mosi_pb4
Bank: 1 Reg: 0x70003068 Val: 0x00006016 -> spi2_miso_pb5
Bank: 1 Reg: 0x7000306c Val: 0x00006016 -> spi2_sck_pb6
Bank: 1 Reg: 0x70003070 Val: 0x00006016 -> spi2_cs0_pb7
Bank: 1 Reg: 0x70003074 Val: 0x00006015 -> spi2_cs1_pdd0
Bank: 1 Reg: 0x70003078 Val: 0x0000e015 -> spi4_mosi_pc7
Bank: 1 Reg: 0x7000307c Val: 0x0000e015 -> spi4_miso_pd0
Bank: 1 Reg: 0x70003080 Val: 0x0000e015 -> spi4_sck_pc5
Bank: 1 Reg: 0x70003084 Val: 0x0000e015 -> spi4_cs0_pc6
Bank: 1 Reg: 0x70003088 Val: 0x00002040 -> qspi_sck_pee0
Bank: 1 Reg: 0x7000308c Val: 0x00002000 -> qspi_cs_n_pee1
Bank: 1 Reg: 0x70003090 Val: 0x00002040 -> qspi_io0_pee2
Bank: 1 Reg: 0x70003094 Val: 0x00002040 -> qspi_io1_pee3
Bank: 1 Reg: 0x70003098 Val: 0x00002040 -> qspi_io2_pee4
Bank: 1 Reg: 0x7000309c Val: 0x00002040 -> qspi_io3_pee5
Bank: 1 Reg: 0x700030a4 Val: 0x00000041 -> dmic1_clk_pe0
Bank: 1 Reg: 0x700030a8 Val: 0x00000041 -> dmic1_dat_pe1
Bank: 1 Reg: 0x700030ac Val: 0x00000041 -> dmic2_clk_pe2
Bank: 1 Reg: 0x700030b0 Val: 0x00000041 -> dmic2_dat_pe3
Bank: 1 Reg: 0x700030b4 Val: 0x00000016 -> dmic3_clk_pe4
Bank: 1 Reg: 0x700030b8 Val: 0x00000016 -> dmic3_dat_pe5
Bank: 1 Reg: 0x700030bc Val: 0x00000440 -> gen1_i2c_scl_pj1
Bank: 1 Reg: 0x700030c0 Val: 0x00000440 -> gen1_i2c_sda_pj0
Bank: 1 Reg: 0x700030c4 Val: 0x00000440 -> gen2_i2c_scl_pj2
Bank: 1 Reg: 0x700030c8 Val: 0x00000440 -> gen2_i2c_sda_pj3
Bank: 1 Reg: 0x700030cc Val: 0x00000040 -> gen3_i2c_scl_pf0
Bank: 1 Reg: 0x700030d0 Val: 0x00000040 -> gen3_i2c_sda_pf1
Bank: 1 Reg: 0x700030d4 Val: 0x00000441 -> cam_i2c_scl_ps2
Bank: 1 Reg: 0x700030d8 Val: 0x00000441 -> cam_i2c_sda_ps3
Bank: 1 Reg: 0x700030dc Val: 0x00000040 -> pwr_i2c_scl_py3
Bank: 1 Reg: 0x700030e0 Val: 0x00000040 -> pwr_i2c_sda_py4
Bank: 1 Reg: 0x700030e4 Val: 0x00000000 -> uart1_tx_pu0
Bank: 1 Reg: 0x700030e8 Val: 0x00000040 -> uart1_rx_pu1
Bank: 1 Reg: 0x700030ec Val: 0x00000015 -> uart1_rts_pu2
Bank: 1 Reg: 0x700030f0 Val: 0x00000015 -> uart1_cts_pu3
Bank: 1 Reg: 0x700030f4 Val: 0x00000000 -> uart2_tx_pg0
Bank: 1 Reg: 0x700030f8 Val: 0x00000044 -> uart2_rx_pg1
Bank: 1 Reg: 0x700030fc Val: 0x00000016 -> uart2_rts_pg2
Bank: 1 Reg: 0x70003100 Val: 0x00000016 -> uart2_cts_pg3
Bank: 1 Reg: 0x70003104 Val: 0x00000000 -> uart3_tx_pd1
Bank: 1 Reg: 0x70003108 Val: 0x00000040 -> uart3_rx_pd2
Bank: 1 Reg: 0x7000310c Val: 0x00000008 -> uart3_rts_pd3
Bank: 1 Reg: 0x70003110 Val: 0x00000048 -> uart3_cts_pd4
Bank: 1 Reg: 0x70003114 Val: 0x00000000 -> uart4_tx_pi4
Bank: 1 Reg: 0x70003118 Val: 0x00000040 -> uart4_r
最低0.47元/天 解锁文章
嵌入式linux中pinctrl子系统驱动用法分析
嵌入式技术开发
06-15 434
大家好，对于大多数的32位SOC而言，引脚的设置基本都是这两方面：1、设置PIN的复用功能。2、如果PIN复用为GPIO功能，设置GPIO相关属性。大多数SOC的pin都是支持复用的，比如RK3568的GPIO3_4即可作为普通的GPIO使用，也可以作为PWM1_M0引脚、GPU_AVS引脚等， 此外还需要配置pin的电气特性，比如上/下拉、驱动能力等等。传统的配置 pin的方式就是直接操作相应的寄存器，但是这种配置方式比较繁琐、而且容易出问题(比如pin功能冲突)。1、获取设备树中pin信息。
Linux的pinctrl子系统
qq_28576837的博客
10-13 1257
上一章我们编写了基于设备树的 LED 驱动，但是驱动的本质还是没变，都是配置 LED 灯所使用的 GPIO 寄存器，驱动开发方式中硬件初始化这一部分和裸机基本没啥区别。Linux 是一个庞大而完善的系统，尤其是驱动框架，像 GPIO 这种最基本的驱动不可能采用“原始”的裸机驱动开发方式，否则就相当于你买了一辆车，结果每天推着车去上班。Linux 内核提供了 pinctrl 和 gpio 子系统用于GPIO 驱动，本章我们就来学习一下如何借助 pinctrl 和 gpio 子系统来简化 GPIO 驱动开发。
pinctrl 子系统
weixin_34799243的博客
05-03 624
文章目录写在前面引入pinctrl的意义pinctrl的主要概念pin controller数据结构驱动代码执行流程client device：数据结构client节点的pinctrl构造过程设备树反汇编 写在前面 这一篇是学习韦东山老师视频随手做的笔记。 引入pinctrl的意义 Pinctrl：Pin Controller，顾名思义，就是用来控制引脚的： ● 引脚枚举与命名(Enumerating and naming) ● 引脚复用(Multiplexing)：比如用作GPIO、I2C或其他功能 ●
Linux内核之pinctrl子系统
飞翔de刺猬
09-16 4641
1. 前言 2. 软件框架 2.1. pinctrl-core 2.2. pinctrl-driver 2.3. pinctrl-client 1. 前言 众所周知，ARM SoC提供了十分丰富的硬件接口，而接口物理上的表现就是一个个的pin(或者叫做pad, finger等)。为了实现丰富的硬件功能，SoC的pin需要实现复用功能，即单独的pin需要提供不同功能，例如，pi...
linux 驱动 - pinctrl子系统
sty01z的博客
07-23 1266
分析总结 pinctrl 子系统框架结构，平台 mtk6771 内核版本 kernel-4.4 , 本文所有的分析均基于此版本。
【嵌入式Linux】嵌入式Linux驱动开发基础知识之Pinctrl子系统和GPIO子系统的使用
永远年轻 永远热泪盈眶
04-21 1255
【嵌入式Linux】嵌入式Linux驱动开发基础知识之Pinctrl子系统和GPIO子系统的使用 上一章中介绍了设备树模型，可以帮助开发者省去在内核中指定资源的步骤，本章介绍Pinctrl子系统和GPIO子系统，使用这两个子系统可帮助让驱动开发者不再需要操作繁琐的GPIO寄存器
【pinctrl子系统】
Sugar_wolf的博客
06-16 1412
【pinctrl子系统】
pinctrl子系统
weixin_A13253323604
03-21 479
1、概述 pinctrl子系统和GPIO子系统是linux驱动分离与分层的产物。 对于大多数的 32 位 SOC 而言，引脚的设置基本都是设置某个 PIN 的复用功能、速度、上下拉等，然后再设置 PIN 所对应的 GPIO这两方面，因此 Linux 内核针对 PIN 的配置推出了 pinctrl 子系统，对于 GPIO的配置推出了 gpio 子系统。 pinctrl子系统分融主要工作内容如下： 1）、获取设备树树中pin的信息。 2）、根据获取到的pin信息，来设置pin的复用。 3）、根据获取到的pin信
Pinctrl子系统
m0_57705123的博客
09-28 692
Pinctrl子系统 1. Pinctrl引入 参考资料： Linux 5.x内核文档 Documentation\devicetree\bindings\pinctrl\pinctrl-bindings.txt Linux 4.x内核文档 Documentation\pinctrl.txt Documentation\devicetree\bindings\pinctrl\pinctrl-bindings.txt 1.1 Pinctrl作用 无论是哪种芯片，都有类似下图的结构： 想要pi
【Linux】Pinctrl子系统
weixin_47596351的博客
12-19 1615
许多SoC内部都包含pin控制器，通过pin控制器的寄存器，我们可以配置一个或者一组引脚的功能和特性。
Linux pinctrl子系统
m0_49328056的博客
03-13 2386
一、pinctrl子系统介绍 在许多soc内部都包含有pin控制器，通过pin控制器的寄存器，我们可以配置一个或者一组引脚的功能和特性。在软件方面，为了统一各soc厂商的pin脚管理，Linux内核提供了pinctrl子系统。pinctrl子系统提供的功能有如下三点：（1）管理系统中所有的可以控制的pin，在系统初始化的时候，枚举所有可以控制的pin，并标识这些pin。（2）管理这些pin的复用（Multiplexing）。对于SOC而言，其引脚除了配置成普通的GPIO之外，若干个引脚还可以组成一个pin
Linux驱动pinctrl子系统
最新发布
07-23
<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 设备驱动（尤其是涉及外设接口的驱动）的基础。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值