DVI driver development in high-definition embedded systems

Introduction
DVI is the abbreviation of Digital Visual Interface. In the field of embedded electronics, high-definition interfaces such as DVI are increasingly used. Many embedded products use H.264 video encoding technology to support the playback of 720P resolution video files in H.264 format, which requires a display output device with at least 1024×768 resolution.
MX51 is a high-end ARM embedded multimedia processor based on the ARM Cortex-A8 core of Freescale Semiconductor. It supports hard decoding of 720P video in multiple formats and can be used to develop high-definition set-top boxes, netbooks and other products. In many cases, high-definition video terminals such as DVI need to be integrated.
In embedded electronic products, the Linux operating system occupies an increasing market share. This article uses the Linux 2.6.28 kernel and MX51 as the system's software and hardware platform, and discusses in detail the method of developing a DVI display driver based on framebuffer technology.

1 DVI Overview
The DVI interface can only be seen on some high-end monitors, and common LCD monitors only have VGA interfaces. The VGA interface displays analog signals, while the DVI interface displays digital signals. It transmits uncompressed digital signals with a maximum rate of 4.9 Gbps, which can achieve good fidelity for high-definition video display and reduce signal loss during analog signal transmission.
DVI transmits digital signals based on TMDS (Transition Minimized Differential Signaling) technology. TMDS uses advanced encoding algorithms to convert 8-bit data (each base color signal in R, G, B) into 10-bit data (including line field synchronization information, clock information, data DE, error correction, etc.) through minimum conversion. After DC balance, differential signals are used to transmit data. Compared with LVDS and TTL, DVI has better electromagnetic compatibility performance and can use low-cost dedicated cables to achieve long-distance, high-quality digital signal transmission.

2 Hardware interface
The hardware platform used in this design is based on the MX51 multimedia application processor development board of Freescale Semiconductor. The processor integrates a variety of peripheral interfaces, including two liquid crystal display controllers (LCDC) and their interfaces, which can connect various types of LCDs with a maximum resolution of 1280×800 pixels. Through the LCD1 interface of MX51, the TFP410 chip of Texas Instruments is expanded to realize DVI video output. The high-definition 720P video decoding capability of MX51 requires a display output device with a larger resolution. Figure 1 shows the connection diagram between the LCD1 interface of MX51 and TFP410.

The TX2±, TX1±, TX0±, and TXC± signals in Figure 1 are 4 pairs of DVI video output signals, 8 signals. DATA[23:0] is the video data input signal, corresponding to DATA[23:0] of MX51 LCD1; clock signals such as DE, VSYNC, HSYNC, and IDCK± correspond to the corresponding pins of LCD1. SCL and SDA are the I2C bus clock and data signals, connected to the two pins of the MX51 I2C interface. The above hardware circuit connection can realize the MX51 output of high-definition video to the DVI chip, and then display it through an external LCD. The LCD controller integrated in the MX51 processor includes the following main registers:
①LSSAR register. Set the first address of the display buffer.
②LSR register. Set the size of the display buffer.
③LPCR register. Set the pixel clock frequency PCD, the synchronous clock polarity FB_SYNC_CLK_INVERT, the OE signal polarity FB_SYNC_OE_ACT_HIGH, the vertical signal clock polarity FB_SYNC_VERT_HIGH_ACT, and the horizontal signal clock polarity FB_SYNC_HOR_HIGH_ACT.
④LHCR register. Set the hsync_len, left_margin, and right_margin of the line synchronization signal.
⑤LVCR register. Set the vsync_len, upper_margin, and lower_margin of the frame synchronization signal.
⑥LPCCR register. Set the display brightness of the screen. The lower 8 bits of LPCCR control the high-level duty cycle of the PWM pulse, and the adjustment range is 0x00~0xFF.

3 Linux frame buffer device
3.1 Framebuffer mechanism
Framebuffer is a driver interface that appears in Linux kernel versions after 2.2.xx. In the Linux system, it is located between the upper-level application and the lower-level display device. Framebuffer shields the differences between different display devices and abstracts the display device into a frame buffer. It is an abstract device for user mode to directly write to the screen. Framebuffer
can regarded as an image of video memory. After the user maps it to the address space of the process through memory mapping, the screen output of the LCD can be directly controlled by reading and writing operations on the display buffer.
The framebuffer device driver is mainly based on the two files linux/include/linux/fb.h and linux/drivers/video/fbmem.c. fb.h contains important data structures related to the framebuffer device. fbmem.c is the core program of the framebuffer mechanism, which provides a general interface for upper-level applications and also provides an interface for lower-level specific hardware. The functions in it can operate specific hardware, such as setting registers and mapping display buffers.
3.2 Several important data structures
(1) struct fb_info
This structure is the driver layer interface defined by Linux for the frame buffer device. It contains a complete description of the properties and operations of the frame buffer device. Some of its members are defined as follows:

Among them, var records the display controller parameters that can be modified by the user, including the screen resolution and the bit width of each pixel; fix records the display controller parameters that cannot be modified by the user; cmap is the current color table; fbops points to the function set for the underlying hardware operation; dev represents the frame buffer device; screen_base is the virtual base address of the I/O mapping.
(2) struct fb_ops
This structure provides function pointers to the underlying operations. Its member functions ultimately interact with the LCD controller hardware. These functions need to be designed by the driver developer according to the hardware settings of the LCD controller and the hardware parameters of the LCD display. Some of the members of this structure are defined as follows:

Among them, fb_check_var is used to check the variable screen parameters and adjust them to the values ​​supported by the hardware; fb_set_par sets the specific read and write registers of the LCD controller according to the screen parameters to enable it to enter the corresponding working state, and fb_setcolreg sets the color register to implement the filling of the pseudo color table and the color table.
(3)struct fb_var_screeninfo
This is a member structure of fb_info. It records the modifiable information of the frame buffer device and the specified display mode, including screen resolution, bit width of each pixel, frame delay, line delay, etc.
(4)struct fb_fix_screeninfo
This is a member structure of fb_info. It describes the properties of the display card and cannot be modified while the system is running, such as the first address and length of the buffer. When a mode is set, the memory information is given by the display card hardware, and the location of the memory and other information cannot be modified.
MX51 embeds the LCD controller directly into the processor chip, which provides a direct interface for the expansion of the display function of the embedded system. The LCD controller driver is the core of the DVI device driver, which is a standard framebuffer device driver. When designing a driver, the first thing is to configure the LCD controller and set the frame buffer, which depends largely on the above data structure. The driver design needs to fill in the relevant structure and complete the interface function specified by the system. [page]

4 DVI driver design
4.1 Platform driver
A new driver management and registration mechanism has been introduced since Linux 2.6: platform_device and platform_driver.
Devices are represented by platform_device, and drivers are registered with platform_driver. Platform devices include port-based devices, peripheral buses, and most controllers integrated in the system-on-chip, as independent hardware modules on the MX51 chip. The LCD controller is a platform device, so the driver design must include a platform driver. The task of the platform driver is to register the devices used with the system, including the LCD controller of the MX51 and the TFP410 DVI video output chip, so that when the device driver is loaded, it can query the system to see whether the corresponding device is registered, and then execute the probe function in the device driver.
In arch/arm/mach-mx51/rex51_3stack.C, the platform_device structure variables mxc_fb_device and i2c_board_info are not set. The structure variable mxc_i2cl_ board_info defines the LCD controller and TFP410 devices.
Call the functions platform_device_register(＆mxc_fb_device) and i2c_register_board_info(1, mxc_i2cl_board_info, ARRAY_SIZE(mxc_i2cl_ board_info)) to register the above devices with the system.
4.2 Device Driver
4.2.1 LCD Controller Driver
The LCD controller driver is a standard frame buffer device driver. First, define the global structure variable mxcfb_driver in drivers/video/mxc/mxc_ipuv3_fb.c:

Then, call platform_driver_register(＆mxcfb_driver) in the driver entry function mxcfb_init(void) to register the driver. When the driver is loaded successfully, the detection function mxcfb_probe will be automatically called.
mxcfb_probe is an important function in driver design. It is mainly responsible for initializing the hardware. Applying for interrupts, allocating memory required for framebuffer, registering framebuffer devices, etc. The following are operations related to framebuffer.
①Call the mxcfb_init_fbinfo(&pdev->dev, &mxcfb_ops) function, and allocate the required space for the mx51 frame buffer information structure struct mxcfb_info through the framebuffer_alloc function. The definition of the parameter mxcfb_ops is as follows:

mxcfb_ops defines a series of functions pointing to the underlying operations. These functions are for MX51 frame buffer operations and are the specific implementation of the framebuffer core driver operations.

② Initialize the fixed and variable parameters of the frame buffer information structure fb_info, and fill in the fb_var_screeninfo var and fb_fix_screeninfo fix members.
Define fbi as a pointer of struct fb_info type, and assign the defined file operation interface mxcfb_ops to the fbops member of the fb-info structure through the statement fbi->fbops=＆mxcfb_ops.
Call the mxcfb_check_var(＆fbi->var, fbi) function to check and adjust the value of the variable var in the fb_info structure. var is a variable of struct fb_var_screeninfo type, which represents the display controller parameters, in which information related to the display output status, such as screen resolution, will be set in the subsequent DVI driver.
Call the mxcfb_set_fix(fbi) function to fill in a struct fb_fix_screeninfo structure variable fbi->fix, which describes the properties of the display output device itself.
③ Call register_framebuffer(fbi) function to register the frame buffer driver. This function has only one parameter, which is the pointer fbi pointing to the struct fb_info structure defined above.
4.2.2 DVI device driver
The LCD controller uses the DVI chip as the display peripheral it is connected to. After completing the LCD controller driver, you also need to write a DVI device driver. In the file drivers/video/mxc/mxcfb_dvi. c:

Then, in the peripheral driver entry function dvi_init(void), platform_driver_regtster(＆dvi_driver) is called to register the DVI driver. After the driver is loaded, the system automatically calls the detection function dvi_probe, which mainly implements the following operations: First, specify the framebuffer device. Since the MX51IPU (image processing unit) supports multiple framebuffer devices, it is necessary to determine which device of the Mx51 IPU framebuffer DVI uses; second, fill in the fb_var_screeninfo structure variable var with information about the display output status, such as the screen display resolution, picture position, etc. For this purpose, the structure array video_modes is defined in the program: the

structure struct fb_videomode is used to describe the display output status, and the function "fb_videomode_to_var(＆var, &video_modes[0])" is called to convert the screen display parameters into the relevant members of the var structure variable. Since some member values ​​of var have been determined in the previous LCD controller driver, the setting of all members of var is completed here.
A frambuffer device is represented by a struct fb_info structure. This design uses the global variable regtstered_fb of the fb_info structure to represent the frambuffer device registered by the system. One of the main tasks of the driver is to fill this structure variable. The information transmission between the LCD controller driver and the DVI peripheral driver is realized through this global variable.

5 DVI driver test
First, test whether the DVI output is normal by displaying a picture. Use a conversion tool (such as Image21cd) to convert a 1024×768 jpg picture into a binary picture in RGB format with RGB 888 resolution and 1024x 768. Then type the command: cp pic. bin/dev/fb0, and the picture will be displayed on the screen. Next, use the MX51 video decoding test program to play a 720P video H. 264 file. You can see that the video playback is clear and smooth, and the effect is very good.

Conclusion
After testing, the DVI driver has been successfully implemented on the MX51 platform. Framebuffer is an interface directly facing the display buffer provided by Linux to users. This design is an application-oriented framebuffer driver. The article gives the overall architecture of the DVI driver and introduces the design ideas and implementation methods of the main modules in detail.