Linux Kernel-based omap3530 LCD screen driver debugging note

Background:

The company wants
The omap3530 platform is currently in the technical investigation stage. One requirement is to change the existing 3-inch LCD screen to a 7-inch screen.

Problem:

We use
It is the Development Board provided by ruitai. The Development Documentation provides an introduction to screen usage. According to the kernel compilation options provided in the document, find the corresponding LCD screen driver file and set the parameters. No effect is found (most obvious
A parameter of is the clock frequency. After modification, the screen should be displayed. In fact, it is still displayed normally ).

Solution Process:

1. Change the parameters to a random test. The test has no effect and you are suspected to have modified the error message.
.

2. Cancel the registration from the module to the DSS system. If the screen turns black, the modified file still works.

3. Ask for technical support from ruitai. no useful information is available.
Answer: give up the right to use the technical support inquiry.

4. Find people with experience in this field in the OMAP Technical Group and provide reference. experienced people say that modifying the parameters of the file will take effect.
.

5. Online kernel adjustment and trackingCodeTry. As a result, online debugging is very troublesome. if the environment is unavailable for half a day, the solution is abandoned.

6. Use the oldest log
Method. The output of debugging information is displayed in the relevant area. With sourceinsigh, you can view the code calling process and locate the problem.

Cause:

When the kernel is started, the omapfb module is introduced with the display Setting Parameter 470 × 272mr-16 @ 60. The display subsystem (DSS) parses this parameter and
Panel-> timings finished products are assigned values, and the value of this Member is set in the driver file mentioned in the document. Therefore, no matter how you modify the parameters in the file, the system can display
.

Solution:

Modify resolution parameters and assign values to display-> panel-> timings.
.

Solution Verification:

After the call is commented out, the system crashes.

New problem investigation:

After locating the problematic code line,
It is found that our parameters are out of the valid range when we set them. Change the value to a smaller value and use the oscilloscope to test the clock frequency and the corresponding signal is the same as the value set in the driver file. The problem is finally solved. It takes seven workers in total.
.