Linux Pinctrl

在求量的心态下，我同时兼职了pinctrl的工作，从开始的头疼到后来的游刃有余，直到今日...

Pinctrl是对SoC的所有IO pin的管理，包括IO的复用（MUX）、IO的配置（Config）以及IO的通用功能（GPIO）。

SoC的ballmap可以看到，除了电源、地、特定功能脚之外，还有很多的IO pin，他们分散在各个电源域，并且在芯片设计阶段已经被规划好了各种复用场景，而pinctrl驱动做的就是让各个模块驱动很简洁地完成复用配置，完成IO配置（如驱动强度、上下拉、斯密特触发器、边沿速率）。

很多家芯片厂商的pinctrl驱动，是在驱动中枚举所有的复用组合，留给dts的是一些固定的function/group name，这样好处是一劳永逸，缺点是驱动较大，可能做手机的不在乎这个。

我接手的时候，我们的pinctrl驱动，是在dts中定义我们开发板(evb)要使用的复用配置，这个在前些年没有问题，是那时候主要做平板，客户都是直接拿着evb去复制，偶尔个别的客户，再由驱动人员对点支持修改。

到了AIot，问题就来了，因为AIot客户几乎是必改IO设计，大家的外设不同，需要的IO不同，对IO的配置需求不同，而所有的客户，包括公司的产品部都无法完成pinctrl新增和修改。

1. 统一/剥离

当然我认为都不是问题，我接收的第一个项目的时候，我就决定一劳永逸，但是因为历史负担，被要求必须保留对外习惯，及给客户的dts规则是不变的。折衷一下，我把所有的复用枚举到dts中，并把pinctrl独立出一个dtsi文件（在现在google pixel中也看到，说明英雄所见略同啊），再进一步，不同芯片的驱动强度定义五花八门，TRM写的 2 4 8 12 mA，实际根本只是个符号，换了个芯片，TRM写的 3 5 7 9 11 mA，同样也不是实际参数。我统一了以下，把他们都取了个名字，level0 level1 level2 level3，统一之后，dts中的pcfg节点我就再次抽离出来，形成独立的config.dtsi文件，所有芯片共用。

2. DTC

AIot就是要求多，芯片太多引脚，而且复用杂多，把所有的枚举起来，情况非常多，问题有

  -- 容易眼花，写错，不容易排查（基本是必错）

  -- 代码大，虽然比在驱动中枚举小很多，但是dtb也不能太大，否则fdt的有一些lookup会很耗时

对于问题一，我通过python开发的工具，从芯片原始数据中，生成出枚举后的dtsi文件，保证只要IC不错，我就不会错。

对于问题二，通过DTC编译器，使用omit-if-no-use标记，如果枚举出来的没有被当下的设备引用，即无效节点，在编译阶段，会删除这个复用节点。

现在问题已经解决一大半了，只要驱动做好就可以。

3. 驱动出错

原先IC通过大量引线，把不同寄存器有序排放，pinctrl驱动看似简单；但是我的优点是让别人简单，我告诉他们不用纠结在排序上，大量的引线已经出了好多次问题，乐坏了好多人，从此只有一个规则就是无序。驱动新增一个问题，即怎么验证驱动正确性。

说真的我思考这个验证驱动正确性的问题，是早先在对驱动拆分并upstream的时候，被问题如何审核你的代码，改动太大，无法审核，无法保证正确性。

我的工作目标，居然是让自己不用再从事这个工作，这也是矛盾，我的这些想法放在其他模块也是通用的。我前几天收到两个反馈，真正的看到了这个不正确性，促使我决定再打一针鸡血，把驱动自我验证做出来，想法都有了也还算简单，可天有不测风云，搁置搁置...而且想法已经出去了，有点后悔说早了。

4. 为什么我说想法是通用的？

从事嵌入式开发的第12年，我从摸着入行，到轻松完成，到后来认为都不好。

Linux的pinctrl驱动上百K，我在RTOS上的第一版本pinctrl也有几百K，但是我觉得不好，通过日夜亢奋的修改，我重新做了个V2版本，才7K，而且通用，也就是以后再也不用做驱动了。

可人家说V1也是你做的，所以V2是自己打自己，没什么。话不投机三句多。

记得4-5年前那会儿，还没有zebu，我作为PM，告诉一个同事说，你的驱动跑起来一对空指针问题，他问说你怎么知道，芯片都还没回来呢。我就问他，为什么要芯片回来？想清楚

然后我们深入交流，并手把手，随便一个能跑的老芯片设备，就可以验证驱动，就是CRU模块，只要驱动跑完，clocktree对的，各个模块的频率如同dts定义预期，就算驱动准备好了。