linux.git/drivers/gpu/drm/scheduler/tests, branch master

BackMerge tag 'v7.2' into drm-next

2026-08-20T00:58:44+00:00

Linux 7.2

There was a lot of conflicts this round between fixes and next,
and I'd like to get the merge resolutions that we have in drm-tip.

Signed-off-by: Dave Airlie

Revert "drm/sched: Remove drm_sched_init_args->num_rqs usage"

2026-08-11T16:34:01+00:00

This reverts commit 2833a0512b4cd55d9fea7ec18be85ef82e69ad3b.

Signed-off-by: Tvrtko Ursulin 
Cc: Luke.Wildhardt@proton.me
Cc: Matthew Brost 
Cc: Danilo Krummrich 
Cc: Philipp Stanner 
Cc: Christian König 
Signed-off-by: Tvrtko Ursulin 
Link: https://lore.kernel.org/r/20260811163139.99746-5-tvrtko.ursulin@igalia.com

Merge tag 'drm-misc-next-2026-06-19' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next

2026-07-06T07:38:49+00:00

drm-misc-next for 7.3:

UAPI Changes:
 - connector: Add color format property

Cross-subsystem Changes:

 - dmem: introduce a peak file

Core Changes:
 - atomic: Add create_state callback and helpers to all objects, add
   documentation on atomic commit lifetime
 - buddy: Fix use-after-free, add per-order free and used block
   scoreboards
 - gem: Remove DRIVER_GEM_GPUVA feature flag
 - hdmi: Hook the color format property in the helpers
 - mipi-dsi: Add MIPI_DSI_MODE_DSC_ALL_SLICES_IN_PKT flag
 - sched: Add test suite for concurrent job submissions
 - virtio: Add support for saving and restoring virtio_gpu_objects,
   abort virtqueue wait on device removal to avoid hung task

Driver Changes:
 - amdgpu: Implement "color format" DRM property
 - amdxdna: Disable device buffer exporting
 - ethosu: Add performance counter support
 - msm: Support DSC configurations with slice_per_pkt > 1
 - mxsfb: Fix disable sequence
 - panthor: Support sparse mappings
 - rockchip: Support YUV background color, Fix layer config timeout, add
   edp support for rk3576, cleanups and formats improvements
 - solomon: Add a batch command submission function
 - tegra: Add DSI support for Tegra 20 and 30, fix dsi driver when the
   firmware hasn't enabled the controller,
 - v3d: Reduce PM runtime autosuspend delay, Scheduler and submission
   fixes and refactoring, Deprecate V3D 3.3 and 4.1 support

 - bridge:
   - display-connector: don't autoenable HPD IRQ, trigger initial HPD
     event for DP
   - dw-dp: Null pointer dereference and use-after-free fixes
   - ti-sn65dsi83: Remove NO_HFP and NO_HBP mode flags
 - panel:
   - himax-hx83121a: add backlight regulator support
   - novatek-nt36672a: Inline panel init sequences
   - panel-edp: Add quirks for AUO B116XAT04.3, CMN N116BCP-EA2, CSW
     MNB601LS1-8, BOE NV116WH2-M30, BOE NT116WHM-N21, BOE NV116FH1-M31,
     BOE NV116FH1-M30, NV140FHM-N5B, TM156VDXP25
   - New panels: Samsung ATNA40HQ08-0, Anbernic TD4310, Chipone
     ICNA35XX, Ilitek ILI9488

Signed-off-by: Dave Airlie 

From: Maxime Ripard 
Link: https://patch.msgid.link/20260619-burgundy-termite-of-whirlwind-f7a4dd@houat

drm/sched: Fix spelling mistake "sumission" -> "submission"

2026-06-09T08:16:48+00:00

There is a spelling mistake in a pr_info message. Fix it.

Signed-off-by: Colin Ian King 
Signed-off-by: Philipp Stanner 
Link: https://patch.msgid.link/20260608172315.34626-1-colin.i.king@gmail.com

drm/sched: Add test suite for concurrent job submissions

2026-06-03T08:10:58+00:00

Add a new test suite to simulate concurrent job submissions to the DRM
scheduler, as this functionality is not covered by current test suites.

The new test suite includes two initial test cases: (i) a test case for
parallel job submission and (ii) a test case for interleaved job
submission and completion. In the first test case, worker threads
concurrently submit jobs to the scheduler, and then the timeline is
manually advanced to complete them in bulk. In the second test case,
worker threads concurrently submit sequences of jobs of different
durations to the mock scheduler using a sliding window to better model
real-world workloads. The timeline is advanced automatically by the
finishing jobs, interleaving submission with completion.

Signed-off-by: Marco Pagani 
Signed-off-by: Philipp Stanner 
Link: https://patch.msgid.link/20260520093350.1036001-1-marco.pagani@linux.dev

drm/sched: Fix clang build warning in kunit tests

2026-05-29T09:37:12+00:00

Initializing compile time constant struct or arrays from another such
variable is a gcc extension, while clang strictly requires a compile time
constant literal.

As reported by LKP:

>> drivers/gpu/drm/scheduler/tests/tests_scheduler.c:675:10: error: initializer element is not a compile-time constant
                                 drm_sched_scheduler_two_clients_attr),
                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/kunit/test.h:224:13: note: expanded from macro 'KUNIT_CASE_PARAM_ATTR'
                     .attr = attributes, .module_name = KBUILD_MODNAME}
                             ^~~~~~~~~~
   1 error generated.

vim +675 drivers/gpu/drm/scheduler/tests/tests_scheduler.c

   671
   672	static struct kunit_case drm_sched_scheduler_two_clients_tests[] = {
   673		KUNIT_CASE_PARAM_ATTR(drm_sched_scheduler_two_clients_test,
   674				      drm_sched_scheduler_two_clients_gen_params,
 > 675				      drm_sched_scheduler_two_clients_attr),
   676		{}
   677	};
   678

Fix it by using a compound literal as other tests do.

Signed-off-by: Tvrtko Ursulin 
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202605220312.Pu7UO05u-lkp@intel.com/
Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests")
Cc: Philipp Stanner 
Acked-by: Philipp Stanner 
Signed-off-by: Tvrtko Ursulin 
Link: https://lore.kernel.org/r/20260522090129.9385-1-tvrtko.ursulin@igalia.com

drm/sched: Remove drm_sched_init_args->num_rqs usage

2026-04-17T12:43:29+00:00

Remove member no longer used by the scheduler core.

Signed-off-by: Tvrtko Ursulin 
Cc: Matthew Brost 
Cc: Danilo Krummrich 
Cc: Philipp Stanner 
Cc: Christian König 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Matthew Brost 
Signed-off-by: Philipp Stanner 
Link: https://patch.msgid.link/20260417103744.76020-27-tvrtko.ursulin@igalia.com

drm/sched: Add some more scheduling quality unit tests

2026-04-17T12:43:28+00:00

This time round we explore the rate of submitted job queue processing
with multiple identical parallel clients.

Example test output:

3 clients:
        t               cycle:     min  avg max : ...
        +     0ms                   0    0    0 :   0   0   0
        +   102ms                   2    2    2 :   2   2   2
        +   208ms                   5    6    6 :   6   5   5
        +   310ms                   8    9    9 :   9   9   8
...
        +  2616ms                  82   83   83 :  83  83  82
        +  2717ms                  83   83   83 :  83  83  83
    avg_max_min_delta(x100)=60

Every 100ms for the duration of the test it logs how many jobs each
client had completed, prefixed by minimum, average and maximum numbers.
When finished overall average delta between max and min is output as a
rough indicator to scheduling fairness.

Signed-off-by: Tvrtko Ursulin 
Cc: Christian König 
Cc: Danilo Krummrich 
Cc: Matthew Brost 
Cc: Philipp Stanner 
Cc: Pierre-Eric Pelloux-Prayer 
Acked-by: Christian König 
Acked-by: Danilo Krummrich 
Tested-by: Vitaly Prosyak 
Signed-off-by: Philipp Stanner 
Link: https://patch.msgid.link/20260417103744.76020-6-tvrtko.ursulin@igalia.com

drm/sched: Add some scheduling quality unit tests

2026-04-17T12:43:28+00:00

To make evaluating different scheduling policies easier (no need for
external benchmarks) and perfectly repeatable, lets add some synthetic
workloads built upon mock scheduler unit test infrastructure.

Focus is on two parallel clients (two threads) submitting different job
patterns and logging their progress and some overall metrics. This is
repeated for both scheduler credit limit 1 and 2.

Example test output:

  Normal and low:
                    pct1 cps1 qd1;  pct2 cps2 qd2
        +     0ms:   0     0    0;   0     0    0
        +   104ms: 100  1240  112; 100  1240  125
        +   209ms: 100     0   99; 100     0  125
        +   313ms: 100     0   86; 100     0  125
        +   419ms: 100     0   73; 100     0  125
        +   524ms: 100     0   60; 100     0  125
        +   628ms: 100     0   47; 100     0  125
        +   731ms: 100     0   34; 100     0  125
        +   836ms: 100     0   21; 100     0  125
        +   939ms: 100     0    8; 100     0  125
        +  1043ms:               ; 100     0  120
        +  1147ms:               ; 100     0  107
        +  1252ms:               ; 100     0   94
        +  1355ms:               ; 100     0   81
        +  1459ms:               ; 100     0   68
        +  1563ms:               ; 100     0   55
        +  1667ms:               ; 100     0   42
        +  1771ms:               ; 100     0   29
        +  1875ms:               ; 100     0   16
        +  1979ms:               ; 100     0    3
    0: prio=normal sync=0 elapsed_ms=1015ms (ideal_ms=1000ms) cycle_time(min,avg,max)=134,222,978 us latency_time(min,avg,max)=134,222,978
us
    1: prio=low sync=0 elapsed_ms=2009ms (ideal_ms=1000ms) cycle_time(min,avg,max)=134,215,806 us latency_time(min,avg,max)=134,215,806 us

There we have two clients represented in the two respective columns, with
their progress logged roughly every 100 milliseconds. The metrics are:

 - pct - Percentage progress of the job submit part
 - cps - Cycles per second
 - qd  - Queue depth - number of submitted unfinished jobs

The cycles per second metric is inherent to the fact that workload
patterns are a data driven cycling sequence of:

 - Submit 1..N jobs
 - Wait for Nth job to finish (optional)
 - Sleep (optional)
 - Repeat from start

In this particular example we have a normal priority and a low priority
client both spamming the scheduler with 8ms jobs with no sync and no
sleeping. Hence they build very deep queues and we can see how the low
priority client is completely starved until the normal finishes.

Note that the PCT and CPS metrics are irrelevant for "unsync" clients
since they manage to complete all of their cycles instantaneously.

A different example would be:

  Heavy and interactive:
                    pct1 cps1 qd1;  pct2 cps2 qd2
        +     0ms:   0     0    0;   0     0    0
        +   106ms:   5    40    3;   5    40    0
        +   209ms:   9    40    0;   9    40    0
        +   314ms:  14    50    3;  14    50    0
        +   417ms:  18    40    0;  18    40    0
        +   522ms:  23    50    3;  23    50    0
        +   625ms:  27    40    0;  27    40    1
        +   729ms:  32    50    0;  32    50    0
        +   833ms:  36    40    1;  36    40    0
        +   937ms:  40    40    0;  40    40    0
        +  1041ms:  45    50    0;  45    50    0
        +  1146ms:  49    40    1;  49    40    1
        +  1249ms:  54    50    0;  54    50    0
        +  1353ms:  58    40    1;  58    40    0
        +  1457ms:  62    40    0;  62    40    1
        +  1561ms:  67    50    0;  67    50    0
        +  1665ms:  71    40    1;  71    40    0
        +  1772ms:  76    50    0;  76    50    0
        +  1877ms:  80    40    1;  80    40    0
        +  1981ms:  84    40    0;  84    40    0
        +  2085ms:  89    50    0;  89    50    0
        +  2189ms:  93    40    1;  93    40    0
        +  2293ms:  97    40    0;  97    40    1

In this case client one is submitting 3x 2.5ms jobs, waiting for the 3rd
and then sleeping for 2.5ms (in effect causing 75% GPU load, minus the
overheads). Second client is submitting 1ms jobs, waiting for each to
finish and sleeping for 9ms (effective 10% GPU load). Here we can see
the PCT and CPS reflecting real progress.

Signed-off-by: Tvrtko Ursulin 
Cc: Christian König 
Cc: Danilo Krummrich 
Cc: Matthew Brost 
Cc: Philipp Stanner 
Cc: Pierre-Eric Pelloux-Prayer 
Acked-by: Christian König 
Acked-by: Danilo Krummrich 
Tested-by: Vitaly Prosyak 
Signed-off-by: Philipp Stanner 
Link: https://patch.msgid.link/20260417103744.76020-5-tvrtko.ursulin@igalia.com

drm/tests: Mark slow tests as slow

2026-02-27T09:39:34+00:00

Some DRM tests cross the 1s execution time threshold that defines a test
as slow. Let's flag them as such.

Reviewed-by: Arunpravin Paneer Selvam 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Thomas Zimmermann 
Link: https://patch.msgid.link/20260224110310.1854608-1-mripard@kernel.org
Signed-off-by: Maxime Ripard