Difference between revisions of "R-Car/Tests:DU"

From eLinux.org
Jump to: navigation, search
(DU tests)
Line 1: Line 1:
 
= DU =
 
= DU =
 
  
 
== Testing the DRM/VSP Interface on RCar G3 Salvator-X platforms ==
 
== Testing the DRM/VSP Interface on RCar G3 Salvator-X platforms ==

Revision as of 04:13, 6 March 2017

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

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