老人机侧键keypad流程

云科　　戴杨一如

kernel/drivers/misc/Makefile里搜索到这一行

obj-$(CONFIG_INPUT_GPIO)        += gpio_event.o gpio_matrix.o gpio_input.o gpio_output.o gpio_axis.o
于是定位到这几个源文件，其中按键设备的注册在gpio_event.c

然后到kernel/arch/arm/mach-msm/下查找配置文件，注意文件名大概是board-????a.c。如何确定呢，笔者在这里走了弯路，浪费了大量时间。前辈jjl使用的方法是，在kernel/arch/arm/mach-msm/下搜索关键字GPIO_EVENT_DEV_NAME（代表按键设备结构体？），在搜索结果中只看到两个文件名符合7?27，所以把范围缩小到这两个文件：Board-msm7x27a.c和Board-qrd7627a.c。然后查看开机log，注意到这行：

Machine: QRD MSM7627a QRD3

于是确定了板的名字，所以配置的文件应该是这个：

board-qrd7627a.c，而不是原先修改的board-msm7x27a.c

并在该文件的底部这一行里得到验证：

MACHINE_START(MSM7627A_QRD3, "QRD MSM7627a QRD3")

接下来在上述文件中搜kp，找到数组keymap。在其中配置GPIO引脚

#define KP_INDEX(row, col) ((row)*ARRAY_SIZE(kp_col_gpios) + (col))

static unsigned int kp_row_gpios[] = {31, 32, 84, 82};
static unsigned int kp_col_gpios[] = {36, 37, 38, 39};

static const unsigned short keymap[ARRAY_SIZE(kp_col_gpios) *
                      ARRAY_SIZE(kp_row_gpios)] = {
    [KP_INDEX(0, 0)] = KEY_VOLUMEUP,    /*volume up */
    [KP_INDEX(0, 1)] = KEY_HOME,        /*HOME*/
    [KP_INDEX(0, 2)] = KEY_1,           /*remind taking medicine*/
    [KP_INDEX(0, 3)] = KEY_2,           /*read message*/

    [KP_INDEX(1, 0)] = KEY_VOLUMEDOWN,  /*volume down */
    [KP_INDEX(1, 1)] = KEY_HELP,        /*SOS*/
    [KP_INDEX(1, 2)] = KEY_3,           /*999*/

    [KP_INDEX(2, 0)] = KEY_RADIO,           /*radio*/
    [KP_INDEX(3, 0)] = KEY_5,               /*torch*/
    
};

然后要将上面等式右边的值配置到这个项目的配置文件中去：device/cct/M4000E/7x27a_kp.kl
# Function keys

key 528    FOCUS
key 87    POWER              WAKE
key 102    HOME
key 212    CAMERA
key 59    MESSAGE
key 60    SOS
key 61    Family number
key 62    FM open
key 63    FM close

# Volume keys
key 115   VOLUME_UP
key 114   VOLUME_DOWN

注意该文件无需编译直接烧录，烧录目标地址：/system/usr/keylayout/7x27a_kp.kl

到此按键的部分（除了按键灯）就基本配置完了

 

当使用函数request_irq注册中断后，该中断应该出现在linux虚拟文件系统下proc/interrupts；查看是否已经注册了中断：adb shell; cat proc/interrupts;

在打印出的列表中，从左到右的字段依次代表：irq的序号（request_irq的第一个参数irq）， 在各自cpu上发生中断的次数，可编程中断控制器，设备名称（request_irq的第四个参数name）

在这里我看到自己的gpio_kp的中断，其序号是100。irq的与对应gpio脚的关系取决于函数gpio_to_irq，这个函数，基本上是返回（参数+64），即，在proc/interrupts看到的irq号，应该是你程序中gpio_to_irq函数的参数——gpio脚编号，再加上64.

 

另外注意这个源文件：modem_proc/dal/drivers/tlmm/src/bsp/7627A/TLMMBsp_M4000E.c

其中组数PRIMARY_CONFIGS中定义了GPIO脚的输入与输出：

uint32 PRIMARY_CONFIGS[TLMM_BSP_NUM_GPIO] =
{

　　…………

　　BSP_GPIO_IN_36,          //GPIO36 KEYPAD_C0
    BSP_GPIO_IN_37,          //GPIO37 KEYPAD_C1
    BSP_GPIO_IN_38,          //GPIO38 KEYPAD_C2
    BSP_GPIO_OUT_39,         //GPIO39 MSM_WAKE_WLAN

　　......

    BSP_GPIO_IN_82,         //GPIO82 DEBUG_SELECT   
    BSP_GPIO_IN_84,

}

而下面这个数组定义了不同的GPIO脚的控制权限：MASTER->modern; PERIPHERAL->CPU

TLMM_BSP_OwnerProcType TLMM_OWNERS[TLMM_BSP_NUM_GPIO]={

......

　　TLMM_OWNER_MASTER, /* 81  */
    TLMM_OWNER_PERIPHERAL, /* 82  */
    TLMM_OWNER_MASTER, /* 83  */

    TLMM_OWNER_PERIPHERAL, /* 84  */
    TLMM_OWNER_PERIPHERAL, /* 85  */

......

}

上面这几个配置的修改是必须的，我的82和84脚就是因为一直被配置成了OUT了，并且权限被设置成了MASTER，所以不能产生中断。

整个modem的编译方式是在windows下：打开cmd，进入modem_proc/build/ms文件夹，  运行BuildP500.cmd。 

编译结果似乎在：amss.bin (fat.amss.bin for android4.1)？

当然，第一次写驱动，bug几乎是无穷无尽，除了上述原因之外，我的probe中没有给input_dev->name赋值，于是加上这句：input_dev->name = i ? "FM_botton" : "Torch_botton";这个bug是通过kmsg的开机log中的probe这个报错得知的：input: Unspecified device as /devices/virtual/input/input5………………

 

按键灯的源文件位于kernel/drivers/leds/leds-msm-pmic.c　　我搜寻的方法是用高端自创脚本findInFiles在整个内核驱动中搜button.*light，仅此一个结果：./leds/leds-msm-pmic.c:51:     .name            = "button-backlight",　　。哇哈哈哈哈哈，不要羡慕.

另外，板子上的pmic-leds设备注册受限于编译开关CONFIG_LEDS_MSM_PMIC：

#ifdef CONFIG_LEDS_MSM_PMIC
static struct platform_device msm_device_pmic_leds = {
    .name   = "pmic-leds",
    .id = -1,
};
#endif

所以要在config中定义这一编译开关：

在kernel/arch/arm/configs/M4000E-debug-perf_defconfig中加入一行：CONFIG_LEDS_MSM_PMIC=y

而M4000E-debug-perf_defconfig这个编译配置文件将被这个makefile文件读入：device/cct/M4000E/AndroidBoard.mk

led按键灯的亮灭由服务层控制，服务层通过往/sys/devices/platform/pmic-leds/leds/button-backlight/brightness写非零值开灯，写0值关灯。可以在adb中验证：echo 0 > brightness；echo 1 > brightness

 

tp源文件：ft5x06_ts.c

转载于:https://www.cnblogs.com/yiru/archive/2013/03/06/2945656.html