Android display Architecture Analysis 8-display development experience

1. Add the work content of the new display driver.

Refer to the software architecture of the FB device in Linux above. You can know that to add a new mddi interface LCM, the driver's job is to provide its own mddi_xxxx.c (in this porting process, to save time, we directly modified mddi_toshiba.c) and initialized the HWR related to the LCD. Main tasks include:

A. initialize the I/O and power supplies related to the LCD/LCD backlight;

B. Compile the initialization function. It is mainly to initialize the LCD controller, which is generally provided by LCD manufacturers. Then, the memory is allocated. The code from the Qualcomm release already contains this action. Finally, it initializes a structure of fb_info, here, we mainly register some LCD information.

C. register the LCD device and driver in the system. (There are not many modifications because the existing driver is replaced .)

For the preceding section B and C code, see kernel \ drivers \ video \ MSM \ mddi_toshiba.c.

2 display driver development process 1.2.1 configure power and IO

Modify some gpio configurations and some power level configurations. Then, make sure that the signal is normal through actual measurement:

A. Power Supply for LCD and mddi bridge;

B. mddi bridge and LCD reset signal;

C. The gpio of the control backlight IC works normally (the backlight is not turned on and the LCD cannot be debugged ).

1.2.2porting LCD initialization sequence

The LCD init code and the initialization code of the peripheral mddi bridge can be obtained in the code base of Boston Windows Mobile system; this part of code is transplanted to mddi_toshiba.c, the corresponding image format, resolution, and other configurations are modified and compiled. The LCD Initialization is basically complete.

1.2.3lcd initialization process debugging

Since the hardware can work in Boston load before, it can be considered that the hardware connection is no problem, so you only need to pay attention to the software part.

The display software debugging process is as follows:

A. After the service is started, check whether gpio is configured as expected in the Code (ensure that

The gpio interface works normally );

B. Check whether each power supply is in the level value defined in the Code. After these are OK, Backlight

Yes (backlight control is relatively simple, just a gpio );

C. If the LCD and mddi bridge are properly initialized at this time, the screen will

See. If the screen is not displayed, use JTAG to check whether the initialization function in mddi_toshiba.c has been called during startup.

In the current version, the driver module to be loaded is determined based on the vendor number read in the peripheral mddi bridge. During this debugging, the bootloader can correctly read the manufacturer's ID, so the initialization of the LCD in the bootloader is done, so the status displayed on the screen is what the LCD looks like after initialization (flat screen).
But after the kernel is up, there is no other display. After the JTAG is followed, it is found that the correct vendor ID cannot be read in module init in the kernel, so the driver behind it is not loaded. Then we find that if the mddi bridge Initialization is not performed in the bootloader, the module init will run normally, this issue has not been clarified yet (now init disable in bootloader is removed first ).

1.2.4lcd Adjustment

After the initialization is normal, the UI-related screen is displayed, but the obvious color and position are incorrect.

This may be caused by incorrect data type configuration, that is, the MDP output type and the mddi configuration type are,The LCD reception type does not match, or the RGB sequence is incorrect (It can be configured as BGR ). After debugging, the MDP output format is configured as rgb565, and the peripheral mddi bridge and LCD input format are also configured as rgb565. The color is normal.

If the position or direction is incorrect, for example, up or down, you can change the Scanning direction in the LCD configuration.

1.2.5 others

Later I found a problem. The color of the video is black and white.

This problem is easy to misunderstand. According to our normal understanding, the data produced by video decode is YCbCr, Y is the brightness signal, and cbcr is the chromatic aberration signal, if only the Y signal is available, the color should be black and white. Therefore, there are two suspected points: one is that the data from deCODE is incorrect, and the other is that mddi bridge mistakenly uses the input YCbCr signal as the RGB signal, which is also possible. But soon the second suspect was ruled out (because the problem still cannot be solved after the mddi input format is changed ).

Later, I read the code of the display part in detail and used the JTAG to track the display interface used for video playback. I found that the output formats of all the Display Interfaces are RGB, that is to say, YCbCr has been converted before MDP, while the Conversion Function in MDP is not used. MDP is simply used as a DMA for direct data transmission, which is called bypasse in this document.

The conversion from YCbCr to RGB is completed by the android Lib. A sr was sent to Qualcomm, and Qualcomm's reply was also confirmed. In 6.3.50, this lib (copybit. default. so), 6.3.60 and later versions have solved this problem.