From eLinux.org
Jump to: navigation, search


Testing the DRM/VSP Interface on RCar G3 Salvator-X platforms

VSP Race

When operating on R-Car Gen3 the DU driver can, under some conditions, report completion of a page flip event one frame too early. This can result in display flicker when userspace starts rendering to the buffer that is still being scanned out.

Work which has been completed to repair the race 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

The fixes provided by the tag drm-next-du-vsp-v3-20170305 will aim to be merged in Linux v4.12, after which the tag may be removed.

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`;
         echo $n;
         echo $n > /sys/module/vsp1/parameters/vsp1_delay ;
         sleep 5;