Difference between revisions of "R-Car/Tests:DU"
< R-Car
(Created page with "= DU = == Testing the DRM/VSP Interface on RCar G3 Salvator-X platforms == === VSP Race === Work which has been completed to repair races between the DU and VSP drivers mu...") |
|||
| Line 12: | Line 12: | ||
To manually verify this work - perform the following sequence: | To manually verify this work - perform the following sequence: | ||
| + | |||
| + | ==== Test Dependancies ==== | ||
| + | * [[:File:DNI-TEST-Fake-long-processing-during-atomic-flush.patch|DNI-TEST-Fake-long-processing-during-atomic-flush.patch]] | ||
| + | * a sample application for drawing on the screen | ||
| + | ** kmscube is recommended | ||
==== Test Setup ==== | ==== Test Setup ==== | ||
| Line 21: | Line 26: | ||
* Compile the kernel, and boot a Salvator-X board | * Compile the kernel, and boot a Salvator-X board | ||
* Introduce an artificial delay with the following command using a shell terminal running on the board: | * Introduce an artificial delay with the following command using a shell terminal running on the board: | ||
| − | ** # echo | + | ** # echo 8000 > /sys/module/vsp1/parameters/vsp1_delay |
| + | * execute a visual test application, and observe the tearing and flickering effects. | ||
| + | ** # kmscube | ||
| + | |||
| + | ==== Apply the fixes and retest ==== | ||
| + | * Returning to your kernel build environment, checkout a branch containing the fixes referenced in this document, and again apply the test patch on top of the series, or merge in the branch/tag to your current working tree. | ||
| + | * Compile the kernel and reboot the Salvator-X board | ||
| + | * Introduce an artificial delay with the following command: | ||
| + | ** # echo 8000 > /sys/module/vsp1/parameters/vsp1_delay | ||
| + | * execute a visual test application, and observe the screen. No tearing or flickering effects should be present | ||
| + | ** # kmscube | ||
| + | |||
| + | ==== Resiliance stress testing ==== | ||
| + | As an extra step, verify the system under a varying degree of delays | ||
| + | * Ensure that kmscube or your test application is still running on the screen. | ||
| + | * Execute the following loop to dynamically change the delay | ||
| + | for n in `seq 10000 100 17000`; | ||
| + | do | ||
| + | echo $n; | ||
| + | echo $n > /sys/module/vsp1/parameters/vsp1_delay ; | ||
| + | sleep 5; | ||
| + | done | ||
Revision as of 04:11, 6 March 2017
Contents
DU
Testing the DRM/VSP Interface on RCar G3 Salvator-X platforms
VSP Race
Work which has been completed to repair races between the DU and VSP drivers must be verified by a manual process.
This process involves introducing an artificial delay to simulate the possible delays that could occur in a running system, which would cause an effect on the display pipeline. To implement this delay, a patch: File:DNI-TEST-Fake-long-processing-during-atomic-flush.patch is provided. This patch should be applied manually to your local Linux Kernel sources, before rebuilding.
To manually verify this work - perform the following sequence:
Test Dependancies
- DNI-TEST-Fake-long-processing-during-atomic-flush.patch
- a sample application for drawing on the screen
- kmscube is recommended
Test Setup
- Establish a build environment for compiling the kernel on your host development platform
- Download the patch and save in your kernel tree.
Establish a baseline comparison
- Apply the patch to your kernel tree without any fixes relating to the issue.
- Compile the kernel, and boot a Salvator-X board
- Introduce an artificial delay with the following command using a shell terminal running on the board:
- # echo 8000 > /sys/module/vsp1/parameters/vsp1_delay
- execute a visual test application, and observe the tearing and flickering effects.
- # kmscube
Apply the fixes and retest
- Returning to your kernel build environment, checkout a branch containing the fixes referenced in this document, and again apply the test patch on top of the series, or merge in the branch/tag to your current working tree.
- Compile the kernel and reboot the Salvator-X board
- Introduce an artificial delay with the following command:
- # echo 8000 > /sys/module/vsp1/parameters/vsp1_delay
- execute a visual test application, and observe the screen. No tearing or flickering effects should be present
- # kmscube
Resiliance stress testing
As an extra step, verify the system under a varying degree of delays
- Ensure that kmscube or your test application is still running on the screen.
- Execute the following loop to dynamically change the delay
for n in `seq 10000 100 17000`;
do
echo $n;
echo $n > /sys/module/vsp1/parameters/vsp1_delay ;
sleep 5;
done
