前言
随着内核的发展，linux驱动框架在不断的变化。很早很早以前，出现了gpio子系统，后来又出现了pinctrl子系统。在网上很难看到一篇讲解这类子系统的文章。就拿gpio操作来说吧，很多时候都是简单的调用gpio子系统提供的api，然后根据sdk说明文档写明的gpio号传参数，至于里面的工作过程对于驱动工程师而言就像个黑盒子。当我们自己设计的板子和demo板有很大变动时，问题就出现了。首先遇到的是怎么配置pin(是基于设备树还是不基于设备树，基于设备树的话，怎么修改设备树关于pinctrl部分的内容，里面各个字段什么意思，怎么改)，然后是在哪里配置pin（内核部分有哪些需要相应修改，还是不需要一点修改呢），接着就是怎么调试等等。我想只有清楚了尽量多的gpio子系统和pinctrl子系统细节，才会更快更好的完成这些工作。有些平台的实现没有使用内核提供的pinctrl子系统，而是继续采用在内核提供pinctrl子系统前自己实现的那套机制来pinmux操作，如omap，有些平台则基于pinctrl子系统来实现pinmux、pinconf的控制。本文以gpio子系统为入口慢慢深入，最后分析pinctrl子系统。
如果有错误的地方，欢迎大家直接指出
gpio子系统
gpio子系统帮助我们管理整个系统gpio的使用情况，同时通过sys文件系统导出了调试信息和应用层控制接口。它内部实现主要提供了两类接口，一类给bsp工程师，用于注册gpio chip（也就是所谓的gpio控制器驱动），另一部分给驱动工程师使用，为驱动工程师屏蔽了不同gpio chip之间的区别，驱动工程师调用的api的最终操作流程会导向gpio对应的gpio chip的控制代码，也就是bsp的代码。
gpio子系统核心实现分析
gpio子系统的内容在drivers/gpio文件夹下，主要文件有：
devres.c
gpiolib.c
gpiolib-of.c
gpiolib-acpi.c
gpio-xxx.c
devres.c是针对gpio api增加的devres机制的支持，devres机制讲解请参考另一篇博文，gpiolib.c是gpio子系统的核心实现，gpiolib-of.c是对设备树的支持，gpiolib-acpi.c和acpi相关，不分析（acpi还未深入了解_），最后情景分析的时候，会找一个平台的gpio-xxx.c来分析。
从驱动工程师使用的api开始分析吧！也分两代，legacy的api主要会用到的接口有（现在推荐采用新的，基于描述符的api）：gpio_request、gpio_freegpio_direction_input、gpio_direction_outputgpio_to_irqgpio_export
一般的流程：
-
//请求一个/一组gpio
-
gpio_request/devm_gpio_request、gpio_request_one/devm_gpio_request_one、gpio_request_array ---------<
1>
-
...
-
//设置gpio方向为输入/输出
-
gpio_direction_input或者gpio_direction_output ---------<
2>
-
...
-
//将该gpio通过sys文件系统导出，应用层可以通过文件操作gpio
-
gpio_export ---------<
3>
-
...
-
//如果gpio为输入，获取gpio值，如果gpio为输出，可以设置gpio高低电平
-
gpio_get_value、gpio_set_value ---------<
4>
-
...
-
//将gpio转为对应的irq，然后注册该irq的中断handler
-
request_irq(
gpio_to_irq(gpio_num)...) ---------<
5>
-
...
-
//释放请求的一个或者一组gpio
-
gpio_free/devm_gpio_free、gpio_free_array ---------<
6>
-
...
下面一个个来分析吧！
<1> 以gpio_request为例，gpio_request_one、gpio_request_array是它的扩展，devm_为前缀的是gpio devres机制的实现。int gpio_request(unsigned gpio, const char *label)
参数为gpio号和为该gpio指定的表签名，具体gpio号是多少，可以通过sdk开发包说明文档查看，或者查看设备树文件，再或者基于bank数量推算（当然，这样可能不准），实在没办法的话，瞄一眼gpio chip驱动的代码吧！gpio_request主要做了以下动作：
- 检查是否已经被申请，没有的话，标记为已申请
- 填充label到该pin数据结构，用于debug
- 如果chip driver提供了request回调，调用它
- 如果chip driver提供了get_direction回调，调用它,通过它更新pin数据结构，标明gpio方向
gpio_request_one多一个flags参数，通过该参数，可以指定GPIOF_OPEN_DRAIN、GPIOF_OPEN_SOURCE、GPIOF_DIR_IN、GPIOF_EXPORT等标志，如果指定了GPIOF_DIR_IN，那么后面就不需要自己再额外调用gpio_direction_input或者gpio_direction_output了，如果指定了GPIOF_EXPORT，后面就不需要自己调用gpio_export了。
gpio_request_array是对gpio_request_one的封装，用于处理同时申请多个gpio的情形。
<2> gpio_direction_input或者gpio_direction_output用来设置该gpio为输入还是输出，它们主要是回调gpio chip driver提供的direction_input或者direction_output来设置该gpio寄存器为输入、输出。
<3> gpio_export主要用于调试，它会将该gpio的信息通过sys文件系统导出，这样应用层可以直接查看状态、设置状态等。
<4> gpio_get_value或者gpio_set_value和input、output类似，如果为输入，获取该gpio的值，如果为输出，设置该gpio的值，内部也是调用gpio chip driver提供的get、set。
<5> gpio_to_irq用于获取该gpio对应的中断号，这个需要设备树里的该gpio节点描述使用哪个中断号（并不是所有的gpio都可以触发中断的）。它里面的实现就是回调gpio chip driver提供的to_irq。
<6> gpio_free就不用说了啦，gpio_request的逆操作。
要使用以上接口，需要#include <linux/gpio.h>，且还有一组用于允许睡眠场景的api没有给出，更多相关的说明可以参考Documentation/gpio/gpio-legacy.txt
上面的分析没有深入的代码层，之所以没有深入分析，是因为打算放到后面分析基于描述符api时啦！其实，legacy gpio 大部分api就是基于描述符api来实现的。最新的,基于描述符一般的流程：
-
...
-
//请求第一个/指定某一个gpio desc，该返回值用于后面的操作
-
gpiod_get/devm_gpiod_get、gpiod_get_index/devm_gpiod_get_index ---------<
1>
-
...
-
//设置gpio方向为输入/输出
-
gpiod_direction_input或者gpiod_get_direction ---------<
2>
-
...
-
//将该gpio通过sys文件系统导出，应用层可以通过文件操作gpio
-
gpiod_export ---------<
3>
-
...
-
//如果gpio为输入，获取gpio值，如果gpio为输出，可以设置gpio高低电平
-
gpiod_get_value或者gpiod_set_value ---------<
4>
-
...
-
//将gpio转为对应的irq，然后注册该irq的中断handler
-
request_irq(
gpiod_to_irq(gpio_desc)...) ---------<
5>
-
...
-
//释放请求的一个或者一组gpio
-
gpiod_put/devm_gpiod_put ---------<
6>
-
...
还是下面一个个来分析吧！
<1> gpiod_get内部的处理和gpio_request一样，不过输入参数变为char *con_id，这个需要从设备树文件里查看到，除此之外，我们还可以在设备树文件里添加参数（GPIO_ACTIVE_LOW、GPIO_OPEN_DRAIN、GPIO_OPEN_SOURCE）来触发该接口内部设置gpio，具体的参数格式和具体的gpio chip driver有关，一般可以在/Documentation/devicetree/bindings/gpio里找到对应平台的。举个例子：
-
row-gpios = <&gpio1
25 GPIO_ACTIVE_HIGH
/* Bank1, pin25 */
-
&gpio1
26 GPIO_ACTIVE_HIGH
/* Bank1, pin26 */
-
&gpio1
27 GPIO_ACTIVE_HIGH>;
/* Bank1, pin27 */
struct gpio_desc *__must_check gpiod_get(struct device *dev, const char *con_id)
对应上面的设备树描述，con_id就是row了，获取的也会是第一个设置，即gpio1 25 GPIO_ACTIVE_HIGH，如果想获取第二个设置，我们得通过gpiod_get_index，并将输入参数idx设置为１。
<2> gpiod_direction_input和gpio_direction_input功能一样，实际上gpio_direction_input仅仅简单封装了gpiod_direction_input，不再描述。
<3> gpiod_export 同上
<4> gpiod_get_value 同上
<5> gpiod_to_irq 同上
<6> gpiod_put 同上
要使用以上接口，需要#include <linux/gpio/consumer.h>，且还有一组用于允许睡眠场景的api没有给出，更多相关的说明可以参考Documentation/gpio/consumer.txt
下面简单分析下gpio子系统内部实现：
1> gpio chip driver的初始化
gpio子系统提供了两层接口，一层给上层驱动工程师调用，一层给下层bsp工程师调用。上层使用前，当然先得bsp工程师完成对应的动作。先看一张网上的截图：
bsp工程师通过gpiochip_add将gpio chip添加到gpio子系统中，下面就分析它：
-
int gpiochip_add(struct gpio_chip *chip)
-
{
-
unsigned
long flags;
-
int status =
0;
-
unsigned id;
-
int base = chip->base;
-
-
//如果指定了base，也就是指定了启示gpio号，需要校验下chip的所有gpio是否有效
-
//这里会用到ARCH_NR_GPIOS宏，它可以在配置的时候，通过CONFIG_ARCH_NR_GPIO修改，
-
//否则采用默认值256
-
if ((!
gpio_is_valid(base) || !
gpio_is_valid(base + chip->ngpio -
1))
-
&& base >=
0) {
-
status = -EINVAL;
-
goto fail;
-
}
-
-
spin_lock_irqsave(&gpio_lock, flags);
-
-
//如果没有指定base，那么需要基于该chip的gpio数量在系统支持的gpio范围里找一段区间给该chip
-
if (base <
0) {
-
base =
gpiochip_find_base(chip->ngpio);
-
if (base <
0) {
-
status = base;
-
goto unlock;
-
}
-
chip->base = base;
-
}
-
-
//到这里的时候，说明一切正常，把它加入到全局的gpiochip链表中去吧，注意，加入的时候会基于base排序
-
//这也保证了gpiochip_find_base的实现
-
status =
gpiochip_add_to_list(chip);
-
-
//如果加入成功，最后一步就是初始化该chip对应的那些gpio了
-
if (status ==
0) {
-
chip->desc = &gpio_desc[chip->base];
-
-
for (id =
0; id < chip->ngpio; id++) {
-
struct
gpio_desc *desc = &chip->desc[id];
-
//将该chip对应的那些gpio对应的数据结构desc初始化，指向拥有它的chip
-
desc->chip = chip;
-
-
/* REVISIT: most hardware initializes GPIOs as
-
* inputs (often with pullups enabled) so power
-
* usage is minimized. Linux code should set the
-
* gpio direction first thing; but until it does,
-
* and in case chip->get_direction is not set,
-
* we may expose the wrong direction in sysfs.
-
*/
-
//如果chip driver没有指定chip->direction_input，意味着不是输入，那就设置为输出咯
-
desc->flags = !chip->direction_input
-
? (
1 << FLAG_IS_OUT)
-
:
0;
-
}
-
}
-
-
spin_unlock_irqrestore(&gpio_lock, flags);
-
-
#ifdef CONFIG_PINCTRL
-
//这里在配置了pinctrl的时候，会初始化它，后面会用到
-
INIT_LIST_HEAD(&chip->pin_ranges);
-
#endif
-
-
//初始化设备树相关的信息，后面会详细讲一下这部分
-
of_gpiochip_add(chip);
-
//acpi方式的先忽略吧
-
acpi_gpiochip_add(chip);
-
-
if (status)
-
goto fail;
-
-
//将该gpiochip导出到sys，用于调试和应用层直接操作
-
status =
gpiochip_export(chip);
-
if (status)
-
goto fail;
-
-
pr_debug(
"%s: registered GPIOs %d to %d on device: %s\n", __func__,
-
chip->base, chip->base + chip->ngpio -
1,
-
chip->label ? :
"generic");
-
-
return
0;
-
-
unlock:
-
spin_unlock_irqrestore(&gpio_lock, flags);
-
fail:
-
/* failures here can mean systems won't boot... */
-
pr_err(
"%s: GPIOs %d..%d (%s) failed to register\n", __func__,
-
chip->base, chip->base + chip->ngpio -
1,
-
chip->label ? :
"generic");
-
return status;
-
}
还是以zynq平台为例，看看输入参数struct gpio_chip *chip的初始化过程：
-
chip->label =
"zynq_gpio";
-
chip->owner = THIS_MODULE;
-
chip->dev = &pdev->dev;
-
chip->get = zynq_gpio_get_value;
-
chip->set = zynq_gpio_set_value;
-
chip->request = zynq_gpio_request;
-
chip->free = zynq_gpio_free;
-
chip->direction_input = zynq_gpio_dir_in;
-
chip->direction_output = zynq_gpio_dir_out;
-
chip->to_irq = zynq_gpio_to_irq;
-
chip->dbg_show =
NULL;
-
chip->base =
0;
/* default pin base */
-
chip->ngpio = ZYNQ_GPIO_NR_GPIOS;
-
chip->can_sleep =
0;
get、set、request、free、direction_input、direction_output、to_irq这几个回调应该很清楚了，也知道是哪几个接口调用的它们了吧，另外几个关键的参数base和ngpio在上面的gpiochip_add里应该也已经清楚了它们的重要作用了吧！
of_gpiochip_add会处理gpio chip设备树相关的东西：
-
void of_gpiochip_add(struct gpio_chip *chip)
-
{
-
if ((!chip->of_node) && (chip->dev))
-
chip->of_node = chip->dev->of_node;
-
-
if (!chip->of_node)
-
return;
-
-
//如果没有指定of_xlate，那给一个默认的吧！of_xlate用于解析设备树里gpio属性
-
//不同的soc可能需要不同的解析方法，但是如果没有什么特别，那就用默认的解析吧
-
//当前设备树的节点里支持两种格式的属性，一种是xxx-gpios，另一种就直接是gpios
-
//如前文中用到的row-gpios就是一种
-
if (!chip->of_xlate) {
-
chip->of_gpio_n_cells =
2;
-
chip->of_xlate = of_gpio_simple_xlate;
-
}
-
-
//这一步就是与pinctrl子系统打交道啦！后面会简单分析下它都做了什么
-
//等到讲pinctrl子系统的时候就更加清楚了
-
of_gpiochip_add_pin_range(chip);
-
//增加该节点引用计数
-
of_node_get(chip->of_node);
-
}
关于of_gpiochip_add_pin_range，看起来很复杂，其实也就那样啦_：
-
static void of_gpiochip_add_pin_range(struct gpio_chip *chip)
-
{
-
struct
device_node *np = chip->of_node;
-
struct
of_phandle_args pinspec;
-
struct
pinctrl_dev *pctldev;
-
int index =
0, ret;
-
const
char *name;
-
static
const
char group_names_propname[] =
"gpio-ranges-group-names";
-
struct
property *group_names;
-
-
if (!np)
-
return;
-
-
//查找该gpiochip里的gpio-ranges-group-names属性
-
group_names =
of_find_property(np, group_names_propname,
NULL);
-
-
for (;; index++) {
-
//提取该gpiochip设备树信息里的gpio-ranges属性，按3个字段为一组解析，解析后
-
//放到pinspec中，这个gpio-ranges可能存在多组，因此用index来控制，一组一组来处理
-
//举个例子：
-
//gpio0: gpio@ffc40000 {
-
// compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
-
// reg = <0xffc40000 0x2c>;
-
// interrupt-parent = <&gic>;
-
// interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
-
// #gpio-cells = <2>;
-
// gpio-controller;
-
// gpio-ranges = <&pfc 0 0 32>;
-
// #interrupt-cells = <2>;
-
// interrupt-controller;
-
//};
-
//gpio-ranges属性是gpio子系统规定的属性，更详细的信息参考
-
//Documentation/devicetree/bindings/gpio/gpio.txt
-
ret =
of_parse_phandle_with_fixed_args(np,
"gpio-ranges",
3,
-
index, &pinspec);
-
if (ret)
-
break;
-
-
//获取到pinspec.np（也就是pinctrl对应的节点）对应的pctldev
-
//注意，这个时候的gpiochip属于pinctrl的一个client
-
pctldev =
of_pinctrl_get(pinspec.np);
-
if (!pctldev)
-
break;
-
-
//这部分的解析也是Documentation/devicetree/bindings/gpio/gpio.txt里有详细
-
//说明的，如果最后一个参数为0，表示代表一个gpio group，否则，第一个参数意思是gpio号起始值
-
//第二个参数意思是与之对应的pin号的起始值，最后一个参数表示连续多少各
-
if (pinspec.args[
2]) {
-
if (group_names) {
//这里仅仅是校验，如果不是表示gpio group，那么对应的
-
//gpio-ranges-group-names属性里对应的字段应该为""
-
ret =
of_property_read_string_index(np,
-
group_names_propname,
-
index, &name);
-
if (
strlen(name)) {
-
pr_err(
"%s: Group name of numeric GPIO ranges must be the empty string.\n",
-
np->full_name);
-
break;
-
}
-
}
-
/* npins != 0: linear range */
-
//到这里说明确定不是gpio group啦，那就将它们加入到pinctrl子系统管理起来吧
-
//，这里后面分析pinctrl子系统的时候再回过头来分析它
-
ret =
gpiochip_add_pin_range(chip,
-
pinctrl_dev_get_devname(pctldev),
-
pinspec.args[
0],
-
pinspec.args[
1],
-
pinspec.args[
2]);
-
if (ret)
-
break;
-
}
else {
-
/* npins == 0: special range */
-
//校验，为pin gourp时，gpio 子系统要求第一个参数必须要0
-
if (pinspec.args[
1]) {
-
pr_err(
"%s: Illegal gpio-range format.\n",
-
np->full_name);
-
break;
-
}
-
-
//如果是pin group，那么gpio-ranges-group-names属性必须要有，通过它来指定
-
//那个group
-
if (!group_names) {
-
pr_err(
"%s: GPIO group range requested but no %s property.\n",
-
np->full_name, group_names_propname);
-
break;
-
}
-
-
//获取gpio-ranges-group-names属性里第index对应的字串（也就是组名）
-
ret =
of_property_read_string_index(np,
-
group_names_propname,
-
index, &name);
-
if (ret)
-
break;
-
-
if (!
strlen(name)) {
-
pr_err(
"%s: Group name of GPIO group range cannot be the empty string.\n",
-
np->full_name);
-
break;
-
}
-
-
//一切ok，按group将它们加入到pinctrl子系统管理起来吧，这里后面分析pinctrl子系统的
-
//时候再回过头来分析它
-
ret =
gpiochip_add_pingroup_range(chip, pctldev,
-
pinspec.args[
0], name);
-
if (ret)
-
break;
-
}
-
}
-
}
总结一下，gpiochip_add总共做了以下主要事情：
- 将chip添加到全局的gpio chip链表中，用于gpio chip冲突处理和gpio管理
- 将该gpio chip对应的那段gpio都初始化
- 初始化设备树相关的信息，用于后面的属性解析及向pinctrl子系统同步下
- 导出到sys
还有一点需要补充，从这里我们也会发现pinctrl由gpio子系统调用了，驱动工程师以及bsp工程师都不用关心，多好啊！后面会再次看到，大部分都是内核的通用部分代码处理了pinctrl，驱动工程师以及bsp工程师仍然不用关心，只需要关心设备树里pinctrl相关的部分，不过我们也得知其所以然啊，不然改动那些和pinctrl相关的总是心理没底啊！！！和bsp驱动工程师相关的部分就一个函数，没其他的了。不过准备chip里面的那些字段也够bsp工程师忙一阵子了吧_
下面开始分析驱动工程师调用的gpio_request的过程，它的核心实现是调用gpiod_request，gpiod_get和gpiod_get_index的核心实现处理也调用了gpiod_request，但还做了一些其他事情，如解析gpios或者xxx-gpios属性获取设备树里指定的flags以及通过指定的gpio号获取到对应的desc（在上面的gpiochip_add过程中，我们有看到了desc的初始化），当然解析的过程会用到gpiochip_add里说过的of_xlate
-
if (
IS_ENABLED(CONFIG_OF) && dev && dev->of_node) {
-
dev_dbg(dev,
"using device tree for GPIO lookup\n");
-
desc =
of_find_gpio(dev, con_id, idx, &flags);
-
}
else
if (
IS_ENABLED(CONFIG_ACPI) && dev &&
ACPI_HANDLE(dev)) {
-
dev_dbg(dev,
"using ACPI for GPIO lookup\n");
-
desc =
acpi_find_gpio(dev, con_id, idx, &flags);
-
}
以及根据设备树里指定的flags设置desc，比如是否低电平有效，是否开漏输出等
-
if (flags & GPIO_ACTIVE_LOW)
-
set_bit(FLAG_ACTIVE_LOW, &desc->flags);
-
if (flags & GPIO_OPEN_DRAIN)
-
set_bit(FLAG_OPEN_DRAIN, &desc->flags);
-
if (flags & GPIO_OPEN_SOURCE)
-
set_bit(FLAG_OPEN_SOURCE, &desc->flags);
gpio_request里面做的事情前面已经说的很清楚了，下面结合代码再回顾下：
-
static int gpiod_request(struct gpio_desc *desc, const char *label)
-
{
-
int status = -EPROBE_DEFER;
-
struct gpio_chip *chip;
-
-
//检查desc是否有效，gpio_request会根据传入的gpio号在全局的desc里定位到desc
-
//gpiod_get和gpiod_get_index则是通过解析设备树信息，提取里面的gpio号，然后再转换
-
if (!desc) {
-
pr_warn(
"%s: invalid GPIO\n", __func__);
-
return -EINVAL;
-
}
-
-
//获取该desc的拥有者，即gpio chip（这个初始化在gpiochip_add里已经分析过了）
-
chip = desc->chip;
-
if (!chip)
-
goto
done;
-
-
if (try_module_get(chip->owner)) {//增加下chip的引用
-
status = __gpiod_request(desc, label);//核心动作都是在__gpiod_request里完成，就不再跟进去分析了^_^
-
if (status < 0)
-
module_put(chip->owner);
-
}
-
-
done:
-
if (status)
-
gpiod_dbg(desc,
"%s: status %d\n", __func__, status);
-
-
return status;
-
}
总结一下，驱动工程师用gpio_request等api请求指定的gpio，这些gpio其实都是由bsp工程师调用gpiochip_add添加的，gpio_request会标记它，防止被不同的模块重复引用该gpio，当然也会告诉下gpio chip（如果chip想要被通知的话）
2> gpio_to_irq/gpiod_to_irq的过程分析
通过前面的分析，应该对gpio子系统有了一个比较完全的了解吧！其他的api应该也都能理解（猜测到会做什么），这里在对和gpio相关的中断分析下
gpio_to_irq只是简单的对gpiod_to_irq进行封装，主要看gpiod_to_irq：
-
int gpiod_to_irq(const struct gpio_desc *desc)
-
{
-
struct
gpio_chip *chip;
-
int offset;
-
-
if (!desc)
-
return -EINVAL;
-
chip = desc->chip;
-
//获取该gpio号对应于该chip的offset，由于chip的起始号不一定就开始与系统全局desc的起点
-
//而该chip的处理又都是基于0开始的，所以得转一下啦
-
offset =
gpio_chip_hwgpio(desc);
-
//调用芯片驱动提供的to_irq，如果chip driver不支持中断，那么to_irq应该就是空咯，说明不支持
-
//从这里应该也清楚的知道了gpio号与中断号的对应关系是由chip driver处理的
-
//驱动工程师用的gpio号都是全局的，bsp工程师用的gpio号都是局部的
-
return chip->to_irq ? chip->
to_irq(chip, offset) : -ENXIO;
-
}
还是看一下zynq的to_irq的实现吧！说到这里，会牵涉到中断子系统（貌似我还没写过中断子系统的文章），如果不太清楚，就跳过吧！
-
static int zynq_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
-
{
-
return
irq_find_mapping(irq_domain, offset);
-
}
看起来貌似很简单吧！其实这也要归功于中断子系统的功劳啦！一般有中断控制器功能的设备会在该设备驱动里调用irq_domain_add_xxx接口来注册一个irq domain，然后会调用irq_create_mapping来创建irq号与硬件号的对应关系，里面会分配期望的irq desc，分配的时候，该中断控制器对应的中断号就确定了，然后会绑定该irq号与传入的硬件号。这就为后面的irq_find_mapping提供了支持，通过硬件号获取对应的irq号。这里再多说一句，大部分gpio chip同时也是一个中断控制器，写bsp的苦逼们不仅要gpiochip_add还要irq_domain_add等等操作，于是乎，gpio子系统解救他们来了，提供了一个接口gpiochip_irqchip_add，这接口完成后和gpio中断相关的所有事情，于是乎，bsp驱动工程师们也只需要调用两个接口了_多么美好！
未完，待续！
2015年7月
1963
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
