RK3399—pinctrl和gpio子系统

最新推荐文章于 2025-03-26 16:41:14 发布

Acuity.

最新推荐文章于 2025-03-26 16:41:14 发布

阅读量9.8k

点赞数 12

分类专栏： RK3399 文章标签： pinctrl gpio子系统

本文链接：https://blog.csdn.net/qq_20553613/article/details/103931924

版权

RK3399 专栏收录该内容

13 篇文章 ¥9.90 ¥99.00

订阅专栏

超级会员免费看

本文介绍了RK3399的pinctrl和gpio子系统，阐述了它们在简化GPIO配置和管理复用功能方面的作用。通过设备树配置，pinctrl子系统管理PIN复用和电气特性，而gpio子系统负责GPIO的申请、释放、读写及中断。文章详细讲解了两者在驱动开发中的应用，包括设备树修改、驱动源码编写和运行示例。

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

1. 前言

记得以前在学习51单片机时，要控制一个GPIO输出高、低电平，就得根据对应IO寄存器每一bit的作用和含义进行配置，时钟、速率、方向、上下拉等等。51单片机是一款8位MCU，在配置寄存器相对容易，如果是32位甚至64位的处理器呢，会大大增加配置的复杂度。后来ST推出了STM32，并迅速收获一大批开发者和市场占有份额，至今依然是岿然不动。原因之一就是ST推出了一个“BSP标准库”（当然后来有推出了HAL、LL库等），BSP库屏蔽了底层寄存，大大释放了开发者的工作量，让开发者眼前一亮——原来MCU也可以这样开发。确实，BSP层应该由原厂实现，驱动工程师只做驱动，应用工程师专注做应用。

linux下的pintcrl和gpio子系统就类似于ST的“BSP库”，但是linux的pinctrl和gpio系统实现的功能和过程要远远比STM32的“BSP库”复杂。linux下引入pincrtl和gpio子系统，大大释放了驱动工程师的工作量，特别是引入“设备树”之后，使用一个外设时，对于pin引脚的初始化和管理，只需通过设备树描述即可，然后由pin子系统管理；对于gpio则由gpio子系统管理。

因此，与CPU引脚“关联”的设备驱动，最终都会调用pincrtl和gpio子系统。二者是设备驱