kernel/linux.git/drivers/gpu/drm/xe/tests, branch v7.2-rc1

drm/xe: Move xe->info.devid|revid initialization

2026-05-27T10:51:25+00:00

The xe_info_init_early() is a place where we initialize those of the xe->info fields that do not require any additional hardware probes. Move the initialization of the devid/revid also there, but to avoid breaking the kunit helper, which also calls this function, keep their initialization separate in sub-function so we can easily stub it when running the kunit test. Signed-off-by: Michal Wajdeczko Cc: Gustavo Sousa Reviewed-by: Gustavo Sousa Link: https://patch.msgid.link/20260526195452.20545-5-michal.wajdeczko@intel.com

drm/xe/rtp: Fully parse the ruleset

2026-05-22T13:52:29+00:00

The function rule_matches() short-circuits evaluation of the implicit conjunctions (each substring of rules not containing OR) and the explicit disjunctions (implicit conjunctions joined by OR). In other words: - in a conjunction, once a rule evaluate to false, we skip to the next OR (if any) to evaluate the next conjunction; - in a disjunction, once a conjunction evaluates to true, we return true and skip evaluating all the remaining rules. While this behavior results in a correct logical value, due to how the "OR" short-circuiting is implemented, it has the side-effect that rule set does not get fully "parsed", allowing incomplete constructs like (rule1, OR) to evaluate to true when rule1 is true. We should treat such constructs as invalid and treat them the same way we do for stuff like (OR, rule1). As such, update rule_matches() to "parse" the whole rule set, and that while keeping the short-circuit aspect of evaluation. With that, we can fix the FIXME test cases that cover that behavior. v2: - Do not change short-circuit *evaluation* behavior. (Matt) Reviewed-by: Matt Roper Reviewed-by: Violet Monti Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-6-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa

drm/xe/rtp: Do not break parsing when missing context

2026-05-22T13:52:29+00:00

With the current implementation, the RTP framework will cause parsing of the rule set to be interrupted if one rule requires a context item (gt or hwe) that is missing (i.e. when the value is NULL). This is arguably a semantic error instead of a syntactic one, meaning that RTP should not interrupt parsing the rules. With the current behavior, we would miss detecting other errors that could appear in the remaining rules and could also prevent valid rules joined by "OR" from being evaluated. Make sure that we do not stop parsing the rule set when detecting missing context and let's add rtp_rules_test_cases to reflect that. v2: - Add "missing-context" in the test case names to indicate that those are about rules that are missing the necessary context. (Matt) - Rebase: treat the new match type XE_RTP_MATCH_PLATFORM_STEP in the same way when the platform is missing step information. Reviewed-by: Matt Roper # v1 Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-4-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa

drm/xe/rtp: Don't short-circuit to false in or-yes case

2026-05-22T13:52:29+00:00

While RTP processing evaluates true on the "yes-or" case (i.e. a conjunction of rules that evaluate to true followed by an "OR" without the right hand operand), it does not on the "or-yes" one. Both cases are considered malformed and could be a result of someone dropping checks deemed not necessary anymore and forgetting to drop the superfluous "OR". Nevertheless, we should aim for consistency, and having the "or-yes" case also evaluating to true while also causing a warning seems reasonable. So let's do that. The "or-yes" pattern being evaluated to false comes from the fact that that we unconditionally short-circuit upon finding XE_RTP_MATCH_OR on the outer loop. We should only do that if the preceding conjunction of rules evaluated to true (meaning that rcount must be non-zero) and continue the evaluation otherwise. Do that and also add extra test cases to validate the short-circuiting behavior. Notice that some of the new test cases have a "FIXME" comment, which comes from the fact that we are unable to detect syntax errors after the short-circuit point. That is going to be fixed in a follow-up change. Link: https://lore.kernel.org/intel-xe/871pfw4lo9.fsf@intel.com/ Reviewed-by: Matt Roper Reviewed-by: Violet Monti Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-3-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa

drm/xe/rtp: Drop rule matching cases from rtp_to_sr_cases and rtp_cases

2026-05-22T13:52:29+00:00

The kunit test cases for the RTP framework are currently separated into three groups: (1) rtp_rules_cases: Those to verify rule matching logic. (2) rtp_to_sr_cases: Those to verify generation of save/restore tables from RTP tables. (3) rtp_cases Those to verify processing of RTP tables without save/restore action associated, which are used for OOB workarounds. Today we have some cases in (2) and (3) that are actually meant to verify rule matching logic. Now that we have (1), let's cleanup (2) and (3) so that they become focused on their main objectives. Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-2-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa

drm/xe/rtp: Write kunit test cases specific for rule matching

2026-05-22T13:52:29+00:00

The kunit test cases for the RTP framework are currently separated into those that validate xe_rtp_process_to_sr() and those that validate xe_rtp_process(). In both of them, we also have mixed stuff to validate rule matching functionality, which should rather be done in a separate test case group. Let's create such a group, specific for validating rule matching, and also add an initial set of cases. In an upcoming change, we will do a cleanup of the other groups by migrating those cases intended for rule matching to this new group. v2: - s/no-yes-or-no-yes/no-yes-or-yes-no/ (Matt) - Drop leftover include of . Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-1-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa

drm/xe/reg_sr: Do sanity check for MCR vs non-MCR

2026-05-15T21:05:14+00:00

The type struct xe_reg_mcr exists to ensure that the correct API is used when handling MCR registers. However, for the register save/restore functionality, the RTP processing always cast the register to a struct xe_reg and then apply_one_mmio() selects the MMIO API based on the "mcr" field of the register instance. This allows the developer to commit mistakes like passing a MCR register for an RTP action for a GT where the respective register is not MCR; and vice-versa. To capture such scenarios, do a sanity check in xe_reg_sr_add() that, upon an inconsistency: - "fixes" the register type by favoring what we have in our MCR range tables instead of what the developer selected for the save/restore entry; - raises a notice-level message to inform about the inconsistency. Note: As a collateral of this change, we need to include MCR initialization in xe_wa_test.c, otherwise a bunch of test cases end up failing because xe_gt_mcr_check_reg() will always return false, meaning that will incorrectly say that a MCR register is not MCR. v2: - Downgrade messages to notice level so as not to block CI execution when inconsistencies are found. (Matt) - Add missing EXPORT_SYMBOL_IF_KUNIT() calls. (Gustavo) Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260514-rtp-mcr-check-v3-7-30dd47855fee@intel.com Signed-off-by: Gustavo Sousa

drm/xe/kunit: Use KUNIT_EXPECT_EQ() in xe_wa_gt()

2026-05-15T21:05:13+00:00

Use KUNIT_EXPECT_EQ() in xe_wa_gt() as reg_sr errors in one GT do not impact the next GT in the test. Reviewed-by: Michal Wajdeczko Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260514-rtp-mcr-check-v3-5-30dd47855fee@intel.com Signed-off-by: Gustavo Sousa

drm/xe: Refactor emit_xy_fast_copy and emit_mem_copy functions

2026-05-13T06:51:12+00:00

To perform copy, based on whether the platform supports service copy engines, either MEM_COPY or XY_FAST_COPY_BLT instruction is used. Length of both the instructions is same today and so they use a common define EMIT_COPY_DW. This is not true for the future platforms. Implement separate functions which return the length of the instruction to help in preparing for it. Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260511123746.616662-8-balasubramani.vivekanandan@intel.com Signed-off-by: Balasubramani Vivekanandan

drm/xe/pat: Introduce xe_cache_pat_idx() macro helper

2026-04-21T17:20:17+00:00

Wrap pat.idx[] reads with xe_cache_pat_idx() so invalid PAT index use is caught by xe_assert() in debug builds. Suggested-by: Matthew Auld Reviewed-by: Matthew Auld Signed-off-by: Xin Wang Link: https://patch.msgid.link/20260416045526.536497-4-x.wang@intel.com Signed-off-by: Matt Roper