| Age | Commit message (Collapse) | Author |
|---|
|
1. Create auxiliary directory amdgpu into igt-gpu-tools/lib
Put all helpers and reusable functions into this directory using
the following assumptions:
- group memory alloc/free functions into separate file amd_memory.c and h.
- group command submissions helper functions for GFX, COMPUTE and SDMA into
separate file amd_command_submission.c and h.
- for compute put nop command submission into separate file amd_compute.c and h.
- for graphics put command submission into separate file amd_gfx.c and h.
- for fence put command submission into separate file amd_fence.c and h.
2. Simplify implementation and reduce the number of local variables and allocations.
3. The file igt-gpu-tools/tests/amdgpu/amd_basic.c has only functions responsible
for single sub test:
- amdgpu_memory_alloc
- amdgpu_userptr_test
- amdgpu_command_submission_gfx
- amdgpu_command_submission_compute
- amdgpu_command_submission_multi_fence
- amdgpu_command_submission_sdma
- amdgpu_semaphore_test
4. No helper functions into amd_basic.c file.
5. Updated command submissions for secure buffer.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Christian Koenig <christian.koenig@amd.com>
Reviewed-by: Alexander Deucher <alexander.deucher@amd.com>
|
|
Instead of writing our own wrappers of debugfs read,
use updated functions from lib.
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Mark Yacoub <markyacoub@chromium.org>
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
|
|
[why]
We need test cases to validate PSR-SU disabled when a specific
plane scaling occurs by visual confirm. From driver's perspective,
any plane's height/width change detected, it would cause PSR-SU
be disabled.
[how]
- based on the existed MPO test case, we'd add two more input
arguments to the test function, i.e. one as flag indicating if
to test scaling, another as scaling ratio for the primary plane
- start from 1/3 iteration in test run, scaling the primary plane
w/ the given ratio and update the overlay as well, and observe
if PSR-SU is disabled as expected by allowing some delay to
check
- add two sub-test cases, one w/ scaling ratio 1.5, another 0.75
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
|
|
[why]
Current implementation to emulate the MPO video playback is via
creating 20 framebuffers (FB) and each FB has a colorful strip
pattern in a different position. From usrmode's view, in general
it would not create so many FBs for primary plane. Instead, it
only creates double or tripple buffers.
[how]
- drop the 20 framebuffers in current implementation
- use the double primary plane framebuffers defined in data struct
and update the strip pattern alternatively on the double FBs and
do page flip for each iteration
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
|
|
[why]
We'd clean-up the code to avoid repeated variable declarations in
different psr-su test cases.
[how]
- add primary/overlay framebuffer width/height to generic data
structure
- add cursor framebuffer instance to data structure
- clean-up the code for mpo/ffu/cusor test cases by using above
re-useable variables
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
|
|
[why]
Analogous to usermode behavior, when there are primary plane and
overlay plane committed, alpha region of overlay corresponding to
the primary plane position/size should be set to zero to explicitly
display the content of primary plane (emulated as video playback in
this test case) in general.
The input arguments of width/height of the helper to paint the
framebuffer should not exceed the size of the created framebuffer.
[how]
- set the alpha region of overlay plane framebuffer to zero aligned
to the position/size of the primary plane
- paint the primary plane framebuffer background/foreground w/ the
valid width/height.
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
changes in v2:
------------------
- correct the word "toplay" and replace w/ "overlay" to make it
more clear and accurate
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
|
|
[why & how]
Since the DSC is visually lossless but loss still exists after
compression/decompression at source/destination sides. So for any
bypass mode validation, which requires what received at sink is
consistent to what is transmitted at source, DSC is required to be
turned off.
skip the test run if the DSC is enabled on the connector (output).
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
|
|
[why]
In amdgpu kernel, to enable PSR visual confirm debug option, it
needs a full modeset to call the DM PSR setup helper which in turn
to set the visual confirm debug option. Currently before test run
there is such full modeset, and after test run ends the visual
confirm option is restored to be disabled. Although the IGT clean
up after test run ends will do DPMS transition and trigger a full
modeset, but at the moment the visual confirm is already disabled.
This means that even from command line, visual confirm option is
set, the DC visual confirm debug is never enabled actually during
any PSR-SU test run.
[how]
If visual confirm option is set from command line parameter, before
any PSR-SU test run, we manually trigger a DPMS off->ON transition
which in turn to trigger a full modeset in kernel from test_init(),
to enable the visual confirm.
changes in v2:
- drop the scaling test patch and rebase w/ latest cod base
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
|
|
[why & how]
Besides the static background + cursor movement, a more generic use
case from usermode is MPO + cursor movement, e.g. a video stream
is playing on screen and user moves the cursor randomly. We'd have
a test case to validate PSR-SU enablement and SU region updates by
visual confirm for MPO + cursor movement scenario.
Refactoring the function for static background + cursor movement
test case by adding a flag indicating to test MPO or not. Adding
primary FBs as member of data structure used in PSR-SU test cases.
For MPO + cursormovement test case, create two primary FBs w/ diff
color and fix the position, and during iteration, flip the primary
FB together w/ cursor positon update. By enabling visual confirm
debug option, the equivalent dirty rectangle region fo SU update
is the combination of the old cursor position, new cursor position,
and the dirty rectangle for MPO plane. It is expected to observe
a green bar on the right side of the screen with height of the
combinated dirty rectangle.
changes in v2:
-----------------
- use multi-level comment to replace "//"
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
|
|
[why]
We'd have a test case to validate PSR-SU enablement and selective
region update when cursor movement occurs by visual confirm. This
is to emulate the scenario of usermode behavior that only the
cursor is moving on top of the static screen.
[how]
create overlay plane w/ screen size and primary plane w/ quarter
of screen size and positioned at the top-left of screen. create
a cursor plane w/ size of (currently set to) 128 pixels.
move the cursor plane along horizonal/vertical/diagonal three
directions w/ the incremental step of 16 pixels for a couple of
seconds to allow visual confirm of PSR-SU update.
changes in v2:
-------------------
- use multi-level comment to replace the '//' as per the Linux
coding rule
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
|
|
[why & how]
For CI machine, by default it would directly run test case w/o any
manual confirmation. And visual confirm option is to validate the
PSR-SU feature as manual approach, which is for debugging purpose
and not for CI automated scheme.
Pre-set the "visual_confirm" to disable and only to enable the
visual confirm by manual.
changes in v2:
----------------------
- pre-set visual confirm option from enabled to disabled, and set
it as required argument.
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
|
|
[why & how]
For amdgpu PSR-SU validation, we'd create and test cursor update
use case as well. To emulate a mouse-like cursor movement, we'd
define a helper to draw a cursor pattern.
- helper draw the cursor pattern as an 45-degrees rotated arrow
- for the region of arrow, set alpha to 1 to make cursor foreground
and always on the top
- for rest of the non-arrow region, set alpha to 0 to make it as
background
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
|
|
[why & how]
For amdgpu PSR-SU test cases, we'd first check if the sink device
and amdgpu driver support the PSR-SU feature at the beginning. We
define a local helper to wrap the check for PSR-SU support from
sink and driver as well and called by both MPO and FFU test case,
to avoid the code repetition.
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Changes in v2:
-----------------
- use igt_warn() for any PSR SU cap/support check before FALSE
returned
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
|
|
[why]
We need a full-frame update (FFU) test case to validate PSR-SU
feature enablement by visual confirm.
[how]
1. create two overlay FBs with full screen size and one primary FB
w/ 1/4 screen size
2. panning the primary plane to top-left and flip for couple of
frames
3. wait for couple of seconds to allow visual confirm
4. panning the primary plane from top-left to middle of screen
5. repeat step 3
6. panning the primary plane from middle to bottom-right of screen
7. repeat step 3
If the PSR-SU is enabled as expected, for FFU we'd observe the
visual confirm by seeing the blue border at the bottom of screen
and the bottom of primary plane (megenta rectangle) as well.
Changes in v2:
----------------
- drop the unnecessary helper panning_pfb_and_psrsu_check() and
collapse the operations into run_check_psr_su_ffu()
- initial the two overlay FBs w/ global alpha and different color
not to update the specific alpha region for each panning of the
primary plane.
Changes in v3:
----------------
- before each panning of primary plane, update alpha region in
overlay at position/size of primary plane, set alpha to 0.0
to make it transparent. In addition, set the rest of overlay
region to 1.0 to make it opaque.
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
[why & how]
AMDGPU DM debugfs provides a debug option of PSR visual confirm,
we'd make it an interactive option that provides capability to
usermode to choose if or not to enable the PSR visual confirm.
- add interactive option "visual-confirm" and by-default we select
it as TRUE to enable visual confirm for PSR-SU test cases.
- set PSR visual confirm debugfs if interactive debug option of
visual confirm set before any test run begins, and reset after
any test run ends.
changes in v2:
------------------
- drop the "_dm_" from helpers of visual confirm debugfs set/get
- drop the non-necessary visual confirm option check after set
and reset, before and after the test run, respectively
- align the 2nd line code w/ previous line's opening brace
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
|
|
[why & how]
Currently the enablement of PSR-SU for Linux kernel is still WIP
and the PSR state to check for PSR-SU MPO is not upstreamed yet.
In addition, all the PSR-SU test case currently by default is
validated with visual confirm.
Drop the PSR state check in MPO PSR-SU sub-test case in the loop.
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
|
|
[why & how]
The enum of AMDGPU PSR STATE may update along the time and should be
aligned to the code base of upstream. Instead of using hard-coded
integer, replace them with enum PSR_STATE would be preferred and we only
need to update the PSR_STATE enum if needed in the future.
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jay Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
|
|
[why & how]
The PSR state read helper should return an integer which is not
the same as PSR state enumeration item for the case of debugfs
interface opening fail. Currently it return false which is casted
to 0 that is the same as PSR_STATE0, this is incorrect.
Instead of returning 0, a negative (e.g. -1) value is returned
when debugfs interface of PSR state opening fails. And adding the
check of such negative value in amd_psr test case as well.
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
|
|
[why]
We need a test case to imitate the multiplane overlay (MPO) video
playback use case and check PSR-SU enablement during test run.
[how]
The test run only works for PSR-SU capable sink device and skip for
any non-eDP or non-PSR-SU connector or kernel driver not supporting
PSR-SU feature.
To emulate the video playback and MPO scenario, we use overlay plane
w/ size of addressable and primary plane w/ size of quater of overlay
acting as video playback region.
Create couple of framebuffers w/ size of primary plane and with
the pattern of vertical color strip on different position on the
FB. During test run, we flip the primary framebuffer and expect the
visual effect of moving strip within the region of primary plane
acting as video playback. The primary plane during test run is not
moving position or resizing.
changes in v3
----------------
* make the indentation consistent to use tabs
* newline after for loop for readability
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
|
|
[why]
The existed amdgpu debugfs helpers to check existance/support of
connector's debugfs entry have a bunch of code redundant. Since
the generic debugfs interface checker is defined, we'd refactor
to avoid code redundancy.
[how]
- call generic helper igt_amd_output_has_debugfs() for debugfs
interface existence check for DSC, HPD, LINK SETTING, PSR CAP
etc.
- call psr state check helper for existed basic PSR test case.
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
|
|
[why]
For AMDGPU devices, we'd check the PSR state via reading from the
debugfs interface for a given eDP connector, where the debugfs
interface path locates at
<debugfs_root>/dri/0/eDP-X/psr_state
where 'X' is the eDP connector index.
[how]
define and add the helper to check if PSR state debugfs interface
is supported in driver, and the helper to read PSR state from the
debugfs interface.
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
|
|
[Why]
No need to capture original lane count and link rate for setting back
when exit the test. What we actually need to do is clean up the
preferred link_setting of driver.
[How]
Clean up unnecessary steps.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
|
|
[Why & How]
1. There is no need to check crc since what we're testing is link training.
Not test about driver selected BW is sufficient or not.
2. Current crc is created by "auto" which is the crc of crtc. This crc should
be constant when change link training setting which is meaningless to this
test.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
|
|
This tests transition between normal and FreeSync-Video modes and
measures the FPS to ensure vblank events are happening at the
expected rate. A SMPTE test pattern is displayed in the first mode,
and then a simple animation is displayed in the second mode, in
order to help the user to check if there are blanking with mode
transition.
v4: Rebase and refine commit message
v3: Remove conditional debugging calls and some comments.
v2: Rebase
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Solomon Chiu <solomon.chiu@amd.com>
|
|
[Why & How]
Add new igt test amd_ilr for ilr fature.
ILR (Intermediate Link Rate) is the feature introduced in eDP1.4.
For saving power purpose, it provides finer granularity of link
rates to optimize the allocated bandwidth needed for resolutions of
eDP panels.
This new igt test "amd_ilr" validates ILR feature from two perspective:
* Test if we can sucessfully train link rate at all supported ILRs
* Iterate over all modes to see if we do use ILR to optimize the link
rate to light up the mode.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
This commit adds a DP DSC test that checks:
* Forces DSC on/off and ensures it is reset properly
* Check DSC slice height property
* Verify various DSC slice dimensions
* Tests various combinations of link_rate + lane_count and logs if DSC
enabled/disabled Tests different bpc settings and logs if DSC is
enabled/disabled
Change since V3:
- Drop useless test
Change since V2:
- Remove IGT_CRTC_DSC_SLICE_HEIGHT crtc property from this commit
Change since V1:
- Rebase
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Nicholas Choi <Nicholas.Choi@amd.com>
Cc: Mark Yacoub <markyacoub@chromium.org>
Cc: Hayden Goodfellow <hayden.goodfellow@amd.com>
Cc: Hersen Wu <hersenxs.wu@amd.com>
Cc: Roman Li <roman.li@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Signed-off-by: Eryk Brol <eryk.brol@amd.com>
|
|
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
|
|
Couple of tests were accessing pipe's without ensuring if they are
enabled or not. Using for_each_pipe macro to do so.
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
|
|
[Why]
Full screen scaling is a common usecase
[How]
Rework the scaling tests to add a 'fullscreen' test case. Change the
test_plane function to use "dst_w/h" instead of a scale multiplier. This
way we can easily add a full screen scale multiplier.
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
|
|
[Why]
The MPO scale and pan subtests is valid with one display and our current
CI setup only has one display.
[How]
Change the MPO scale and pan subtests to be single display and add
"-multihead" subtests for the two for the original dual display config
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Victor Lu <victorchengchi.lu@amd.com>
|
|
[Why]
Resizing MPO window is a common usecase (video in windowed mode)
Our MPO feature has scaling limitations (0.25x -> 16x). So this test
creates a window of various reolutions and scales them between 0.25x -> 16x
[How]
The test creates common video sizes and scales them from (0.30x->16x).
The lower limit is 0.25 but some combination of configs fail at 0.25x so
0.30 is used as the starting point.
CRTC#1 CRTC#1
+--------------------+ +---------------------+
| +-------+ | | +------------+ |
| |Primary| | | |Primary | |
| +-------+ | --> | | | |
| | scale | | | |
| | | +------------+ |
|overlay | |Overlay |
+--------------------+ +---------------------+
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
|
|
[Why]
In a multi display MPO config the MPO window is dragged from one display
to the other. In this usecase there is an instance when the overlay is
moved from one display to the next. This test recreates the scenario
(MPO swap)
[How]
Overlay should switch to the display that has >50% of the video. This
test was created with this asumption.
The test creates common video sizes and swaps a window of size (w/2,h)
between 2 displays bezzels at the top,middle and bottom of the display.
CRTC#1 CRTC#2 CRTC#1 CRTC#2
+-------------+------------+ +-------------+------------+
| | | | | |
| +--------+ | | +--------+ |
| |Primary | Primary | <=> | Primary |Primary | |
| | | | Swap | | | |
| +--------+ | | +--------+ |
|overlay | | | |Overlay |
+-------------+------------+ +-------------+------------+
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
|
|
[Why]
Moving the MPO window is a common usecase (video window being moved).
This test creates a MPO window and moves it horizontally, vertically and
diagonally
[How]
Create common video resolution windows and move them across the
displays. Test pass is determined by getting a crc of window location
using a single plane, then recreating this scenario using overlay.
Test panes from Start->End1, Start->End2 and Start->End3
CRTC#1
Start
+--------+--------+--------+
|Primary | --> |Primary | End1
+--------+ +--------+
| | \ Overlay |
| v * |
+--------+ \ +--------+
|Primary | |Primary | End2
+--------+--------+--------+
End3
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
|
|
[why]
Older ASIC does not support multi-head MPO
[how]
Rename current mpo-swizzle-toggle subtest to
mpo-swizzle-toggle-multihead. Change mpo-swizzle-toggle to only use one
output.
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Victor Lu <victorchengchi.lu@amd.com>
|
|
[Why]
The test wasn't working on some setups and needs fixing
[How]
Added output pipe initialization
Added checks for both 4k and 2160p
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Ahmad Othman <ahmad.othman@amd.com>
|
|
Sequence captured on ChromeOS - we experience underflow when toggling
between swizzle modes on the primary plane with MPO enabled.
Add a new subtest replicating that sequence, "mpo-swizzle-toggle".
Converts the existing framework over to the new multi-display framework
since that's the configuration where this was found.
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
|
|
Tests MPO using a primary plane and an overlay plane with a transparent
cutout.
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Victor Lu <victorchengchi.lu@amd.com>
|
|
[Why&How]
Test for PSR functionality. With an eDP connected, it tests whether PSR
is enabled by commiting a static framebuffer
hardware requirements:
1. eDP panel that supports PSR (multiple panel can be connected at the
same time)
2. Optional DP display for testing a regression condition (setting crtc
to null)
Acked-by: Mikita Lipski <Mikita.Lipski@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
|
|
Switching between different modes could potentially create pstate
warnings if clocks are not being set correctly.
The subtest gets the highest and lowest mode supported on the connector
and switch between them.
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
|
|
[why]
Since driver can now support multiple eDPs and Debugfs structure for
backlight changed per connector - the test should then iterate through
all eDP connectors.
[how]
1. Execute each subtest on all eDP outputs connected.
2. Change helper functions to be used per connector.
3. Since debugfs current/target backlight entries are per connector now,
change the sanity test to checking if eDP connectors present.
The individual test should fail if entries are not found.
4. Update abm_gradual test per new ABM behavior:
- convergence time is reduced;
- transition can be observed within 1 sec.
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Reviewed-by: Roman Li <romli@amd.com>
|
|
[Why]
There was a driver regression with which too high max-bpc setting
causes 4K video modes failing stream validation and dropped from
mode list.
[How]
Add this test to catch the regression.
v2:
- Fix typo
- Skip instead of fail if no HDMI display connected
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
DRM_FORMAT_MOD_LINEAR is the more sensible name for
DRM_FORMAT_MOD_NONE. Use the better name.
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
[Why]
Having a test that iterates through different link
settings and performs link training with them is useful
and currently missing from IGT.
[How]
Add a link settings test and its required helper functions.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Signed-off-by: Eryk Brol <eryk.brol@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Tested-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
Add tests to check Freesync capability reporting after system resume
from suspend.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
These new tests only check if frame rate range is within legal range.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
Freesync capability is parsed from EDID and reported to debugfs. The
new tests check if the parsing is correct by overriding EDID with golden
sample.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
Check for memory leaks in these two cases:
- Connector EDID parsing after suspend-resume
- Triggerring of connector hotplugs
Depends on CONFIG_HAVE_DEBUG_KMEMLEAK=y in kernel config.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
Test if ASSR is correctly enabled/disabled after suspend and DPMS.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
Check if ASSR is correctly disabled or enabled on DP/eDP links.
Currrently the tests are verified to work on AMD hardware but failing
on some others, so they are AMD-specific for the time being.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
|
[Why]
There is a debugfs entry to trigger software hotplugs. We can use this
for IGT tests.
[How]
Add hotplug test for all connectors, hotplug after suspend.
Signed-off-by: Victor Lu <victorchengchi.lu@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
|
