基于tiny4412的ts驱动简单分析

学完了S3C2440的相关知识，了解了驱动和应用的开发流程。想找块其他的板子练下手。考虑到后面会进行android的学习，于是开始动手折腾S3C4412的板子。这一折腾，就被折腾得够呛了，像一根小牙签掉到了大水缸里啊。

首先，我手里有块现成的itop4412的板子，拿到迅为的uboot和kernel包，开始编译，下载。然后修改内核。由于原内核已经做好了所有的工作，想尝试移植一个高版本的内核。以为在2440上的内核是3.4.2，所有想直接用上去。用make exynos_defconfig然后make menuconfig配置early_print和comand line，编译下载，弹出不能识别的处理器id。于是各种找，在arch/arm/mm下的proc-v7.s里找到了对ARMv的支持

#ifndef CONFIG_ARM_LPAE
    /*
     * ARM Ltd. Cortex A5 processor.
     */
    .type   __v7_ca5mp_proc_info, #object
__v7_ca5mp_proc_info:
    .long   0x410fc050
    .long   0xff0ffff0
    __v7_proc __v7_ca5mp_setup
    .size   __v7_ca5mp_proc_info, . - __v7_ca5mp_proc_info

    /*
     * ARM Ltd. Cortex A9 processor.
     */
    .type   __v7_ca9mp_proc_info, #object
__v7_ca9mp_proc_info:
    .long   0x410fc090
    .long   0xff0ffff0
    __v7_proc __v7_ca9mp_setup
    .size   __v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
#endif  /* CONFIG_ARM_LPAE */
这里显然要去掉CONFIG_ARM_LPAE的支持。
    配置去掉CONFIG_ARM_LPAE之后，不支持的信息倒是没有了，关键太干净了，一点early_print都没了。后来发现itop的所有prink都是直接调用的print_ascii，这个函数在debug.s里定义，是直接打开串口很暴力的往里面灌数据。ok，那我也把printk改了吧，不然真不知道问题出在哪里。

    Error: unrecognized/unsupported machine ID (r1 = 0x00000b16)
这个就直接修改mach-types了，找到4412的板级信息。就这样把你征服。
然后，我就看到了内核的一堆打印信息。最终以内核崩溃，打印一大堆堆栈信息结尾。那只能愚公移山了。从start_kernel开始，一点点打印，mach_setup过了，console_init过了，最后顽强了跑完了init进程。在setup_machine_tags里死掉了。最后定位到phys_to_virt。反复尝试，都没能找到原因。最后网上搜索，发现可能是TRUST_ZONE的问题。itop的uboot开启了trust_zone。询问他们客服，也是爱答不理。无奈尝试修改uboot也不行。最后，流着眼泪，用最low的办法，重新败了一块tiny4412的开发板。因为想跟上自己的学习计划，不想在这里浪费太多时间，等以后有时间再好好研究这个问题。
tiny4412的板子还好，按网上的办法，烧uboot(他自己支持闭源的superboot)。内核，能启动起来了。
系统启动，挂载上了nfs文件系统，能在控制台敲各找命令了。显示屏也亮起来了，但是触摸屏怎么按都没反应。这怎么行。对于一个顽强的码农，是不能被苦难吓倒的。
开始对ts的驱动剥皮拆骨。
首先，应用层对ts事件的读取是这样的
打开ts设备

    ts_fd = open("/dev/input/event1",02);  
读取ts事件

    rd = read(event0_fd, buf, sz);  
读取的方式为阻塞方式。
内核中间，触摸屏的驱动为ft5x06.c，当手指按压式，能够触发中断，并且报的坐标也大致正确。但是应用就是不能接收到数据。仔细对照了input_register_device的流程

set_bit(EV_SYN, input_dev->evbit);
set_bit(EV_ABS, input_dev->evbit);
set_bit(EV_KEY, input_dev->evbit);

ifdef CONFIG_FT5X0X_MULTITOUCH

set_bit(ABS_MT_TRACKING_ID, input_dev->absbit);
set_bit(ABS_MT_TOUCH_MAJOR, input_dev->absbit);
set_bit(ABS_MT_WIDTH_MAJOR, input_dev->absbit);
set_bit(ABS_MT_POSITION_X, input_dev->absbit);
set_bit(ABS_MT_POSITION_Y, input_dev->absbit);

input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, ts->screen_max_x, 0, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, ts->screen_max_y, 0, 0);
input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0, ts->pressure_max, 0, 0);
input_set_abs_params(input_dev, ABS_MT_WIDTH_MAJOR, 0, 200, 0, 0);
input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, FT5X0X_PT_MAX, 0, 0);

else

set_bit(ABS_X, input_dev->absbit);
set_bit(ABS_Y, input_dev->absbit);
set_bit(ABS_PRESSURE, input_dev->absbit);
set_bit(BTN_TOUCH, input_dev->keybit);

input_set_abs_params(input_dev, ABS_X, 0, ts->screen_max_x, 0, 0);
input_set_abs_params(input_dev, ABS_Y, 0, ts->screen_max_y, 0, 0);
input_set_abs_params(input_dev, ABS_PRESSURE, 0, ts->pressure_max, 0 , 0);

endif

input_dev->name = FT5X0X_NAME;
input_dev->id.bustype = BUS_I2C;
input_dev->id.vendor = 0x12FA;
input_dev->id.product = 0x2143;
input_dev->id.version = 0x0100;

err = input_register_device(input_dev);

原来是定义了多点触摸，上报的时间也自然不一致了。屏蔽这个宏之后，以为大功告成了。还是没有没有反应。
跟踪到event read过程。
在evdev.c中

static ssize_t evdev_read(struct file *file, char __user *buffer,
          size_t count, loff_t *ppos)
{
struct evdev_client *client = file->private_data;
struct evdev *evdev = client->evdev;
struct input_event event;
size_t read = 0;
int error;

if (count != 0 && count < input_event_size())
    return -EINVAL;

for (;;) {
    if (!evdev->exist)
    {
        return -ENODEV;
    }

    if (client->packet_head == client->tail &&
        (file->f_flags & O_NONBLOCK))
        return -EAGAIN;

    /*
     * count == 0 is special - no IO is done but we check
     * for error conditions (see above).
     */
    if (count == 0)
        break;

    while (read + input_event_size() <= count &&
           evdev_fetch_next_event(client, &event)) {

        if (input_event_to_user(buffer + read, &event))
        {
            return -EFAULT;
        }

        read += input_event_size();
    }

    if (read)
        break;

    if (!(file->f_flags & O_NONBLOCK)) {
        error = wait_event_interruptible(evdev->wait,
                client->packet_head != client->tail ||
                !evdev->exist);
        if (error)
            return error;
    }
}
return read;

}

会一直停在wait_event_interruptible处。
而屏幕按压触发后的提交过程

    ft5x0x_ts_report
        input_report_abs
        input_report_key
        input_sync
            input_event
                input_handle_event
                    input_pass_event
                        handler->event(handle, type, code, value);
最终调用的是edev的event成员。
这个handler是在evdev.c中定义的evdev_handler

static struct input_handler evdev_handler = {
    .event      = evdev_event,
    .connect    = evdev_connect,
    .disconnect = evdev_disconnect,
    .fops       = &evdev_fops,
    .minor      = EVDEV_MINOR_BASE,
    .name       = "evdev",
    .id_table   = evdev_ids,
};

event既是evdev_event

static void evdev_event(struct input_handle *handle,
        unsigned int type, unsigned int code, int value)

{
struct evdev *evdev = handle->private;
struct evdev_client *client;
struct input_event event;
ktime_t time_mono, time_real;

time_mono = ktime_get();
time_real = ktime_sub(time_mono, ktime_get_monotonic_offset());

event.type = type;
event.code = code;
event.value = value;

rcu_read_lock();

client = rcu_dereference(evdev->grab);

if (client)
    evdev_pass_event(client, &event, time_mono, time_real);
else
    list_for_each_entry_rcu(client, &evdev->client_list, node)
        evdev_pass_event(client, &event, time_mono, time_real);

rcu_read_unlock();

if (type == EV_SYN && code == SYN_REPORT)
{
    wake_up_interruptible(&evdev->wait);
}

}
“`

在这里唤醒了进程。这样就和evdev的read对应上了。打印
handle->handler->name的名称，竟然为event0，而应用使用的却是event1。一个小小的疏忽，折腾了好久。但把input和evdev分析一遍，还是有点收获的