Serial port driver Programming details---Serial port initialization (top)

TTY Driver Architecture:

1. TTY Concept Analysis

1.1/dev/ttysca0

1.2/dev/tty1-n

1.3/dev/console

In a Linux system, a terminal is a type of character device, which consists of many types, usually using a TTY for short-range end devices.

. Serial Terminal (/dev/ttys*)

The serial port terminal is the end device which uses the computer serial port connection. Linux considers each serial port to be a character device. The device name corresponding to these serial ports is/dev/ttysac*;

Console Terminal (/dev/console)

In a Linux system, the output device of a computer is often referred to as the console terminal, where the PRINTK information is exported to the device. /dev/console is a virtual device that needs to be mapped to a real TTY, such as a kernel boot parameter "CONSOLE=TTYSCA0" to map the console to a serial port 0

. Virtual terminal (, dev/tty*)

When the user logs in, the virtual terminal is used. With Ctcl+alt[f1-f6], we can switch to Tty1, Tty2, Tty3, and so on. Tty* is called a virtual terminal, and Tty0 is an alias for the virtual terminal that is currently being used.

2. TTY Architecture Analysis

The following is a backtracking function from the kernel code to verify the above image of the TTY schema function call Relationship!

The function that corresponds to the first Red arrow is the Driver_write ()

Second Red Arrow part: add a dump_stack function to the function to save and recompile the kernel

download to the Development Board via TFTP the boot kernel will see the serial terminal print out this function call backtracking information!

The computer is in childbirth today! Compile the kernel for a long time, a few minutes before the fix!

The board starts the kernel and then DMESG commands to view the back-printed information (why not print directly to the serial port for DMESG and PRINTK print levels)

Here print more, carefully look at actually all is repeating here I inside of a copy paste down:

[<c049c7c0>] (dump_stack+0x18/0x1c) from [<c0237670>] (s3c24xx_serial_start_tx+0x14/0xb4) [<c0237670>] (s3c24xx_ SERIAL_START_TX+0X14/0XB4) from [<c023374c>] (uart_start+0x64/0x68) [<c023374c>] (uart_start+0x64/0x68) from [<c0234cb4>] (uart_write+0xc0/0xe4) [<c0234cb4>] (uart_write+0xc0/0xe4) from [<c021dd84>] (do_ OUTPUT_CHAR+0X16C/0X1D8) [<c021dd84>] (do_output_char+0x16c/0x1d8) from [<c021de28>] (process_output+ 0X38/0X54) [<c021de28>] (process_output+0x38/0x54) from [<c021e978>] (n_tty_write+0x204/0x444) [< C021e978>] (n_tty_write+0x204/0x444) from [<c021b808>] (tty_write+0x14c/0x244) [<c021b808>] (tty_ write+0x14c/0x244) from [<c021b958>] (redirected_tty_write+0x58/0x68) [<c021b958>] (redirected_tty_ write+0x58/0x68) from [<c00e5ca4>] (vfs_write+0xbc/0x150) [<c00e5ca4>] (vfs_write+0xbc/0x150) from [< C00e5e14>] (sys_write+0x44/0x74) [<c00e5e14>] (sys_write+0x44/0x74) from [<c002fb40>] (ret_fast_syscall+0x0/0x30) 

The above diagram shows a layer-by-level invocation of each function, versus the schema analysis diagram above. (This is where the architecture map is pasted up)

This function dump_stack () function is very powerful! (If you can make a graphical interface directly display the following graphic structure is the inverse of the sky)

The above is a function N_tty_write function is actually the write! in the line procedure

The following first analysis of serial port initialization: first

The kernel of 2440, 6410 of the serial port part is used s3c24xx. This function, the internal implementation is similar, must be the kernel driver lazy!

initialization of serial port driver analysis :

Summary of the most important of the four jobs: serial port initialization, serial port open, serial read operation, serial port write operation

Kernel code inside the most important and serial port related files One is samsung.c, one is s3c6400.c

1. Serial Driver structure

Look at the figure below ( 2. Important data structure in the string the Analysis flowchart ): The first user-space write serial function to find the corresponding data structure in the kernel

Here you can see the write function of the user space corresponding to the tty_write in file_operations, there are some other common functions

Continue to follow the figure below to see tty_write corresponding to the line code in the Tty_ldisc_ops function:

You can also find the OPS data structure of the line discipline from the kernel code:

This concludes that the write function of the user space invokes the tty-write of the system call interface, and then Tty-write calls the N_tty_write in the line discipline.

Or the following diagram to continue the analysis, you can see N_tty_write will call Tty_operations inside the function, kernel code in the N_tty_write function is a bit long, here are two images truncated:

Here's a look at the tty_operations structure definition:

From this can be seen n_tty_write and corresponding to the Uart_write function here! What a great trouble to jump and jump! It feels like a routine!

Below or continue to analyze uart_write, the same can be seen from the following figure Uart_write and corresponding to the drive inside the Write function:

There are several important data structures: The second third arrow points to the section: Here you can see from the struct uart_state structure to get the port port number Uart_port, and then jump to the Uart_start (TTY) function:

Continue to jump:

You can see that this function jumps through the port structure into the OPS function! In fact, Port is the uart_ops data structure type! The graph above can function in this data structure has a lot of function pointers! You can then use these function pointers to manipulate the hardware in the drive layer!

The above should pay special attention to the struct UART_STATE data structure, the above line of code deduction out analysis:

struct Uart_state *state = tty->driver_data;

You can see that this data structure is from the driver_data of the TTY, then how does this data structure put into the driver_data inside? This is done in the Uart_open function:

From the function above you can see from the Uart_open function to get the state and then put the state into the TTY Driver_data (void* type) structure.

The following continues to analyze how state is obtained:

From the sourceinsight, you can see that state is obtained from the data structure of the driver uart_state:

The above analysis of so many actually summarize the most important data structure of the inclusion relationship can be summarized as follows:

uart_driver ------> uart_state ------> uart_port ------> uart_ops

2. Important data structures in the serial drive

The first step of the serial port call process is based on the following diagram to analyze, the previous step is described in this picture below

3. Initialization analysis

The usual, from the original kernel source code to start analysis! Re-build the wheels!

Open samsung.c in SI

Module_init (S3c24xx_serial_modinit); Module_exit (S3c24xx_serial_modexit);

Jump to module initialization function Code section:

Here you can see that in the Module initialization section using the uart_register_driver function to register a serial port driver, the following to see the type of function parameters:

Combine the first step of the above analysis and the second step of the flowchart to see if it is much clearer! (The analysis here is also in contrast to the above flowchart)

The following is an analysis of module initialization in the S3C6400.C file:

Continue to jump:

You can see that this function also calls the platform-driven registration function (in detail in the previous blog post), the platform bus will be the platform driver and the platform device in our system to match one by one, if there is a match, he will call platform-driven probe function

Jump to jump to jump to this:

Here is a detailed analysis of the above functions:

First look at the place where the first arrow refers, and look at the structure:

This array is all stored in Uart_port's serial port information.

The serial initialization function is then called:

<span style= "color: #ff0000;" >ret = S3c24xx_serial_init_port (ourport, info, dev);</span>

Function comparison Long here is a two-piece graph, you can see this function is to do some initialization work! One of the more important is the red arrow in the point, the first one line is the base site initialization , where the use of static mapping (Linux at the start of the relationship between the physical address and the virtual address map)! Take the virtual address, take the interrupt number, reset the FIFO

Jump back and continue analyzing the probe function:

Take a look at the function that the first arrow points to, which basically establishes the connection between Uart_driver and Uart_port:

/** *uart_add_one_port-attach a driver-defined port structure * @drv: Pointer to the "UART low" driver structure for This port * @uport: The UART port structure to the use for this port.  * *this allows the driver to register its own uart_port structure *with the core driver. The main purpose is to allow the low *level UART drivers to expand Uart_port, rather than have yet *more levels of Struc Tures. */int uart_add_one_port (struct uart_driver *drv, struct uart_port *uport) {struct uart_state *state;struct tty_port *port ; int ret = 0;struct device *tty_dev; Bug_on (In_interrupt ()); if (Uport->line >= drv->nr) return-einval;state = drv->state + Uport->line;port = &state->port;mutex_lock (&port_mutex); Mutex_lock (&port->mutex); if (state->uart_port) {ret =- Einval;goto out;} State->uart_port = Uport;state->pm_state = -1;uport->cons = Drv->cons;uport->state = state;/* * If this por T is a console and then the spinlock is already * initialised. */IF (! ( UaRt_console (Uport) && (Uport->cons->flags & con_enabled)) {spin_lock_init (&uport->lock); Lockdep_set_class (&uport->lock, &port_lock_key);}  Uart_configure_port (DRV, State, uport);/* Register the Port whether it ' s detected or not. This allows * setserial to is used to alter this ports parameters. */tty_dev = Tty_register_device (Drv->tty_driver, Uport->line, Uport->dev); if (likely (!IS_ERR)) { Device_init_wakeup (Tty_dev, 1);d evice_set_wakeup_enable (Tty_dev, 0);} ELSEPRINTK (kern_err "Cannot register TTY device on line%d\n", uport->line);/* * Ensure Upf_dead is not set. */uport->flags &= ~upf_dead; Out:mutex_unlock (&port->mutex); Mutex_unlock (&port_mutex); return ret;}

ret = Device_create_file (&dev->dev, &dev_attr_clock_source);Create property file This driver will use the

Installation driver The serial port information we see in the/sys/directory is what this function implements:

It's a very, very, very, very well-set.

Here this function temporarily jumps to this! Heart Tired! It's endless! Take care of the big picture First!

ret = S3c24xx_serial_cpufreq_register (ourport);//Dynamic frequency adjustment function

Is the routine, here for the moment as long as know and CPU related on the line, temporarily let go!

Here's another one. Serial Port initialization Analysis Flowchart:

So far the entire serial port initialization process has been analyzed! Kernel code is really not that simple!

The platform bus driver is registered first, then the platform bus driver matches the platform device, the probe function is called when the match is made, and then the probe function performs some initialization work!

The next article begins to analyze the edge code! Four-step strategy: Serial port initialization, open serial port, serial port write operation, serial read operation

Serial port driver Programming details---Serial port initialization (top)