Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to configure Linux driver". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to configure Linux driver.

Summary

The AM335x touchscreen controller supports the following four operating modes:

8-way universal ADC

4-way as 4-wire touch screen connection, 4-way as general ADC

5-way as a 5-wire touch screen connection, 3-way as a general ADC

8-way connection as an 8-wire touch screen

ADC uses 12-bit SAR ADC with a sampling rate of 200k per second. The AD sampling analog signal starts when the start of conversion is high and continues to sample within 1 clock cycle after the falling edge. It captures the analog signal and starts the conversion at the end of the sampling period. It digitizes the sampled data within 12 clock cycles. When the end of conversion signal is enabled to be high, it indicates that the data ADCOUT is readable. When the previous data is read, a new conversion cycle can begin. Notice that ADC outputs weighted binary data

A hardware connection:

Connection of 4-wire touch screen

5-wire touchscreen connection

8-wire touchscreen connection

The second Linux driver2.1 configuration uses Device Drivers-- > [*] Staging drivers-- > [*] Industrial I support O support-> [*] Enable buffer support within IIO Industrial I lock free software ring

Industrial I buffering based on kfifo O buffering based on kfifo-*-Enable triggered sampling support (2) Maximum number of consumers per trigger Analog to digital converters-> TI's ADC driver

Here TI's ADC driver is compiled directly into the kernel. If you just want to compile it into a module, you can click the space to change it to

2.2 set up driven platform data (platform_data)

Add the following code to arch/arm/mach-omap2/board-am335xevm.c (my board is board-com335x.c):

# include static struct adc_data am335x_adc_data = {.adc _ channels = 4,}; static struct mfd_tscadc_board tscadc = {.tsc _ init = & am335x_touchscreen_data, .adc _ init = & am335x_adc_data,}

If you want to use adc and touchscreen at the same time, just follow the above settings.

If you only use adc, you want to remove the touchscreen platform data (platform data) as follows:

Static struct adc_data am335x_adc_data = {.adc _ channels = 8,}; / * static struct tsc_data am335x_touchscreen_data = {.wires = 4, .x _ plate_resistance = 200,.clients _ to_configure = 5,}; * / static struct mfd_tscadc_board tscadc = {/ * .tsc _ init = & am335x_touchscreen_data, * / .adc _ init = & am335x_adc_data,} Three tests

Connect the DC voltage to the pin from AIN0 to AIN7 (which pin you use). Be sure to note that the test voltage can only be between 0v and 1.8v.

3.1 View IIO Devic

Root@arago-armv7:~# ls-al / sys/bus/iio/devices/iio\: device0/drwxr-xr-x 5 root root 0 Jan 1 00:00. Drwxr-xr-x 4 root root 0 Jan 1 00:00.. drwxr-xr-x 2 root root 0 Jan 1 00:00 buffer-r--r--r-- 1 root root 4096 Jan 1 00 : 00 dev-r--r--r-- 1 root root 4096 Jan 1 00:00 in_voltage0_raw-r--r--r-- 1 root root 4096 Jan 1 00:00 in_voltage1_raw-r--r--r-- 1 root root 4096 Jan 1 00:00 in_voltage2_raw-r--r--r-- 1 root root 4096 Jan 1 00:00 in_voltage3_raw-r--r--r-- 1 root root 4096 Jan 1 00:00 in_voltage4_raw-r--r--r-- 1 root root 4096 Jan 1 00:00 in_voltage5_raw-r--r--r-- 1 root root 4096 Jan 1 00:00 in_voltage6_raw-r--r--r-- 1 Root root 4096 Jan 1 00:00 in_voltage7_raw-rw-r--r-- 1 root root 4096 Jan 1 00:00 mode-r--r--r-- 1 root root 4096 Jan 1 00:00 namedrwxr-xr-x 2 root root 0 Jan 1 00:00 powerdrwxr-xr-x 2 root root 0 Jan 1 00:00 scan_elementslrwxrwxrwx 1 root root 0 Jan 1 00:00 subsystem->.. /.. / bus/iio-rw-r--r-- 1 root root 4096 Jan 1 00:00 uevent

3.2 single mode

Check the ADC mode, which is the single mode as follows

Cat / sys/bus/iio/devices/iio\: device0/modeoneshot

If it is not a single mode, you can change it using the following command

Echo onesht > / sys/bus/iio/devices/iio\: device0/mode

Read ADC output data from a port:

In_voltageX_raw: raw value of the channel X of the ADC

From the following command, we can see that what is saved in in_voltageX_raw is the raw data of ADC, and 4095 is the full range data.

Root@arago:~# cat / sys/bus/iio/devices/iio\: device0/in_voltage0_ raw40954 calculation result

D = Vin * (2 ^ n-1) / Vref

For example, the data read back from ADC is 2298, then the input voltage is

Vin = D / ((2 ^ n-1) / Vref)

Vin = 2298 / ((2 ^ 12-1) / 1.8)

Vin = 1.01V

Related information:

1 AM335x ADC Driver's Guide http://www.deyisupport.com/question_answer/w/faq/469.am335x-linux.aspx

2 hardware connection and Linux driver of AM335X touch screen

Http://ti.eetop.cn/viewnews-4453

3 Using resistive touch screens for human/machine interface

Http://www.ti.com/lit/an/slyt209a/slyt209a.pdf

Input subsystem

Because the touchscreen uses the input subsystem, we should first explain the input subsystem before we explain the touchscreen. Its core file is input.c.

Structure and function realization of Input Subsystem

1 the Input subsystem is layered, which is divided into three layers: hardware driver layer, subsystem core layer and event processing layer.

(1) the hardware driver layer is responsible for operating specific hardware devices, and the code of this layer is specific to the specific driver and needs to be written by the author of the driver.

(2) the core layer of the subsystem is the link and bridge between the other two layers, providing the interface of the driver layer down and the interface of the event handling layer up.

(3) the event handling layer is responsible for dealing with the user program and reporting the events sent from the hardware driver layer to the user program.

(2) the basic unit of communication between layers is the event, and the action of any input device can be abstracted into an event, such as the press of the keyboard, the press of the touch screen, the movement of the mouse and so on. Events have three attributes: type, code, and value. All events supported by the Input subsystem are defined in input.h, including all supported types, the encoding supported by the type, and so on. The direction of event transmission is hardware driver layer-> subsystem core-- > event processing layer-- > user space.

(3) take the touch screen as an example to illustrate the workflow of the input subsystem:

Note: the module file corresponding to the driver layer of the touchscreen driver of am335x sdk6 is ti_tsc.c, and the module file of event processing layer is evdev.c.

(1) in the initialization function of the ti_tsc module, the touch screen is registered in the input subsystem, and at the same time, the registration function looks for the event handler in the event processing layer linked list, where the evdev is found and the driver is mounted with the event handler. And generate the device file event0 in / dev/input, and when we visit this file, we will find our touchscreen driver.

(2) the application opens the device file / dev/input/event0, reads the device file, and calls read in the evdev module. If there are no events, the process will sleep.

(3) when the touch screen is pressed, the driver layer passes the event (that is, the XQuery Y coordinate, press / release) through the core layer of the input subsystem to the event processing layer, that is, the evdev,evdev wakes up the sleeping process, and passes the event to the process for processing.

Take a look at the code flow below:

Input_init () class_registerregister_chrdev (INPUT_MAJOR, "input", & input_fops); you can see that the input subsystem has written the above two functions for us, so is this input_fops the file_operations we want to fill? static const struct file_operations input_fops = {.owner = THIS_MODULE, .open = input_open_file, .lluminous = noop_llseek,}

This file_operations does not have interfaces such as read/write, so we know that the structure is only a function of connecting the upper and lower layers, which is a hierarchical idea. So he connects the upper and lower layers through open members. Let's take a look at what open members do:

Input_open_file handler = input_ table [iminor (inode) > 5]; / / use this device number to get the handler structure new_fops = fops_get (handler- > fops); / / get the new file_operations file- > f_op = new_fops; / / use the fops member of handler as the new file_operations new_fops- > open (inode, file) / / handler- > fops- > open (indoe, file)

Thus it can be seen that the conversion from the upper input_fops to the underlying real handler- > fops is completed by getting the handler members in the array through the secondary device number.

The underlying handler- > fops- > open (indoe, file) is the real open, and so is the corresponding read/write.

The most important thing now is how did the input_table [] array come from?

Find out that it is used in input_register_handler by looking up the code, so who called this function? Many drivers under the input subsystem use this function. They first find out if there is any hardware that can match, and if so, call this function to put input_handler in the array.

These drivers can be seen in the following software section:

Software part

Evdev.c Joydev.c Keyboard.c Mousedev.c and so on are the input subsystems that register input_handler upwards

Input_register_handler input_attach_handler determines whether the hardware's id_table can match its own id_table, and if so, establish a connection.

Hardware part:

Input_register_device input_attach_handler determines whether the id_table of the software matches its own id_table, and if so, establishes a connection.

Both device and handler look for matches when registering, and if so, call the connect function to connect with each other.

The following takes evdev.c as an example to illustrate how the software and hardware parts establish a connection:

Evdev_connect () evdev- > handle.dev = input_get_device (dev); evdev- > handle.handler = handler

Another handle structure is created in evdev.c, which points to device and handler respectively, so that the hardware and software can find each other through this structure.

Am335x sdk6 touchscreen driver file-arch/arm/mach-omap2/board-com335x.c board-level initialization static struct tsc_data am335x_touchscreen_data = {.wires = 4, / 4-line touchscreen .x _ plate_resistance = 200, / / impedance 200 ohms. Impedance _ to_configure = 5 / / the number of samples in fifo before the interrupt is generated, up to 16} Drivers/input/touchscreen/ti_tsc.c driver file ti_tsc_init platform_driver_register (& ti_tsc_driver); tscadc_probe input_allocate_device / / assign request_irq input_dev- > name = "ti-tsc"; / / set input_dev- > dev.parent = & pdev- > dev; input_dev- > evbit [0] = BIT_MASK (EV_KEY) | BIT_MASK (EV_ABS) / / can generate button events / absolute displacement events input_dev- > Keybit [bit _ WORD (BTN_TOUCH)] = BIT_MASK (BTN_TOUCH); / / Touch screen events input_register_device// registration

Interrupt handling function

Tscadc_interrupt tscadc_readl reads the interrupt status register. Adc and tsc share an interrupt source to determine the cause of the interrupt and then report the event input_report_abs (input_dev, ABS_X, val_x); / / x coordinate input_report_abs (input_dev, ABS_Y, val_y); / / y coordinate input_report_abs (input_dev, ABS_PRESSURE, z) / / pressure-sensitive input_report_key (input_dev, BTN_TOUCH, 1); / / Press / release input_sync (input_dev); check whether the lift interrupt status = tscadc_readl (ts_dev, TSCADC_REG_RAWIRQSTATUS); if (status & TSCADC_IRQENB_PENUP) input_report_key (input_dev, BTN_TOUCH, 0) Input_report_abs (input_dev, ABS_PRESSURE, 0); input_sync (input_dev); at this point, I believe you have a deeper understanding of "how to configure and use Linux driver". You might as well do it in practice! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.