高通平台tp驱动（一）

在网上对于gsl680驱动的剖析文章很多，本人自己也负责过tp驱动的移植，但是对于内部tp驱动的构造从未了解过，觉得有必要对tp驱动进行一个梳理。以下仅为本人观点，如有不对欢迎各路大佬指点，目的主要是分析tp驱动的整个流程

首先，分析一个驱动，特别是像我这种工作经验不是很饱满的人，我自己习惯的方式是：先对整个驱动相关文件进行一个梳理，入口、出口以及他内部主要核心操作都在哪里。因此，我后面会分为三篇文章进行我个人的梳理。分别是以下：

1.入口函数gsl_g15d_init的初始化操作

2.gsl680驱动的前期工作（如供电、复位、中断脚初始化等）

3.gsl680驱动的input子系统相关步骤

那么本篇就先从头开始分析gsl680驱动的入口及初始化操作

module_init(gsl_g15d_init);

这里是作为一个驱动的入口，没啥好说的

return i2c_add_driver(&gsl_ts_driver);

这个是将gsl_ts_driver这个驱动结构体添加至i2c总线上，i2c_add_driver这个就是一个i2c总线添加驱动的api，会用即可

static struct i2c_driver gsl_ts_driver = {
        .driver = {
                .name = GSL_TS_NAME,
        .owner    = THIS_MODULE,
                .of_match_table = gsl_match_table,
        },
        .probe = gsl_ts_probe,
        .remove = gsl_ts_remove,
        .id_table       = gsl_ts_id,
};

而这个gsl_ts_driver的结构体内就会定义各个内容，其中.driver以及.id_table可以理解为就是为了与设备树内的tp设备进行一个配对操作，这个也不是重点。我们主要分析的重点应该放在.probe属性上，看看gsl_ts_probe做了什么

static int gsl_ts_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
        int err = 0;
        struct input_dev *input_dev;

        struct gsl_ts_platform_data *pdata;
        dev_info("%s\n",__func__);
        printk("%s: ======probe begin ========\n",__func__);
        printk("i2c addr: 0x%02x from dtsi\n",client->addr);

        if (client->dev.of_node) {
                pdata = devm_kzalloc(&client->dev,
                        sizeof(struct gsl_ts_platform_data), GFP_KERNEL);
                ...
                err = gsl_parse_dt(&client->dev, pdata);
                ...
        else
                pdata = client->dev.platform_data;
        }
        if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
                err = -ENODEV;
        dev_err(&client->dev, "I2c doesn't work\n");
                goto exit_check_functionality_failed;
        }
}

在probe函数的上半段，我们可以看到他实际上的功能就集中在两部分：gsl_parse_dt以及i2c_check_functionality。

首先看看gsl_parse_dt，从名称上可以看到似乎是与设备数比对相关。

static int gsl_parse_dt(struct device *dev, struct mxt_platform_data *pdata)
{
         struct device_node *np;
    if (!dev)
        return -ENODEV;

       np = dev->of_node;
        pdata->name = "gsl";
        pdata->irq_gpio = of_get_named_gpio(np, "silead,irq-gpio", 0);
        pdata->reset_gpio = of_get_named_gpio(np, "silead,rst-gpio", 0);
    if (!gpio_is_valid(pdata->irq_gpio) || !gpio_is_valid(pdata->reset_gpio)) {
        printk("Invalid GPIO, irq-gpio:%d, rst-gpio:%d",
            pdata->irq_gpio, pdata->reset_gpio);
        return -EINVAL;
    }
    return 0;
}

这里确实是跟我们上面猜测的搭边，与设备数有关。of_get_name_gpio是linux自带的api，用于搜索设备树节点内的属性名称，这里是通过搜索"silead,irq-gpio"以及"silead,rst-gpio"这个属性确定中断gpio以及复位gpio（实际上根据大佬跟我说的，tp驱动最关键的就是中断以及复位），获取成功后会进行判断这两个gpio是否真的被获取到了。

那么至此，我们的设备树里面已经有3个属性可以根据硬件原理图填写了，分别是 compatible（初始化过程中的配对name）、silead,irq-gpio（中断gpio）以及silead,reset-gpio（复位gpio）

        gsl{
            compatible = "silead,gsl-tp";
            silead,rst-gpio = <&tlmm 87 0x0>;
            silead,irq-gpio = <&tlmm 88 0x2002>;
        };

下面就是另外一个函数：i2c_check_functionality，实际上就是通过调用kernel内的api，判断当前的这个驱动是否匹配i2c总线设备模型罢了。

        if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
                err = -ENODEV;
        dev_err(&client->dev, "I2c doesn't work\n");
                goto exit_check_functionality_failed;
        }

所以，第一章讲的内容其实特别简单，一些很基础的知识。只不过我个人认为自己有必要梳理这部分的知识罢了，基础不牢谈何上层。