Android TP Drive porting Debug Notes

1. Add I²c Device

TP is generally used as the data and command interface, so TP driver can also be categorized as an I²c drive. The main logic of TP driver is not here, but the understanding of the Linux I²c architecture, you can have the entire drive process has

A clearer understanding, but here is not a detailed discussion of the architecture of the i²c, only around how to migrate the development of TP-driven discussion.

In the board-level file, that is, rising micro code file BOARD-RK30-SDK.C, instantiate a i2c_board_info structure, the structure of the abstract description of a specific i²c device, and then add the instance to the __i2c_board_list global linked list. To cite an example:

#if defined (CONFIG_TOUCHSCREEN_PIXCIR)

{

. Type = "Pixcir_ts",

. addr = 0x5c,

. Flags = 0,

. IRQ = RK30_PIN4_PC2,

. Platform_data = &pixcir_info,

},

#endif

Understand the I²C architecture should know that the Linux system can successfully find the I²C adapter, that is, after the I²c controller, will be scanned __i2c_board_list This list, each find a i2c_board_info, will generate an i²c Some of _client,i2c_client's information comes from I2c_board_info, partly from I2c_adapter. I2c_client represents a true-to-true i²c device because it has both the information describing its basic properties and the method of describing its behavior, which is popularly said to be the transmission method of I²c.

Now we can go back and talk about the meaning of each member of the I2C_BOARD_INFO structure mentioned earlier. The type member is used to assign to the name member in the later generated i2c_client, and name in I2c_client represents the name of the i2c_client. Addr is the address of this i²c device, it and the I²C controller together to indicate that the I²C device, if our TP is mounted on the controller 0, then 0-005c is the i²c device, 0-005c we can also find in the SYS system. Flag is an i²c read-write flag, 0 for write, 1 for read. IRQ is the interrupt pin for this i²c device. Platform_data is used when the driver is registered.

2. Add the I²c Drive

People familiar with the Linux device driver model understand the device, driver, bus relationship, above we are talking about equipment, light has equipment not, but also have to drive. General TP supplier will have the driver to provide us, here we use rising Micro SDK PIXCIR_I2C_TS.C to make an example.

The first step is to add the I²c driver:

I2c_add_driver (&pixcir_i2c_ts_driver);

This function is not discussed here, Pixcir_i2c_ts_driver is defined as follows:

static struct I2c_driver Pixcir_i2c_ts_driver = {

. Driver = {

. Owner = This_module,

. Name = "pixcir_i2c_ts_v3.3.09",

#ifdef PIX_DRV_ATTR

. Groups = Pixcir_drv_grp,

#endif

},

#ifndef Config_has_earlysuspend

. Suspend = Pixcir_i2c_ts_suspend,

. Resume = Pixcir_i2c_ts_resume,

#endif

. Probe = Pixcir_i2c_ts_probe,

. remove = __devexit_p (Pixcir_i2c_ts_remove),

. id_table = pixcir_i2c_ts_id,

};

According to the Linux device driver model, once the bus has a new driver to join, then the system will automatically search for all the devices mounted on this bus, and then take the name of each device and the driver of the id_table comparison, if the name of the two, then the next execution of the driver inside the probe function.

3. Probe in TP drive

No matter what kind of TP drive, in the probe do the following several things:

1) apply TP corresponding IO port, then reboot the device

2) Application for TP interruption, the person familiar with the Linux outage should know the top and bottom half of the interrupt mechanism, so to apply for a work queue and initialize a task.

Init_work (&tsdata->work.work, Pixcir_ts_poscheck);

Pixcir_wq = Create_singlethread_workqueue ("Pixcir_wq");

The data escalation process for TP is that when manually pressed, TP generates an interrupt in the Interrupt service program, which reads the data out and reports the data to the operating system via the input subsystem.

3) TP on the hardware through the I²c interface to tell people its data, the software is through the input subsystem to tell the operating system its data, and the first step of using the input subsystem is to request an input sub-device:

Input_allocate_device ();

This is not discussed in detail here, the basic unit of input subsystem communication is an event, there are three kinds of attributes: type, encoding (code), value. The input subsystem supports a wide variety of events, many kinds of event encoding, so before using the input device, you need to set what type of event the device supports and what the event code is.

4) The general TP driver is supported by the following types of events

__set_bit (Ev_key, input->evbit);

__set_bit (Ev_abs, input->evbit);

__set_bit (Ev_syn, input->evbit);

5) Determine the multi-touch protocol. The multi-Touch protocol has a protocol with the B protocol. Class A adds Input_mt_sync (Touch_dev->input_dev) after each reporting point;

Class B is required to execute input_mt_init_slots (Ts->input_dev, Ts->max_touch_num) in probe, and then input_mt_slot before each reporting point (Ts->input_dev, index);

6) Register the device with the input subsystem:

Input_register_device (Ts->input_dev);

4. Touch screen Debugging FAQ Reference:

1) After loading the driver, the lock cannot be solved.

You can first unlock it with a USB mouse. If you can use ADB, you can also directly use the ADB shell input keyevent 82 Unlocked

2) Click on the screen does not respond

Make sure that the I²C device is powered properly, determine if the probe is executed, if it is executed, and then determine if IO has not been initialized first, there is no restart device, then determine if the I²c pass, click on the screen can enter the interrupt.

3) The probe was not executed. Check that the type member definition of the I2c_board_info terminal is the same as the id_table in I2c_driver.

4) The i²c does not pass. Check the power supply normal No, there is no restart the device, I²c address there is no error, and some i²c device is 7 bits, some with 8 bit, 8 bit must move right one

5) The most frequently occurring problem, TP is not the point of the report.

This problem has not been summed up in a methodology so far. Personal debugging experience, this with the LCD resolution, TP resolution, input subsystem settings are related.

Let's start with an example to determine the resolution of the screen, if the resolution is 800 * 1280, then it should look like this:

Chart 1 LCD screen representation diagram

If the TP resolution is also 800 * 1280

Chart 2 TP resolution representation diagram

As shown in the above two pictures, the LCD and TP resolution is the same, and the same as the original point, if the input subsystem parameters are set to:

Input_set_abs_params (Ts->input_dev, abs_mt_position_x, 0, 800, 0, 0);

Input_set_abs_params (Ts->input_dev, abs_mt_position_y, 0, 1280, 0, 0);

Then the reported point should be without any conversion, that is to say the point is right.

Let's discuss another scenario, if the TP resolution is:

Figure 3 TP Resolution Indicator chart

It is worth mentioning that the X, y axes of TP can be interchanged, but the origin will not change. 3 TP with the LCD of Figure 1, since the original point of the LCD is different from the origin of TP, then the reported point must be driven by the conversion. The formula for conversion is:

X=800-y1;

y=x1;

6) How to find the LCD origin and TP Origin point.

The LCD origin should be before the system does not do any flipping, when the system is lit, the little penguin appears in the place

The origin of TP, should be in the TP drive in the X, Y did not undergo a logical conversion, with PRINTK print out the point information.

Reprint: http://blog.csdn.net/jkzrc/article/details/18549957

Android TP Drive porting Debug Notes (RPM)