This article describes how to implement Modular programming of the LCD driver and how to load the driver into the system kernel statically Based on Samsung's arm9-series embedded processor S3C2410.
This article describes how to develop Embedded LCD drivers on the Linux platform based on the LCD interface of Samsung's kernel chip S3C2410.
The hardware in this article uses the Samsung S3C2410 chip Development Board, the software uses the Linux 2.4.19 platform, the compiler is the arm-Linux-GCC cross compiler, using a 640 × 480 resolution TFT color LCD, by Rewriting and debugging the Linux driver, the driver and display of the screen are successfully realized.
Concept of embedded driver
The device driver is the interface between the operating system kernel and the hardware of the machine. The device driver shields the hardware details from the application. In this way, the hardware device is just a device file, applications can operate on hardware devices like normal files. The device driver is a part of the kernel. It provides the following functions: Initialize and release the device, transfer data from the kernel to the hardware, and read data from the hardware; read the data that the application sends to the device file, send back the data requested by the application, and detect and process device errors.
Linux classifies devices into two basic categories: character devices and Block devices. The main difference between a character device and a block device is that when a read/write request is sent to a character device, the actual hardware I/O usually follows. Character devices perform sequential read/write operations in a single byte, without using the buffer technology. Block devices store and read/write data blocks of a fixed size, such as hard disks and floppy disks, A system memory is used as the buffer. To improve efficiency, the system provides a caching mechanism for block device read/write. The implementation is much more complex than that of character devices due to issues such as buffer management, scheduling, and synchronization. LCD is accessed and managed by character devices. Linux regards the display driver as a character device and sends the data to be displayed in one byte to the LCD driver.
Linux device management is closely integrated with the file system. Various devices are stored in the/dev directory as files, which are called device files. Applications can open, close, and read/write these device files to complete operations on the device, just like operating a common data file. To manage these devices, the system numbers the devices. Each device number is divided into the primary device number and secondary device number. The primary device number is used to distinguish different types of devices, while the secondary device number is used to distinguish multiple devices of the same type. For common devices, Linux has a conventional number, for example, the master device Number of the hard disk is 3. Linux provides a unified operation function interface for all device files by using the data structure struct file_operations. This data structure includes the pointers of many operation functions, such as open (), close (), read (), and write (). However, due to the many types of peripherals, the operation methods are different. The members in the struct file_operations struct are a series of interface functions, such as the read/write function for read/write and IOCTL for control. To open a file, call the open operation in file_operations. Different types of files have different file_operations member functions, such as common disk data files and interface functions to complete disk data block read/write operations. For various device files, then, I/O functions in the respective drivers are called to perform operations on specific devices. In this way, applications do not have to consider devices or common files. They can be processed as files with clear and unified I/O interfaces. Therefore, file_operations is an I/O interface at the file level.
LCD Controller
The function of the LCD controller is to display the driving signal and then drive the LCD. You only need to read and write a series of registers to complete the configuration and display driver. In the process of driving the LCD design, the first step is to configure the LCD controller, and the most important step in the configuration of the LCD controller is the designation of the frame buffer. The content to be displayed is read from the buffer and displayed on the screen. The size of the frame buffer is determined by the screen resolution and the number of colors displayed. The implementation of driving frame buffering is the focus of the entire driving development process. The LCD controller in S3C2410 supports two types of Liquid Crystal: STN and TFT. The LCD Controller supports four-digit dual-scan, four-digit single-scan, and eight-digit single-scan display modes for an stn LCD Panel. It supports four-level and 16-level gray-level monochrome display modes, supports 256-color and 4096-color display, and supports LCD with multiple resolutions, such as 640x480, 320x240, and 160x160. In the 256-color display mode, the maximum value is 4096x1024, 2048x2048, and 1024x4096. The tft LCD Panel supports 1-2-4-8bpp (bits per pixel) color palette display mode and 16 BPP non-color palette display.
The frame buffer is a driver interface that appears in Linux 2.2.xx and later kernel versions. This interface will show that the device is abstracted as the frame buffer device zone. The frame buffer Provides abstract processing for image hardware devices. It represents some video hardware devices that allow application software to access image hardware devices through a clearly defined interface. In this way, the software does not need to know anything that involves underlying hardware drivers (such as hardware registers ). It allows upper-layer applications to directly read and write the display buffer and perform I/O Control in graphic mode. You can use a dedicated device node to access this device, such as/dev/FB *. You can think of it as an image showing the memory. After you map it to the process address space, you can perform read/write operations, and the read/write operations can be reflected in the LCD.
The device file corresponding to the frame buffer device is/dev/FB *. If the system has multiple video cards, Linux also supports multiple frame buffering devices, up to 32, that is,/dev/fb0 ~ /Dev/fb31. /Dev/FB points to the current frame buffer device. Generally, the default frame buffer device is/dev/fb0.
The frame buffer device is also a character device, using the "file layer-driver layer" interface method. The following data structure is defined at the file layer.
Static struct file_operations fb_fops = {
Ower: this_module,
Read: fb_read,/* read operation */
Write: fb_write,/* write operation */
Ioct1: fb_ioct1,/* I/O operations */
MMAP: fb_mmap,/* ing operation */
Open: fb_open,/* open operation */
Release: fb_release,/* close operation */
}
Its member functions are defined in Linux/driver/Video/fbmem. C. The functions perform operations on specific hardware, set registers, and map display buffering. The main struct is as follows.
● Struct fb_fix_screeninfo: records the unchangeable information of the frame buffer device and the specified display mode. It contains the physical address and length of the screen buffer.
● Struct fb_var_screeninfo: records the modifiable information of the frame buffer device and the specified display mode. It includes the resolution of the display screen, the number of bits per pixel, and some time series variables. The variable xres defines the number of workers for a row on the screen, yres defines the number of workers for a column on the screen, and bits_per_pixel defines how many bits are used for each pixel.
● Struct fb_info: Linux is the driver layer interface defined by the frame buffer device. It not only contains underlying functions, but also records device status data. Each frame buffer device corresponds to an fb_info structure. The member variable modename is the device name, fontname is the display font, and fbops is the pointer to the underlying function.
LCD driver development
1. Compile the initialization Function
The initialization function first initializes the LCD controller, sets the display mode and number of colors by writing registers, and then allocates the LCD display buffer. In Linux, you can use the kmalloc () function to allocate continuous space. Buffer size: Number of dot matrix lines X number of dot matrix columns X indicates the number of bits/8 in one pixel. The buffer is usually allocated in a large volume of off-chip SDRAM, and the starting address is stored in the LCD control register. The LCD display method used in this article is 640x480, 16-bit color, the display buffer to be allocated is 640x480x2 = 600kb. Finally, initialize an fb_info structure, fill in the member variables, and call register_framebuffer (& fb_info) to register fb_info into the kernel.
2. Compile member functions
Compile the member functions corresponding to the function pointer fb_ops in the fb_info structure. For simple implementation of the embedded system, you only need the following three functions.
Struct fb_ops {
......
INT (* fb_get_fix) (struct fb_fix_screeninfo * Fix, int con, struct fb_info * info );
INT (* fb_get_var) (struct fb_var_screeninfo * var, int con, struct fb_info * info );
INT (* fb_set_var) (struct fb_var_screeninfo * var, int con, struct fb_info * info );
......
}
Struct fb_ops is defined in include/Linux/FB. h. These functions are used to set/obtain the member variables in the fb_info structure. When the application performs the ioctl operation on the device files, it will call them. For fb_get_fix (), the application imports the fb_fix_screeninfo structure and assigns values to its member variables in the function, mainly smem_start (buffer start address) and smem_len (buffer length ), finally, it is returned to the application. The input parameter of the fb_set_var () function is fb_var_screeninfo. The function must assign values to xres, yres, and bits_per_pixel.
For/dev/FB, you can perform the following operations on the display device.
● Read/write/dev/FB: it is equivalent to the read/write screen buffer.
● Map operation: since Linux is working in protection mode, each application has its own virtual address space, so it cannot directly access the physical buffer address in the application. Therefore, Linux provides the MMAP function in the file_operations structure for file operations, which can map the file content to the user space. For frame buffer devices, you can map the physical address of the screen buffer to a virtual address in the user space, then, the user can access the screen buffer by reading and writing the virtual address, and draw a picture on the screen.
● I/O Control: For frame buffering devices, IOCTL operations on device files can be performed to read/set display device and screen parameters, such as resolution, number of display colors, and screen size. IOCTL operations are performed by the underlying driver. In the application, the general steps for operating/dev/FB are as follows: Open the/dev/FB device file; Use ioctrl to obtain the parameters of the current display screen, for example, the screen resolution and the number of bits per pixel can be calculated based on the screen parameters. The screen buffer can be mapped to the user space. After the ing, the screen buffer can be read and written directly, drawing and image display.
LCD modular drive
When compiling a modular driver for the LCD of S3C2410, you must first remove the LCD Driver from the kernel. Here we need to make some changes. The system call is added to the following files and should be removed:/root/usr/src/ARM/Linux/kernel/sys. c;/root/usr/src/ARM/Linux/include/unistd under arm-arm. H and LCD. h;/root/usr/src/ARM/Linux/ARCH/ARM/kernel. s.
Write a modular driver with the following key functions.
● LCD _kernel_init (void) // executed when the module is loaded
● LCD _kernel_exit (void) // executed when the module is removed from the kernel space
● LCD _kernel1_ioctl (struct * inode, struct * file, unsigned int cmd, unsigned longarg) // other functions
Whenever a device driver is assembled, the system automatically calls the initialization module LCD _kernel_init (void ).
Another function that must be provided is LCD _kernel_exit (void). It is called when the module is detached and is responsible for the work of the device driver.
Run the insmod LCD. O command to add the LCD driver to the kernel. Run the rmmod LCD command to delete the LCD Driver from the kernel.
Statically loaded LCD Driver
Compile the LCD Driver LCD. c. Put it in the arm/Linux/Drivers/Char directory and modify ARM/Linux/Drivers/Char/config. in file, add a line: bool ''LCD driver support'' config _ LCD; modify the ARM/Linux/Drivers/Char/MAKEFILE file, and add a line: obj-$ (config_ LCD) + = LCD. o.
In this way, when making xconfig, you will choose whether to compile the LCD driver into the kernel. The same method can be used on other devices.
First, my board uses the ch7005 to convert the LCD signal to VGA. The 2.4 kernel provides a driver, and the display effect is small. People on the Internet said that as long as the LCD is driven up, it can be displayed, and someone like me, it is displayed successfully.
Now my porting process is as follows: ARCH/ARM/mach-s3c2410/mach-smdk2410.c
Static struct s3c2410fb_mach_info smdk2410_ LCD _platdata = {
. Fixed_syncs = 0,
. Width = 640,
. Size = 480,
. Xres = {
. Defval = 640,
. Min = 640,
. Max = 640,
},
. Yres = {
. Defval = 480,
. Min = 480,
. Max = 480,
},
. Bpp = {
. Defval = 16,
. Min = 16,
. Max = 16,
},
. Regs = {
. Lcdcon1 = s3c2410_lcdcon0000tft16bpp | s3c2410_lcdcon0000tft | s3c2410_lcdcon0000clkval (1 ),
. Lcdcon2 = s3c2410_lcdcon2_vbpd (25) | s3c2410_lcdcon2_vfpd (5) | s3c2410_lcdcon2_vspw (1 ),
References: http://www.helloeda.com/Article/deembed/200612/55.html
| LCD Driver transplant notes | ||
| Author: Tag Source: csdn clicks: 37652 updated on: 2006-12-9 |
||
|
LCD driver to kernel 2.6.11 1. Download the Linux kernel source code from the Internet to the local machine and decompress it: Graphics support ---> |
||
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
