Linux内核之pinctrl子系统

简介: 众所周知,ARM SoC提供了十分丰富的硬件接口,而接口物理上的表现就是一个个的pin(或者叫做pad, finger等)。为了实现丰富的硬件功能,SoC的pin需要实现复用功能,即单独的pin需要提供不同功能,例如,pin0既可以作为GPIO,可以也用于i2c的SCL,通过pin相关的复用寄存器来切换不同的功能。除此之外,软件还可以通过寄存器配置pin相关的电气特性,例如,上拉/下拉、驱动能力、开漏等。

1. 前言


众所周知,ARM SoC提供了十分丰富的硬件接口,而接口物理上的表现就是一个个的pin(或者叫做pad, finger等)。为了实现丰富的硬件功能,SoC的pin需要实现复用功能,即单独的pin需要提供不同功能,例如,pin0既可以作为GPIO,可以也用于i2c的SCL,通过pin相关的复用寄存器来切换不同的功能。除此之外,软件还可以通过寄存器配置pin相关的电气特性,例如,上拉/下拉、驱动能力、开漏等。


Linux kernel 3.0之前的内核,对于pin的功能配置都是通过目标板的配置文件(arch/arm/mach-*)来初始化的,这种配置方式比较繁琐,十分容易出现问题(例如,pin的功能配置冲突)。所以,Linux kernel 3.0之后,实现了DT的板级配置信息管理机制,大大改善了对于pin的配置方式,随之一起实现的就是pinctrl子系统。


pinctrl子系统主要负责以下功能:


  1. 枚举、命名通过板级DTS配置的所有pin;


  1. 对于pin实现复用功能;


  1. 配置pin的电器特性,例如,上拉/下拉、驱动能力、开漏等。;


可见,pinctrl子系统地位相当于kernel全局的pin管理中心,kernel中所有需要pin资源的驱动、子系统都需要通过pinctrl子系统来申请、配置、释放。可将对于pin的操作来说,pinctrl子系统十分重要的。


2. 软件框架


对于不同的SoC,其对于pin管理方式可能不同,所以软件上对于pin的配置方式可能存在较大的差异。对此,pinctrl子系统"求同存异",将pin的管理方式进行了抽象,形成pinctrl-core抽象层,将具体SoC的pin controler隔离出去,形成pinctrl-driver抽象层,pinctrl-core和pinctrl-driver通过抽象接口进行通信。对于pinctrl-core的back-end,即各个需要用到pin的驱动,pinctrl子系统将其抽象为pinctrl-client。


通过上面的软件抽象,pinctrl子系统可以很好的应对不同的SoC pin controler的管理需求,同样可以很好的为不同需要的驱动程序提供pin操作服务。下图简单示意一下pinctrl子系统的软件架构。


网络异常,图片无法展示
|


通过观察pinctrl子系统的软件框架图,可以发现一个问题,那就是GPIO子系统与pinctrl子系统的关系。理论上,GPIO子系统作为pinctrl子系统的使用者,其地位应该和普通的设备驱动没有差别,但是由于以下原因导致GPIO子系统与pinctrl子系统的功能出现了耦合:


  1. 早在kernel 3.0之前,GPIO子系统就已经出现了,其功能也比较明确,就是管理pin的GPIO功能;


  1. pinctrl子系统以及DT机制出现之后,由于GPIO管理的特殊性,并没有将GPIO子系统合并到pinctrl子系统中,而是在pinctrl子系统为GPIO子系统保留了特殊的访问通道,已达到GPIO子系统访问pin的需求。


2.1. pinctrl-core


pinctrl-core抽象层主要的功能就是提供三种服务:


  1. 为SoC pin controler drvier提供底层通信接口的能力;


  1. 为Driver提供访问pin的能力,即driver配置pin复用能、配置引脚的电气特性;


  1. 为GPIO子系统提供GPIO访问的能力;


对于第一种服务来说,其实,对于pinctrl-core抽象层,底层的pin存在方式以及如何对其配置,其完全不会去关心。那么,pinctrl-core如何完成对于pinctrl-driver的控制呢?其实很简单,pinctrl-core与pinctrl-driver是通过pin controller descriptor进行通信的。该结构定义如下:


/**
 * struct pinctrl_desc - pin controller descriptor, register this to pin
 * control subsystem
 * @name: name for the pin controller
 * @pins: an array of pin descriptors describing all the pins handled by
 *  this pin controller
 * @npins: number of descriptors in the array, usually just ARRAY_SIZE()
 *  of the pins field above
 * @pctlops: pin control operation vtable, to support global concepts like
 *  grouping of pins, this is optional.
 * @pmxops: pinmux operations vtable, if you support pinmuxing in your driver
 * @confops: pin config operations vtable, if you support pin configuration in
 *  your driver
 * @owner: module providing the pin controller, used for refcounting
 */
struct pinctrl_desc {
  /*pinctrl-driver属性*/
    const char *name;
    const struct pinctrl_pin_desc *pins;                                                                                                                                                                            
    unsigned int npins;
  /*pinctrl-drive抽象接口*/
    const struct pinctrl_ops *pctlops;
    const struct pinmux_ops  *pmxops;
    const struct pinconf_ops *confops;
    struct module *owner;
};


pinctrl_desc其实对于pinctrl-driver的抽象,其包括了pinctrl-driver所有属性以及其具有的所有能力;这就是典型的面向对象编程的思想,pinctrl-core将pinctrl-driver抽象为pinctrl_desc对象,具体到SoC pinctrl-driver便是该对象一个实例。pinctrl-core通过该实例完成对于系统中所有pin的操作。但是,具体到pinctrl-driver如何完成pin的相关操作,pinctrl-core其实是不关心的。这就将pinctrl-driver的管理的复杂性进行了隔离,与之通信的唯一方式就是预先定义好的抽象接口。这样,不管pinctrl-driver如何变化,只要是按照协议,实例化pinctrl_desc,那么pinctrl-core就始终可以管理系统所有的pin。

其实,对于软件设计最为本质的目的就是消除复杂性,面向对象编程其实是一种很好的解决软件复杂性的思想。不管是何种软件,服务器程序也好、Web前端程序也好亦或是嵌入式驱动程序也好,其面对的问题其实是一样的,那么最终解决问题指导思想也是相似的。最终目的,就是编写出复杂度低,易于维护的软件。


2.2. pinctrl-driver


pinctrl-driver主要为pinctrl-core提供pin的操作能力。对于具体的pinctrl-controler每个SoC的管理方式可能不同,对应到pinctrl-driver上,其实现方式可能会略有不同,但是,所有pinctrl-driver都是为了同一达到同一个目标,那就是把系统所有的pin信息以及对于pin的控制接口实例化成pinctrl_desc,并将pinctrl_desc注册到pinctrl-core中。

pinctrl-driver对于系统pin的管理是通过function和group实现的。下面解释一下function和group的概念,解释之前需要提供一下pinctrl的DTS描述,对于DTS不是很熟悉的可以参考DTS相关的文章:


/ {  
pinctrl: pinctrl@ff770000 {
    compatible = "rockchip,rk3288-pinctrl";
    reg = <0xff770000 0x140>,
          <0xff770140 0x80>,
          <0xff7701c0 0x80>;
    reg-names = "base", "pull", "drv";
    #address-cells = <1>; 
    #size-cells = <1>; 
    ranges;
    gpio0: gpio0@ff750000 {
        compatible = "rockchip,rk3288-gpio-bank0";
        reg =   <0xff750000 0x100>,
            <0xff730084 0x0c>,
                <0xff730064 0x0c>,
            <0xff730070 0x0c>;
        reg-names = "base", "mux_bank0", "pull_bank0", "drv_bank0";
        interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
        clocks = <&clk_gates17 4>;
        gpio-controller;
        #gpio-cells = <2>; 
        interrupt-controller;
        #interrupt-cells = <2>; 
    };
  ......
  gpio0_i2c0 {
        i2c0_sda:i2c0-sda {
            rockchip,pins = <I2C0PMU_SDA>;
            rockchip,pull = <VALUE_PULL_DISABLE>;
            rockchip,drive = <VALUE_DRV_DEFAULT>;
            //rockchip,tristate = <VALUE_TRI_DEFAULT>;
        };
        i2c0_scl:i2c0-scl {
            rockchip,pins = <I2C0PMU_SCL>;
            rockchip,pull = <VALUE_PULL_DISABLE>;
            rockchip,drive = <VALUE_DRV_DEFAULT>;
            //rockchip,tristate = <VALUE_TRI_DEFAULT>;
        };
        i2c0_gpio: i2c0-gpio {
            rockchip,pins = <FUNC_TO_GPIO(I2C0PMU_SDA)>, <FUNC_TO_GPIO(I2C0PMU_SCL)>;
            rockchip,drive = <VALUE_DRV_DEFAULT>;
        };
    };


上面的dts来自于Rockchip 3288的pinctrl配置dts,下面通过该配置,介绍一下function和group的概念:


  • group:所谓的group,如上dts中的i2c0_sda:i2c0_gpio,表示一组pins,这组pins统一表示了一种功能,比如,i2c需要两个pins表示,而spi需要四个引脚表示,而对于UART至少需要两个引脚表示。在定义pins的同时,还会提供对于每个pin的电气特性的配置,如,上下拉电阻、驱动能力等。


  • function:所谓的function,如上dts中的gpio0_i2c0,表示一当前这个pin所代表的的功能。每个function可以被一若干个group所引用,但是,对于每个独立的系统(BPS),只有一个group所引用的pin的function有效,否则会引起pin的function冲突。比如,一个pin既可以作为普通的gpio,也可以作为i2c的sda,那么,一个BPS,这个pin只能代表一个function,即,要么作为普通的gpio,作为i2c的sda。


pinctrl-driver会在驱动的xxxx_probe函数中,将DTS中所定义关于function和group的配置,转换为pinctrl_desc中的数据属性,同时将pinctrl_desc中的对于pin相关操作的回调函数pctlops、pmxops、confops进行初始化,然后将pinctr_desc注册到pinctrl-core中。之后,pinctrl-driver所要做的工作就是静静的等待pinctrl-core的召唤。


至于,pinctrl-driver如何转化pin信息以及pinctrl_desc的抽象接口的具体实现,每个SoC的具体实现各不相同,有兴趣的话可以参考具体的内核代码。


2.3. pinctrl-client


具体到使用系统pin资源的设备驱动程序,pinctrl-core主要提供为其提供两种能力:隶属于本设备的所有pin的function的配置能力和GPIO子系统对于GPIO的配置能力;

2.2节中描述了pinctrl相关的DTS关于function和group的配置,对于具体的设备如何使用这些配置信息呢?还是以一个具体设备的DTS配置为例说明问题,DTS配置如下:


i2c0: i2c@ff650000{                                                                                                                                                                                     
        compatible = "rockchip,rk30-i2c";
        reg = <0xff650000 0x1000>;
        interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
        #address-cells = <1>;
        #size-cells = <0>;
        pinctrl-names = "default", "gpio";
        pinctrl-0 = <&i2c0_sda &i2c0_scl>;
        pinctrl-1 = <&i2c0_gpio>;
        gpios = <&gpio0 GPIO_B7 GPIO_ACTIVE_LOW>,  <&gpio0 GPIO_C0 GPIO_ACTIVE_LOW>;
        clocks = <&clk_gates10 2>;
        rockchip,check-idle = <1>;
        status = "disabled";
    };


上面的是关于i2c0控制器的设备配置信息,我们关心的是下面的配置信息:


pinctrl-names = "default", "gpio";
        pinctrl-0 = <&i2c0_sda &i2c0_scl>;
        pinctrl-1 = <&i2c0_gpio>;


pinctrl-names表示i2c0控制器所处的两种状态,称为pin state, 即:default、gpio;其中,pinctrl-0对应于defaut状态下其关心的function和group,类似的,pinctrl-1对应于gpio状态下其关心的function和group。


pinctrl-names所列出的各个状态与系统电源管理模块的联系比较紧密,由于电源管理的需要,系统可能处于不同的工作状态,相应的设备驱动提供pins不同的工作状态,其目的为了降低系统整体功耗,达到省电的需求,这种需求在消费电子产品中尤为重要。


一般情况下,各个core-driver,例如i2c-core、spi-core会在调用设备驱动程序的probe初始化函数之前,将设备的工作状态设定为default状态。pinctrl-core的consumer.h文件(include/linux/pinctrl/consumer.h)文件提供了配置pin state的接口函数,其原型如下:


extern struct pinctrl * __must_check pinctrl_get(struct device *dev);
extern void pinctrl_put(struct pinctrl *p);
extern struct pinctrl_state * __must_check pinctrl_lookup_state(
                            struct pinctrl *p,
                            const char *name);
extern int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *s);
extern struct pinctrl * __must_check devm_pinctrl_get(struct device *dev);
extern void devm_pinctrl_put(struct pinctrl *p);
extern int pinctrl_pm_select_default_state(struct device *dev);
extern int pinctrl_pm_select_sleep_state(struct device *dev);
extern int pinctrl_pm_select_idle_state(struct device *dev);


对于普通的设备驱动程序来说,一般不会使用到上述的接口,在涉及到电源管理或者子系统驱动程序(i2c-core、spi-core)可能用到上述接口。后续文档(GPIO 子系统、i2c-core-drvier、spi-core-drive)会详细分析。


相关文章
|
1月前
|
存储 Linux 数据处理
探索Linux操作系统的内核与文件系统
本文深入探讨了Linux操作系统的核心组件,包括其独特的内核结构和灵活的文件系统。文章首先概述了Linux内核的主要功能和架构,接着详细分析了文件系统的工作原理以及它如何支持数据存储和检索。通过比较不同的文件系统类型,本文旨在为读者提供一个关于如何根据特定需求选择合适文件系统的参考框架。
|
18天前
|
Linux API 调度
技术笔记:Linux内核跟踪和性能分析
技术笔记:Linux内核跟踪和性能分析
|
4天前
|
Linux
查看linux内核版本
在Linux中查看内核版本可使用`uname -r`、`cat /proc/version`、`lsb_release -a`、`cat /etc/*release`、`dmesg | grep Linux`、`hostnamectl`、`kernrelease`(部分系统)、`rpm -q kernel`(RPM系统)或`dpkg -l linux-image-*`(Debian系)。
6 2
|
26天前
|
Linux
查看linux内核版本
在Linux中查看内核版本可使用`uname -r`、`cat /proc/version`、`lsb_release -a`(若安装LSB)、`/etc/*release`或`/etc/*version`文件、`dmesg | grep Linux`、`cat /sys/class/dmi/id/product_name`、`hostnamectl`、`kernrelease`(如果支持)、`rpm -q kernel`(RPM系统)和`dpkg -l linux-image-*`(Debian系统)。
31 4
|
27天前
|
安全 Linux 数据处理
探索Linux的kmod命令:管理内核模块的利器
`kmod`是Linux下管理内核模块的工具,用于加载、卸载和管理模块及其依赖。使用`kmod load`来加载模块,`kmod remove`卸载模块,`kmod list`查看已加载模块,`kmod alias`显示模块别名。注意需有root权限,且要考虑依赖关系和版本兼容性。最佳实践包括备份、查阅文档和使用额外的管理工具。
|
10天前
|
Linux 调度
部署03---Linux操作系统的诞生,Linux操作系统由系统的内核和系统的操作系统所组成
部署03---Linux操作系统的诞生,Linux操作系统由系统的内核和系统的操作系统所组成
|
1月前
|
Linux API 芯片
Linux GPIO 和 Pinctrl 子系统的使用(十四)
Linux GPIO 和 Pinctrl 子系统的使用(十四)
15 1
|
1月前
|
运维 NoSQL Ubuntu
深入理解Linux中的"crash"命令:内核崩溃的调试利器
`crash`是Linux内核崩溃调试工具,用于分析内核崩溃转储文件,提供GDB-like的交互式CLI。通过加载`vmcore`文件和内核映像,管理员可以查看系统状态、调用栈、内存布局等。安装`crash`可使用包管理器,如`apt-get`或`yum/dnf`。尽管有学习曲线且依赖转储文件,但`crash`在系统故障排查中极其重要。
|
28天前
|
Linux
【Linux驱动学习(1)】USB与input子系统,linux统一设备模型,枚举,USB描述符深入剖析
【Linux驱动学习(1)】USB与input子系统,linux统一设备模型,枚举,USB描述符深入剖析
|
1月前
|
Linux 编译器 C语言
编译Linux内核:基础、重要性和交叉编译方法
Linux内核作为操作系统的心脏,负责管理计算机的硬件资源,同时也是运行所有其他程序的基础。理解如何编译Linux内核对于系统管理员、开发者乃至高级用户来说都是一项极其宝贵的技能。本文将介绍编译Linux内核的基本知识、编译的重要性、具体步骤以及交叉编译的概念。
92 0