The idle-skip optimization bypasses GuC suspend, so the GPU may not
perform the context switch that flushes TLB entries for invalidated
userptr VMAs. In LR/preempt-fence VM mode, this can lead to missed TLB
invalidation and page faults during userptr invalidation tests.
Restore unconditional schedule toggling on suspend so the context-switch
TLB flush is always performed.
This optimization will be reintroduced with a fix that does not skip
suspend in LR/preempt-fence VM mode.
Fixes: 8533051ce920 ("drm/xe: Skip exec queue schedule toggle if queue is idle during suspend") Cc: stable@vger.kernel.org # v7.0+ Suggested-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260603065217.3131066-2-tilak.tirumalesh.tangudu@intel.com
Violet Monti [Mon, 1 Jun 2026 20:09:50 +0000 (13:09 -0700)]
drm/xe/rtp: Ensure device_oob_was only evaluates correct rules
This commit builds on the implementation of the GT WA testing, increasing
the scope of testing to include the device OOB workaround list. As well
as checking for XE_RTP_ENGINE_CLASS(), this test also checks for rules
involving XE_RTP_GRAPHICS() and XE_RTP_MEDIA(), as well as their
derivatives.
This test will raise expectation fails for any workarounds in the
device_oob_was list that has an invalid rule type, preventing evaluation
or inclusion of rules that could be applied in the wrong context.
v6:
- No change
v5:
- No change
v4:
- No change
v3:
- Removed "VISIBLE_IF_KUNIT" keyword from xe_wa.h
- Heavily reworked rule checking within _dev_oob_test() function for
easier understanding and interpreting of errors
v2:
- Changed xe_rtp_table_dev_oob_test() to follow format of
xe_rtp_table_gt_test
- Changed device_oob_was generated params to follow format of
gt_was
Violet Monti [Mon, 1 Jun 2026 20:09:49 +0000 (13:09 -0700)]
drm/xe/rtp: Ensure oob_was does not evaluate engine type rules
This commit builds on the implementation of the GT WA testing, increasing
the scope of testing to include the OOB workaround list. The added test
checks for workarounds with XE_RTP_ENGINE_CLASS() rules and raises an
expectationfailure if any are found. Unlike the GT workarounds, there are
no flags within this workaround list, so all invalid rules will fail.
v6:
- No change
v5:
- No change
v4:
- No change
v3:
- Removed VISIBLE_IF_KUNIT keyword from xe_wa.h
- Reworked KUNIT_EXPECT_TRUE for easier decoding of errors
v2:
- Changed xe_rtp_table_oob_test() to follow format of
xe_rtp_table_gt_test
- Changed oob_was generated params to follow format of gt_was
generated params
Violet Monti [Mon, 1 Jun 2026 20:09:48 +0000 (13:09 -0700)]
drm/xe/rtp: Ensure gt_was doesn't evaluate rules with engine types
It is currently possible for a RTP rule, and subsequently a workaround,
to expect contexts that may not be present when the workaround is
applied. For example, the workarounds in the engine_was[] in drm/xe/xe_wa.c
expect an engine entity to be active. Conversely, the gt_was[] is not
depending on an engine entity to implement its workarounds. This kunit
test addition checks the gt_was[] workaround list for any workarounds
with XEP_RTP_ENGINE_CLASS() rules. If a workaround does have one of
these rules, the workaround is then checked for the "FOREACH_ENGINE" flag,
which ensures the workaround is implemented properly.
The result of this test is an expectation failure if a workaround has an
improper XE_RTP_ENGINE_CLASS() rule setup, and aims to prevent future
issues of gt_was workarounds being applied without proper contexts.
The gt_tunings[] RTP table has the same functional layout and
requirements as gt_was[], so it shares the same kunit test function,
minimizing excessive code.
v6:
- No change
v5:
- Remove unnecessary headers from xe_rtp_table_test.c
v4:
- No change
v3:
- Removed "VISIBLE_IF_KUNIT" keyword from xe_wa.h
- Added gt_tunings[] for testing
- Reworked KUNIT_EXPECT_TRUE() for easier parsing of errors
v2:
- Moved contents of xe_rtp_tables_test.h to .c and removed file
- Renamed macro RTP_KUNIT_ARRAY_PARAM to RTP_TABLE_PARAM
- Removed unnecessary functions and iterative components from
generated _gen_params functions and implemented usage of table
name and WA number as entry name
- Condensed xe_rtp_table_gt_test() to use KUNIT_EXPECT_TRUE with no
message statement
- Removed xe_rtp_table_test_init() and xe_rtp_table_test_exit() as
fake device initialization is not necessary
Gustavo Sousa [Mon, 1 Jun 2026 20:09:47 +0000 (13:09 -0700)]
drm/xe/rtp: Add struct types for RTP tables
We currently have a mixture of styles for our RTP tables with respect of
how we define the number of entries:
* xe_rtp_process_to_sr() expects to receive the number of entries as
arguments;
* xe_rtp_process() expects the array to have a sentinel at the end of
the array;
* in xe_rtp_test.c, even though xe_rtp_process_to_sr() does not
require a sentinel value, we need to rely on that technique to be
able to count xe_rtp_entry_sr entries because simply using
ARRAY_SIZE() is not possible.
The style used by xe_rtp_process_to_sr() makes it hard to share the
tables with other compilation units (e.g. kunit tests), since the number
of entries is calculated with ARRAY_SIZE(), which is done at compile
time.
Since we use the size of the tables to create some bitmasks, using a
sentinel style doesn't seem great either.
A way to reconcile things into a single style is to have a struct type
that would hold the entries array and the number of entries. Since we
have xe_rtp_entry and xe_rtp_entry_sr, we would have one type for each.
The advantage of the proposed approach is that now we have a nice way to
share the tables directly to kunit tests with information about their
size.
v6:
- Removed sentinels that are not needed
v5:
- Removed added code from conflict resolution issues
v4:
- Removed conflicts with main branch
v3:
- No changes
v2:
- Add compatibility with new xe_rtp_table_sr format for
"bad-mcr-reg-forced-to-regular" and
"bad-regular-reg-forced-to-mcr"
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260601200947.2032784-7-violet.monti@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
The drm_device-managed mutex_init might fail and return an error.
Add proper error handling. While around, update the function name
to clearly indicate this is an early software-only initialization.
The early GuC FW definition meant for our CI branch was accidentally
merged to the drm-xe-next branch instead. This GuC FW will never be
released to linux-firmware, so we do not want the definition to be
available in the mainline Linux codebase.
John Hubbard [Wed, 27 May 2026 22:55:07 +0000 (15:55 -0700)]
drm/xe: gate observation streams with perf_allow_cpu()
xe OA and EU-stall paths open-code a partial copy of the system-wide
perf CPU-event permission check:
if (xe_observation_paranoid && !perfmon_capable())
return -EACCES;
This open-coded check skips two things perf_allow_cpu() handles: the
graduated kernel.perf_event_paranoid policy that an administrator
may have tuned, and the security_perf_event_open() LSM hook.
Introduce xe_observation_paranoid_check() to wrap perf_allow_cpu(),
and convert the open-coded sites in xe_oa.c and xe_eu_stall.c. The
dev.xe.observation_paranoid sysctl still acts as an escape hatch
when cleared.
xe observation now consults kernel.perf_event_paranoid and the LSM
perf hook on every open. Sites that have already configured an LSM
perf policy or tuned the paranoid sysctl will see those settings
extend to xe.
John Hubbard [Wed, 27 May 2026 22:55:06 +0000 (15:55 -0700)]
perf/core: out-of-line and export perf_allow_cpu/tracepoint()
These helpers are static inline in <linux/perf_event.h> and reach
into sysctl_perf_event_paranoid and security_perf_event_open(),
neither of which is itself exported. The perf_allow_* trio is
therefore asymmetric: built-in callers can use any of the three, but
modular code can only call perf_allow_kernel().
Move both bodies into kernel/events/core.c next to perf_allow_kernel()
and export them with EXPORT_SYMBOL_GPL, following the shape of
commit 5e9629d0ae97 ("drivers/perf: arm_spe: Use perf_allow_kernel()
for permissions"). Existing in-tree callers live in built-in arch and
tracing code, so the change is invisible to them.
Provide !CONFIG_PERF_EVENTS stubs that fall back to perfmon_capable(),
so the helpers stay callable when perf is compiled out.
Wa_16023105232 programs the register IDLEDLY. The register is reset
whenever the engine is reset. Therefore it should be added to the GuC
save-restore register list for it to be restored after reset.
Michal Wajdeczko [Tue, 26 May 2026 19:54:52 +0000 (21:54 +0200)]
drm/xe/pm: Do early initialization in init_early()
There is no need nor gain in splitting mutex or list initializations
between two init functions as all of this is just pure software state
and all this could be done at once.
Michal Wajdeczko [Tue, 26 May 2026 19:54:51 +0000 (21:54 +0200)]
drm/xe/pm: Don't access device in init_early()
We should separate software-only state initialization from anything
else that requires access to the device's hardware. Extract d3cold
capability detection into a new function. Add simple kernel-doc for
updated functions here.
Michal Wajdeczko [Tue, 26 May 2026 19:54:50 +0000 (21:54 +0200)]
drm/xe: Separate early xe_device initialization
We would like to initialize more of the xe_device struct also from
the kunit code, as it should be safe to use most of the generic drm
or xe components without doing any additional tweaks. Separate early
xe initialization code to a new function, so it can be reused.
Michal Wajdeczko [Tue, 26 May 2026 19:54:49 +0000 (21:54 +0200)]
drm/xe: Move xe->info.devid|revid initialization
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.
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 force_execlist flag there.
Michal Wajdeczko [Tue, 26 May 2026 19:54:46 +0000 (21:54 +0200)]
drm/xe: Use raw device ID to find sub-platform descriptor
We don't need the partially initialized xe_device pointer to
find the sub-platform descriptor, as for the descriptor lookup
only the device ID is required and it can be obtained directly
from the pci_dev.
Tvrtko Ursulin [Sat, 23 May 2026 10:34:18 +0000 (11:34 +0100)]
drm/xe: Assign queue name in time for drm_sched_init
Currently the queue name is only assigned after the drm scheduler instance
has been created. This loses information with all logging or debug
workqueue facilities so lets re-order things a bit so the name gets
assigned in time.
To be able to assign a GuC ID early we split the allocation into
reservation and publish phases.
First, with the submission state lock held, we reserve the ID in the GuC
ID manager, which serves as an authoritative source of truth. Then we can
drop the lock and reserve entries in the exec queue lookup XArray. This
can be lockless since the NULL entries are invisible both to the kernel
and userspace. Only after the queue has been fully created we replace the
reserved entries with the queue pointer, which can be done locklessly for
single width queues.
While rule_matches() currently works for the grammar above, it doesn't
easily resemble it. Let's replace it with an implementation that is
structured in a way to resemble the grammar.
Such a new implementation, although a bit more verbose, is arguably
easier to reason about and to adapt to any extension we do to the
grammer in the future.
Also take this opportunity to update the kernel-doc for XE_RTP_RULES()
to include the grammar, so that it is not unwritten anymore.
v2:
- Include the grammar in the code documentation. (Matt)
Gustavo Sousa [Fri, 22 May 2026 08:45:21 +0000 (05:45 -0300)]
drm/xe/rtp: Fully parse the ruleset
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)
Gustavo Sousa [Fri, 22 May 2026 08:45:20 +0000 (05:45 -0300)]
drm/xe/rtp: Extract rule_match_item()
The current logic in rule_matches() mixes individual rule matching
with the logic necessary for handling OR operations. Let's simplify
rule_matches() to focus on the latter by extracting individual rule
matching into a separate function called rule_match_item().
Gustavo Sousa [Fri, 22 May 2026 08:45:19 +0000 (05:45 -0300)]
drm/xe/rtp: Do not break parsing when missing context
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.
Gustavo Sousa [Fri, 22 May 2026 08:45:18 +0000 (05:45 -0300)]
drm/xe/rtp: Don't short-circuit to false in or-yes case
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.
Gustavo Sousa [Fri, 22 May 2026 08:45:17 +0000 (05:45 -0300)]
drm/xe/rtp: Drop rule matching cases from rtp_to_sr_cases and rtp_cases
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.
Gustavo Sousa [Fri, 22 May 2026 08:45:16 +0000 (05:45 -0300)]
drm/xe/rtp: Write kunit test cases specific for rule matching
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 <kunit/test.h>.
Shuicheng Lin [Thu, 14 May 2026 20:32:10 +0000 (20:32 +0000)]
drm/xe/oa: Fix exec_queue leak on width check in stream open
In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the
function returns -EOPNOTSUPP directly, skipping the existing
err_exec_q cleanup path. The exec_queue reference obtained by
xe_exec_queue_lookup() is leaked.
The exec queue holds a reference on the xe_file, which is only
dropped during queue teardown. The leaked lookup ref is not on
the file's exec_queue xarray, so file close cannot release it.
This keeps both the exec queue and the file private state pinned
indefinitely.
Jump to err_exec_q instead of returning directly so the reference
is released.
Fixes: f0ed39830e60 ("xe/oa: Fix query mode of operation for OAR/OAC") Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260514203210.593488-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Michal Wajdeczko [Mon, 18 May 2026 19:25:47 +0000 (21:25 +0200)]
drm/xe/memirq: Drop cached iosys_map for MEMIRQ status
Since addition of the MSI-X support, we mostly rely on the offset
calculations done by XE_MEMIRQ_STATUS_OFFSET. We don't use this
separate map pointing to the first status page anymore.
Michal Wajdeczko [Mon, 18 May 2026 19:25:44 +0000 (21:25 +0200)]
drm/xe/memirq: Update diagnostic message
Instead printing static offset values, print number of allocated
pages and the actual GGTT addresses of the page zero source and
status and address of the common mask vector.
Michal Wajdeczko [Mon, 18 May 2026 19:25:43 +0000 (21:25 +0200)]
drm/xe/memirq: Reduce buffer size
When using MSI-X, we don't have to allocate the largest possible
buffer to accommodate all potential engine instances. Loop through
available engines, find highest engine instance and reduce buffer
size to avoid memory waste.
Michal Wajdeczko [Mon, 18 May 2026 19:25:41 +0000 (21:25 +0200)]
drm/xe/memirq: Update GuC initialization and IRQ handler
Introduce and use simple macro to calculate exact location of the
status vector to avoid inline calculation. Fix type for the GuC
source and status MEMIRQ addresses.
Michal Wajdeczko [Mon, 18 May 2026 19:25:40 +0000 (21:25 +0200)]
drm/xe/memirq: Make page layout macros private
There is no need to expose the macros describing memory-based
interrupts page layouts in the .h file as we only use them in
the private code. Move them to the .c file near the kernel-doc.
Michal Wajdeczko [Mon, 18 May 2026 19:25:39 +0000 (21:25 +0200)]
drm/xe: Add IRQ page to HW engine definition
For each HW engine definition, we already make changes to the IRQ
offset, as required when using MSI-X, but we leave actual MEMIRQ
page selection to the MEMIRQ handler, repeated on every interrupt.
As a preparation step to simplify the MEMIRQ handler, store the
MEMIRQ page number as part of the HW engine definition.
Gustavo Sousa [Wed, 13 May 2026 19:07:14 +0000 (16:07 -0300)]
drm/xe/guc: Use xe_device_is_l2_flush_optimized()
We encapsulate the logic to check if the platform has L2 flush
optimization feature in xe_device_is_l2_flush_optimized(), but
guc_ctl_feature_flags() is using an open-coded version of that same type
of check. Fix that by replacing the open-coded check with
xe_device_is_l2_flush_optimized().
drm/xe/multi_queue: Fix secondary queue error case
If xe_lrc_create() fails, the secondary queue added to the
multi-queue group list is not removed before freeing the
queue. Fix error path handling for secondary queues by
removing it from the multi-queue group list at the right
place.
Reported-by: Sebastian Österlund <sebastian.osterlund@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7979 Fixes: d716a5088c88 ("drm/xe/multi_queue: Handle tearing down of a multi queue") Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260518191639.320890-2-niranjana.vishwanathapura@intel.com
Gustavo Sousa [Thu, 14 May 2026 21:44:50 +0000 (18:44 -0300)]
drm/xe/reg_sr: Do sanity check for MCR vs non-MCR
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)
Gustavo Sousa [Thu, 14 May 2026 21:44:49 +0000 (18:44 -0300)]
drm/xe/mcr: Extract reg_in_steering_type_ranges()
The logic to check if a register falls within one of the ranges for a
steering type is already duplicated in
xe_gt_mcr_get_nonterminated_steering(). We will also want to use that
same logic in another upcoming function. Let's factor out that logic
and put it into a function named reg_in_steering_type_ranges().
Gustavo Sousa [Thu, 14 May 2026 21:44:47 +0000 (18:44 -0300)]
drm/xe: Extract xe_hw_engine_setup_reg_lrc()
The steps for processing RTP rules that build up an engine's reg_lrc
arguably belongs to xe_hw_engine.c and should be encapsulated into a
function in that unit.
Move that logic to a new function called xe_hw_engine_setup_reg_lrc().
Gustavo Sousa [Thu, 14 May 2026 21:44:46 +0000 (18:44 -0300)]
drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN4
The register COMMON_SLICE_CHICKEN4 is a MCR register on both Xe2 and
Xe3. Let's make sure to define a MCR version of it and use it for the
relevant IP versions.
Use XEHP_ as prefix for the register name, since it is MCR as of Xe_HP.
v2:
- Also change for one entry in lrc_tunnings, which was caught by
manual testing and add corresponging Fixes tag in commit message.
(Gustavo)
Fixes: 8d6f16f1f082 ("drm/xe: Extend Wa_22021007897 to Xe3 platforms") Fixes: e5c13e2c505b ("drm/xe/xe2hpg: Add Wa_22021007897") Fixes: 8ccf5f6b2295 ("drm/xe/tuning: Apply windower hardware filtering setting on Xe3 and Xe3p")
Bspec: 66534, 71185, 74417 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260514-rtp-mcr-check-v3-3-30dd47855fee@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reading debugfs file (/sys/kernel/debug/dri/0/gt*/pf/adverse_events)
with CFI (Control Flow Integrity) enabled, the kernel panics at
xe_gt_debugfs_simple_show+0x82/0xc0.
xe_gt_debugfs_simple_show() declare a function pointer expecting int
return type, but xe_gt_sriov_pf_monitor_print_events() is void return
type, leading to CFI failure and kernel panic.
Michal Wajdeczko [Thu, 14 May 2026 15:57:26 +0000 (17:57 +0200)]
drm/xe/vf: Fix signature of print functions
We have plugged-in existing VF print functions into our GT debugfs
show helper as-is, but we missed that the helper expects functions
to return int, while they were defined as void. This can lead to
errors being reported when CFI is enabled.
Fixes: 63d8cb8fe3dd ("drm/xe/vf: Expose SR-IOV VF attributes to GT debugfs") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mohanram Meenakshisundaram <mohanram.meenakshisundaram@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260514155726.7165-1-michal.wajdeczko@intel.com
Michal Wajdeczko [Tue, 12 May 2026 18:33:39 +0000 (20:33 +0200)]
drm/xe/display: Add macro with display driver ops
Instead of updating the drm_driver.fbdev_probe field in the runtime,
we can use macro which value depends on the actual Kconfig setup.
The .fbdev_probe hook will not be used by the drm core unless we
also enable a DRIVER_MODESET driver feature flag, and this flag
still depends on the xe_modparam.probe_display parameter.
Jakub Kolakowski [Tue, 31 Mar 2026 15:22:59 +0000 (15:22 +0000)]
drm/xe/sriov: Mark NVL as SR-IOV capable
Enable SR-IOV support for NVL platforms.
Signed-off-by: Jakub Kolakowski <jakub1.kolakowski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://patch.msgid.link/20260331152259.58270-1-jakub1.kolakowski@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Shuicheng Lin [Mon, 11 May 2026 15:33:07 +0000 (15:33 +0000)]
drm/xe/gt_idle: Use NSEC_PER_MSEC instead of float literal
The residency multiplier conversion in get_residency_ms() used the
floating-point literal 1e6 as the divisor of mul_u64_u32_div(). While
the compiler constant-folds this to an integer, using float literals
in kernel code is bad practice since the kernel generally avoids
floating-point operations.
Replace 1e6 with the standard NSEC_PER_MSEC macro from <linux/time64.h>,
which is both self-documenting (ns to ms conversion) and unambiguously
integer. Add the corresponding include rather than relying on
transitive inclusion.
Shuicheng Lin [Mon, 11 May 2026 15:41:34 +0000 (15:41 +0000)]
drm/xe/gsc: Fix double-free of managed BO in error path
The error path in xe_gsc_init_post_hwconfig() explicitly frees a BO
allocated with xe_managed_bo_create_pin_map() via
xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm
cleanup action registered, this causes a double-free when devm
unwinds during probe failure.
Remove the explicit free and let devm handle it, consistent with
all other xe_managed_bo_create_pin_map() callers.
Fixes: 2e5d47fe7839 ("drm/xe/uc: Use managed bo for HuC and GSC objects") Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Assisted-by: Claude:claude-opus-4.6 Link: https://patch.msgid.link/20260511154134.223696-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Michal Wajdeczko [Mon, 11 May 2026 17:28:38 +0000 (19:28 +0200)]
drm/xe/memirq: Enable GT_MI_USER_INTERRUPT only
We only expect and handle the GT_MI_USER_INTERRUPT from the
engines, there is no point in enabling other interrupts, like
GT_CONTEXT_SWITCH_INTERRUPT, if we don't intent to handle them.
Michal Wajdeczko [Mon, 11 May 2026 17:28:37 +0000 (19:28 +0200)]
drm/xe/memirq: Update interrupt handler logic
To workaround some corner case hardware limitations, new programming
note for the memory based interrupt handler suggests to assume that
some status bytes, like GT_MI_USER_INTERRUPT and GUC_INTR_GUC2HOST,
are always set. Update our interrupt handler to follow the new rules.
Bspec: 53672 Fixes: a6581ebe7685 ("drm/xe/vf: Introduce Memory Based Interrupts Handler") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260511172838.2299-2-michal.wajdeczko@intel.com
drm/xe: Refactor emit_xy_fast_copy and emit_mem_copy functions
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.
Implement a function to return the length of the MEM_SET instruction.
This is to prepare for future platforms where the length of MEM_SET
instruction is expected to change.
Implement a function which returns the length of XY_FAST_COLOR_BLT
instruction instead of hardcoding it inside the emit_clear_main_copy.
In future platforms, the length of this instruction is expected to
change and this patch helps in preparing for it.
Shekhar Chauhan [Tue, 12 May 2026 05:55:08 +0000 (11:25 +0530)]
drm/xe/devcoredump: Drop a FIXME in devcoredump
The FIXME says that xe_engine_snapshot_print.. is accessing persistent
driver data, unlike what the FIXME says that it does. Drop the FIXME
since the current code is not going to access the hardware while
dumping.
More details about this patch:
https://patchwork.freedesktop.org/patch/703884/?series=161407&rev=1
The starting two feedbacks make sense and the original patch is wrong
in adding those changes, but the last feedback is the one which
highlights the point.
Ashutosh Dixit [Thu, 30 Apr 2026 16:14:58 +0000 (09:14 -0700)]
drm/xe/oa: Add val arg to xe_oa_is_valid_config_reg
Add val arg to xe_oa_is_valid_config_reg so that register values can also
be verified, in addition to register address. Value verification is needed
to implement MERTOA Wa_14026779378.
Matthew Auld [Fri, 8 May 2026 10:26:37 +0000 (11:26 +0100)]
drm/xe/dma-buf: fix UAF with retry loop
Retry doesn't work here, since bo will be freed on error, leading to
UAF. However, now that we do the alloc & init before the attach, we can
now combine this as one unit and have the init do the alloc for us. This
should make the retry safe.
Reported by Sashiko.
v2: Fix up the error unwind (CI)
Closes: https://sashiko.dev/#/patchset/20260506184332.86743-2-matthew.auld%40intel.com Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260508102635.149172-4-matthew.auld@intel.com
Matthew Auld [Fri, 8 May 2026 10:26:36 +0000 (11:26 +0100)]
drm/xe/dma-buf: handle empty bo and UAF races
There look to be some nasty races here when triggering the
invalidate_mappings hook:
1) We do xe_bo_alloc() followed by the attach, before the actual full bo
init step in xe_dma_buf_init_obj(). However the bo is visible on the
attachments list after the attach. This is bad since exporter driver,
say amdgpu, can at any time call back into our invalidate_mappings hook,
with an empty/bogus bo, leading to potential bugs/crashes.
2) Similar to 1) but here we get a UAF, when the invalidate_mappings
hook is triggered. For example, we get as far as xe_bo_init_locked()
but this fails in some way. But here the bo will be freed on error, but
we still have it attached from dma-buf pov, so if the
invalidate_mappings is now triggered then the bo we access is gone and
we trigger UAF and more bugs/crashes.
To fix this, move the attach step until after we actually have a fully
set up buffer object. Note that the bo is not published to userspace
until later, so not sure what the comment "Don't publish the bo
until we have a valid attachment", is referring to.
We have at least two different customers reporting hitting a NULL ptr
deref in evict_flags when importing something from amdgpu, followed by
triggering the evict flow. Hit rate is also pretty low, which would
hint at some kind of race, so something like 1) or 2) might explain
this.
v2:
- Shuffle the order of the ops slightly (no functional change)
- Improve the comment to better explain the ordering (Matt B)
In a multi-queue use case, when a job is running on the secondary queue,
the CTX_TIMESTAMP does not reflect the queues run ticks. Instead, we use
the QUEUE TIMESTAMP to check how long the job ran. For user space to see
the run ticks for a secondary queue, whitelist the QUEUE_TIMESTAMP
register.
drm/xe/multi_queue: Capture queue run times for active queues
If a queue is currently active on the CS, query the QUEUE TIMESTAMP
register to get an up to date value of the runtime. To do so, ensure
that the primary queue is active and then check if the secondary queue
is executing on the CS.
drm/xe/multi_queue: Add helpers to access CS QUEUE TIMESTAMP from lrc
In secondary queue LRCs, the QUEUE TIMESTAMP register is saved and
restored allowing us to view the individual queue run times. Add helpers
to read this value from the LRC.
drm/xe/multi_queue: Store primary LRC and position info in LRC
For an LRC belonging to the secondary queue, in order to check if its
context group is active, we need to check the LRC of the primary queue.
In addition to that we want to compare the secondary queue position to
CSMQDEBUG register to check if the queue itself is active.
To do so, store primary LRC and position information in the LRC.
A note on references involved:
- In general the Queue takes a ref on its LRC.
- In addition, for multi-queue,
a. Primary Queue takes a ref for each Secondary LRC.
b. Each Secondary Queue takes a ref to the Primary Queue
In the current patch, each LRC in the queue group is storing a pointer
to primary LRC. Both primary and secondary LRCs are freed only when
primary queue is destroyed. At this time, all secondary queues are
already destroyed, so there is no one using secondary LRCs. We should be
good without taking any additional references.
drm/xe/multi_queue: Refactor check for multi queue support for engine class
xe exec queue code is using a check to see if a class of engines support
multi queue. This check is also needed by other code, so move it to
xe_gt and export it for others.
Matthew Brost [Thu, 7 May 2026 16:20:19 +0000 (09:20 -0700)]
drm/xe: Add timestamp_ms to LRC snapshot
Add a timestamp in milliseconds to the LRC snapshot to make it easier to
reason about how long the LRC has been running and the average duration
of each job.
drm/xe/eustall: Return ENODEV from read if EU stall registers get reset
If a reset (GT or engine) happens during EU stall data sampling, all the
EU stall registers can get reset to 0. This will result in EU stall data
buffers' read and write pointer register values to be out of sync with
the cached values. This will result in read() returning invalid data. To
prevent this, check the value of a EU stall base register. If it is zero,
it indicates a reset may have happened that wiped the register to zero.
If this happens, return ENODEV from read() upon which the user space
should disable and enable EU stall data sampling or close the fd and
open a new fd for a new EU stall data collection session.
This patch has been tested by running two IGT tests simultaneously
xe_eu_stall and xe_exec_reset.
Factor the repeated CGP_SYNC action build-and-send sequence into a new
helper guc_exec_queue_send_cgp_sync(). Drop the redundant guc parameter
from __register_exec_queue_group() since it can be derived via
exec_queue_to_guc(q). Remove xe_guc_exec_queue_group_add() which is now
identical to the helper and replace its call site directly.
Matt Roper [Thu, 7 May 2026 21:00:15 +0000 (14:00 -0700)]
drm/xe: Make decision to use Xe2-style blitter instructions a feature flag
The blitter engines' MEM_COPY and MEM_SET instructions were added as
part of the same hardware change that introduced service copy engines
(i.e., BCS1-BCS8) which is why the driver checks for service copy engine
presence when deciding whether to use these instructions or the older
XY_* instructions. However when making this decision the driver should
consider which engines are part of the hardware architecture, not which
engines are present/usable on the current device. For graphics IP
versions that architecturally include service copy engines (i.e.,
everything Xe2 and later, plus PVC's Xe_HPC) we should use MEM_SET and
MEM_COPY even in if all of the service copy engines wind up getting
fused off. I.e., we need to decide based on whether the platform's
graphics descriptor contains these engines, rather than whether the
usable engine mask contains them. This logic got broken when
gt->info.__engine_mask was removed, although in practice that mistake
has been harmless so far because there haven't been any hardware
SKUs that fuse off all of the service copy engines yet.
Replace the incorrect has_service_copy_support() function with a GT
feature flag that tracks more accurately whether the new blitter
instructions are usable. In addition to fixing incorrect logic if all
service copies are fused off, the flag also makes it more obvious what
the calling code is trying to do; previously it wasn't terribly obvious
why "has service copy engines" was being used as the condition for using
different instructions on all copy engine types.
The new feature flag is named 'has_xe2_blt_instructions' because we
expect this flag to be set for all Xe2 and later platforms (i.e.,
everything officially supported by the Xe driver). Technically there's
also one Xe1-era platform (PVC) that supports these engines/instructions
and will set this flag, but this still seems to be the most clear and
understandable name for the flag.
Fixes: 61549a2ee594 ("drm/xe: Drop __engine_mask") Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20260507-xe2_copy-v1-1-26506381b821@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
drm/xe: Convert stolen memory over to ttm_range_manager
Stolen memory requires physically contiguous allocations for display
scanout and compressed framebuffers. The stolen memory manager was
sharing the gpu_buddy allocator backend with the VRAM manager, but
buddy manages non-contiguous power-of-two blocks making it a poor fit.
Stolen memory also has fundamentally different allocation patterns:
- Allocation sizes are not power-of-two. Since buddy rounds up to the
next power-of-two block size, a ~17MB request can fail even with
~22MB free, because the free space is fragmented across non-fitting
power-of-two blocks.
- Hardware restrictions prevent using the first 4K page of stolen for
certain allocations (e.g., FBC). The display code sets fpfn=1 to
enforce this, but when fpfn != 0, gpu_buddy enables
GPU_BUDDY_RANGE_ALLOCATION mode which disables the try_harder
coalescing path, further reducing allocation success.
This combination caused FBC compressed framebuffer (CFB) allocation
failures on platforms like NVL/PTL. In case of NVL where stolen memory
is ~56MB and the initial plane framebuffer consumes ~34MB at probe time,
leaving ~22MB for subsequent allocations.
Use ttm_range_man_init_nocheck() to set up a drm_mm-backed TTM resource
manager for stolen memory. This reuses the TTM core's ttm_range_manager
callbacks, avoiding duplicate implementations.
Tested on NVL with a 4K DP display: stolen_mm shows a single ~22MB
contiguous free hole after initial plane framebuffer allocation, and
FBC successfully allocates its CFB from that region. The corresponding
IGT was previously skipped and now passes.
v2:
- Clarify that stolen memory requires contiguous allocations (Matt B)
- Properly handle xe_ttm_resource_visible() for stolen instead of
unconditionally returning true (Matt A)
v3:
- Rebase
- Fix xe_display_bo_fbdev_prefer_stolen() to compare in pages, since
ttm_range_manager stores stolen->size in pages not bytes (Matt A)
v4:
- Add kernel-doc for struct xe_ttm_stolen_mgr (Matt B)
Arvind Yadav [Wed, 6 May 2026 13:20:27 +0000 (18:50 +0530)]
drm/xe/madvise: Track purgeability with BO-local counters
xe_bo_recompute_purgeable_state() walks all VMAs of a BO to determine
whether the BO can be made purgeable. This makes VMA create/destroy and
madvise updates O(n) in the number of mappings.
Replace the walk with BO-local counters protected by the BO dma-resv
lock:
- vma_count tracks the number of VMAs mapping the BO.
- willneed_count tracks active WILLNEED holders, including WILLNEED
VMAs and active dma-buf exports for non-imported BOs.
A DONTNEED BO is promoted back to WILLNEED on a 0->1 transition of
willneed_count. A BO is demoted to DONTNEED on a 1->0 transition only
when it still has VMAs, preserving the previous behaviour where a BO
with no mappings keeps its current madvise state.
Fixes: 4f44961eab84 ("drm/xe/vm: Prevent binding of purged buffer objects")
v2:
- Use early return for imported BOs in all four helpers to avoid
nesting (Matt B).
- Group purgeability state into a purgeable sub-struct on struct
xe_bo (Matt B).
- Reword xe_bo_willneed_put_locked() kernel-doc to explain that a 1->0
transition means all remaining active VMAs are DONTNEED (Matt B).
v3:
- Move DONTNEED/PURGED reject from vma_lock_and_validate() into
xe_vma_create(), gated on attr->purgeable_state == WILLNEED.
Fixes vm_bind bypass and partial-unbind rejection on DONTNEED
BOs (Matt B).
- Drop .check_purged from MAP and REMAP; keep it for PREFETCH and
add a comment why (Matt B).
- Skip BO validation in vma_lock_and_validate() for non-WILLNEED
VMA remnants so cleanup/remap paths do not repopulate
DONTNEED/PURGED BOs.
Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260506132027.2556046-1-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Dave Airlie [Fri, 8 May 2026 04:14:24 +0000 (14:14 +1000)]
Merge tag 'drm-misc-next-2026-05-07' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for v7.2-rc1:
UAPI Changes:
- Support medium/low power modes in amdxdna.
- Support limiting frequency in ivpu.
- Document license for drm core uAPI headers.
- Add the following DRM formats: P230, Y7, XYYY2101010, T430,
XVUY210101010.
Core Changes:
- Do not call drop_master on file close if not master.
- Convert drm-bridge and drm/atomic to use drm_printf_indent.
- Remove the extra call to drm_connector_attach_encoder after
drm_bridge_connector_init().
- Assorted docbook updates.
Driver Changes:
- Bugfixes in amdxdna, ivpu, mipi-dsi, imagination, nouveau, panthor,
bridge/analogix_dp, ipv3, lontium-lt8912b, verisilicon, tve200,
etnaviv, panel/focaltech-ota7290b, panel/jadard-jd9365da-h3,
bridge/ite-it6263, renesas, xlnx, bridge/cdns-dsi, gma500,
bridge/microchip-lvds, mgag200.
- Add support for MStar TSUMU88ADT3-LF-1 bridge.
- Add support for WaveShare 7, Novatek NT35532, Startek KD070HDFLD092,
ChipWealth CH13726A AMOLED, Team Source Display TST070WSNE-196C,
Displaytech DT050BTFT-PTS panels.
- Improve mipi-dsi shutdown and convert a panasonic panel to use the
mipi-dsi wrappers.
- Allowing dumping vbios over debugfs in GSP-RM mode.
- Update maintainers for ivpu, add reviewer for drm-bridge code
and update maintainers for LT8912B DRM HDMI bridge.
- Add test pattern support to bridge/ti-sn65dsi83.
- Convert vmwgfx to vblank timers.
- Add power management to sysfb drm drivers to allow suspend/resume.
- Support the aforementioned new drm formats in xlnx/qynqmp.
- Fix panel Kconfig dependencies.
- Add carveout support for debugging and bringup to amxdna.
- Add support for long command tx via videobuffer in bridge/tc358768.
Tomi Valkeinen [Wed, 11 Mar 2026 07:48:18 +0000 (09:48 +0200)]
drm/bridge: tc358768: Add support for long command tx via video buffer
TC358768 has two ways to send DSI commands: 1) buffer the payload data
into registers (DSICMD_WDx), which supports up to 8 bytes of payload, 2)
buffer the payload data into the video buffer, which supports up to 1024
bytes of payload.
The driver currently supports method 1).
Add support for transmitting long DSI commands (more than 8 bytes, up to
1024 bytes) using the video buffer. This mode can only be used before
the actual video transmission is enabled, i.e. the initial configuration.
Original version from Parth Pancholi <parth.pancholi@toradex.com>
Tomi Valkeinen [Wed, 11 Mar 2026 07:48:17 +0000 (09:48 +0200)]
drm/bridge: tc358768: Separate video format config
Sending long commands using the video buffer (to be implemented in
following patches) requires setting TC358768_DATAFMT and
TC358768_DSITX_DT registers for command transfer. The same registers
also need to be configured properly for video transfer.
The long commands will be sent between the bridge's pre_enable() and
enable(), and currently we configure the registers for video transfer in
pre_enable(). Thus, they would be overwritten by the long command
transfer code.
To prevent that from happening, set those registers for video transfer
in enable(), not in pre_enable().
Based on code from Parth Pancholi <parth.pancholi@toradex.com>
Tomi Valkeinen [Wed, 11 Mar 2026 07:48:16 +0000 (09:48 +0200)]
drm/bridge: tc358768: Add LP mode command support
Currently the driver ignores MIPI_DSI_MODE_LPM and always uses HS mode.
Add code to enable HS mode in pre_enable() only if MIPI_DSI_MODE_LPM is
not set, and always enable HS mode in enable() for video transmission.
Tomi Valkeinen [Wed, 11 Mar 2026 07:48:15 +0000 (09:48 +0200)]
drm/bridge: tc358768: Support non-continuous clock
The driver prints a warning if MIPI_DSI_CLOCK_NON_CONTINUOUS is set, and
falls back to continuous clock mode. This was added in commit fbc5a90e82c1 ("drm/bridge: tc358768: Disable non-continuous clock mode").
However, there have been multiple changes to the driver since then, and
at least in my setup, non-continuous clock mode works: I can see an
image on the panel, and I can see the clock lanes being non-continuous
with an oscilloscope.
So, let's enable MIPI_DSI_CLOCK_NON_CONTINUOUS support.
Cc: Dmitry Osipenko <digetx@gmail.com> Tested-by: João Paulo Gonçalves <joao.goncalves@toradex.com> # Toradex Verdin AM62 Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Dmitry Osipenko <digetx@gmail.com> Link: https://patch.msgid.link/20260311-tc358768-v2-4-e75a99131bd5@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi Valkeinen [Wed, 11 Mar 2026 07:48:14 +0000 (09:48 +0200)]
drm/bridge: tc358768: Separate indirect register writes
Some registers can only be written indirectly, using DSI_CONFW register.
We don't have many uses for those registers (in fact, only DSI_CONTROL
is currently written), but the code to do those writes inline is a bit
confusing.
Add a new function, tc358768_confw_update_bits() which can be used to
write the bits indirectly. Only DSI_CONTROL is currently supported.
Parth Pancholi [Wed, 11 Mar 2026 07:48:13 +0000 (09:48 +0200)]
drm/bridge: tc358768: Set pre_enable_prev_first for reverse order
Enable the pre_enable_prev_first flag on the tc358768 bridge to reverse
the pre-enable order, calling bridge pre_enable before panel prepare.
This ensures the bridge is ready before sending panel init commands in
the case of panels sending init commands in panel prepare function.
Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com> Tested-by: João Paulo Gonçalves <joao.goncalves@toradex.com> # Toradex Verdin AM62 Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20260311-tc358768-v2-2-e75a99131bd5@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Shuicheng Lin [Fri, 1 May 2026 17:59:56 +0000 (17:59 +0000)]
drm/gpusvm: Drop redundant @flags.* kernel-doc on struct drm_gpusvm_pages
The kernel-doc block above struct drm_gpusvm_pages duplicates the
descriptions of the bit-flags that live in struct drm_gpusvm_pages_flags
using dotted notation (@flags.migrate_devmem, @flags.unmapped, ...).
That dotted notation is intended for nested anonymous structs/unions that
the parser flattens into the parent's parameter list. Here, however,
flags is of a named external type, so the parser does not flatten its
members and the dotted entries do not match any member of
drm_gpusvm_pages. They also duplicate the canonical descriptions already
present in the kernel-doc of struct drm_gpusvm_pages_flags itself.
Drop the five @flags.* lines and replace them with a single @flags entry
that cross-references the type via kernel-doc's "&struct ..." syntax.
This eliminates the redundancy and removes warnings emitted by the new
parameterdescs check in scripts/kernel-doc:
Excess struct member 'flags.migrate_devmem' description in
'drm_gpusvm_pages'
Excess struct member 'flags.unmapped' description in 'drm_gpusvm_pages'
Excess struct member 'flags.partial_unmap' description in
'drm_gpusvm_pages'
Excess struct member 'flags.has_devmem_pages' description in
'drm_gpusvm_pages'
Excess struct member 'flags.has_dma_mapping' description in
'drm_gpusvm_pages'
No functional change.
Assisted-by: Claude:claude-opus-4.6 Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260501175956.4054088-1-shuicheng.lin@intel.com
projects / linux / log