| Age | Commit message (Collapse) | Author |
|---|
|
This version brings along following update:
-Fix root clock disabled when DSC power gate disabled for DCN314
-Enable/Disable some power gating
-Remove Mall, SubVP and MCLK from DCN42
-Unify fast update classification paths
-Fix narrowing boundaries in dml
-Update MCIF_ADDR macro to address IGT DWB regression
-Fix dual cursor shows on extend desktop
-Fix hubp tmz field define mismatch
Acked-by: Alex Hung <Alex.Hung@amd.com>
Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
Modify some IPS related commands.
Acked-by: Alex Hung <Alex.Hung@amd.com>
Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
When set debug.disable_dsc_power_gate = true, the original code
uses an early return to skip the power gate sequence and root
clock enable and disable.
For this case, install new driver without uninstall old driver.
The sequence like below:
1. On the power-off path, the old driver will power gate dsc and
disable_dsc() (root clock disable) due to
debug.disable_dsc_power_gate = false.
2. On the power-on path, the new driver will force power on dsc but skip
enable_dsc() (root clock enable) due to
debug.disable_dsc_power_gate = true.
Finally, when mode needs DSC but the root clock is disabled, underflow
happened.
[How]
- Moving enable_dsc() before the disable_dsc_power_gate check so the
root clock is always enabled on the power-on path.
- Replacing the early return with a goto that skips only the power gate
register writes, allowing disable_dsc() to still execute on the
power-off path.
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Signed-off-by: Jing Zhou <Jing.Zhou@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
Disable HPO power gate temporarily to
work around some DP 2 LL compliance failures on DCN42.
Reviewed-by: Roman Li <roman.li@amd.com>
Signed-off-by: Leo Chen <leo.chen@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why&How]
Remove MALL, SubVP and MCLK features from DCN42 resource file since it is
an APU and does not support them.
Assisted-by: Claude:opus-4.6
Reviewed-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
The dc_fast_update intermediate struct created code duplication and
complexity with multiple classification paths (populate_fast_updates,
fast_nonaddr_updates_exist, full_update_required). This refactoring
simplifies the update classification system by consolidating to a
single path while maintaining compatibility and adding comprehensive
test coverage for fast sequence functionality.
[How]
Remove entire dc_fast_update struct and associated helper functions:
- populate_fast_updates
- fast_nonaddr_updates_exist
- full_update_required
and
- Refactor check_update_surfaces_for_stream as the
single classification path with explicit handling for func_shaper,
lut3d_func, cursor_csc_color_matrix_change and
scaler_sharpener_update.
- Add reserved bitfields to surface_update_flags and
stream_update_flags unions for completeness guards.
- Extract dc_check_address_only_update and
dc_check_update_surfaces_for_stream as public.
- Add comprehensive test coverage with parameterized tests for all
FAST flags, update classification tests for MED/FULL paths,
and completeness guard tests.
Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
Signed-off-by: Rafal Ostrowski <rafal.ostrowski@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
DML code paths include implicit integer narrowing at protocol and
storage boundaries. Making these boundaries explicit improves clarity
and reduces warning noise while preserving behavior.
[How]
Apply explicit C-style casts at intentional narrowing boundaries
across DML calculation, mode support, RQ/DLG, wrapper, and DSC
helper paths.
Keep intermediate arithmetic in natural-width types where practical,
with minor type-consistency cleanups where needed. Add explicit
boundary casts for intentional narrowing and keep intermediate math
in wider types where practical, with small type-consistency cleanups
to maintain behavior and readability.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The KFD CRIU restore flow restores previously saved object IDs from
userspace.
For event restore:
kfd_criu_restore_event()
-> create_signal_event() / create_other_event()
-> allocate_event_notification_slot()
-> idr_alloc(..., *restore_id, *restore_id + 1, ...)
For BO restore:
criu_restore_memory_of_gpu()
-> idr_alloc(..., bo_priv->idr_handle, ...)
In both cases, the restored ID comes from userspace-provided CRIU data.
idr_alloc() expects the ID range values to fit within signed int
limits. If a restored ID is larger than INT_MAX, it can trigger a WARN
in the IDR layer.
A kernel WARN is undesirable because it prints a warning trace and may
cause a panic or reboot on systems with panic_on_warn enabled.
Smatch reported these paths as allowing unchecked userspace values to
reach idr_alloc().
Add INT_MAX validation before using restored IDs in:
- kfd_criu_restore_event()
- criu_restore_memory_of_gpu()
If the restored ID is invalid, return -EINVAL.
This prevents invalid restore data from reaching the IDR layer and
avoids WARN-triggering paths, while keeping valid restore behavior
unchanged.
Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Felix Kuehling <Felix.Kuehling@amd.com>
Cc: David Yat Sin <david.yatsin@amd.com>
Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: David Yat Sin <david.yatsin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Move more code into a common userq function.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Sunil Khatri <sunil.khatri@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The read_indexed_register helper is duplicated across multiple files
with identical logic.
Move it to amdgpu_reg_access.c as
amdgpu_read_indexed_register and update all users accordingly.
No functional changes intended.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Gabriel Almeida <gabrielsousa230@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The program_aspm helper is duplicated across multiple files with
identical logic.
Move it to amdgpu_nbio.c as amdgpu_nbio_program_aspm and update
all users accordingly.
Signed-off-by: Gabriel Almeida <gabrielsousa230@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
Enable driver power gating on DCN42 for HUBP OPTC
and DPP HW blocks.
Reviewed-by: Ovidiu Bunea <ovidiu.bunea@amd.com>
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Leo Chen <leo.chen@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
Fix implicit narrowing conversion warnings.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
A previous warning-fix commit updated type casts in the DCN3
mmhubbub code but missed updating the MCIF_ADDR macro to the
correct, fully parenthesized and casted version. This caused
a regression during DWB tests, where address values could be
misinterpreted, potentially leading to incorrect hardware
programming.
[How]
Updated the MCIF_ADDR macro in dcn30_mmhubbub.c to use the
proper parenthesization and type casting, ensuring correct
address handling. Removed redundant casts from REG_UPDATE
calls for improved clarity and consistency with current
coding standards.
Fixes: f4cdbb5d5405 ("drm/amd/display: Fix implicit narrowing conversion warnings")
Reviewed-by: Clayton King <clayton.king@amd.com>
Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why & how]
when dpp pipe power gating disabled in driver, disable_pipe
did not disable cursor so next time as long as this pipe
powers up, it will be visible.
port dcn314 logic: disable cursor when it should be pipe pg.
Reviewed-by: Roman Li <roman.li@amd.com>
Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why & how]
to make hubp surface_flip_registers field define mismatch
with dc_plane_address
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Reviewed-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
Enable driver power gating. Temporarily disable DIO power gating.
Reviewed-by: Ovidiu Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Leo Chen <leo.chen@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Currently, VRR is not implmented for DP branch devices.
So skip sending AS SDP for them.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260424090942.3060291-4-ankit.k.nautiyal@intel.com
|
|
Add a helper that determines whether AS SDP can be used for the
current DP configuration. For now this is true only when the sink
supports AS SDP and VRR is enabled, but more conditions may be added
later.
v2:
- Rename to intel_dp_needs_as_sdp(). (Ville)
- Add a #FIXME documenting non-atomic of DP SDP updates. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260424090942.3060291-3-ankit.k.nautiyal@intel.com
|
|
Currently we do not support VRR with HDMI so skip vrr compute
config step for all DP branch devices.
v2: Restrict VRR on all DP branch devices instead for checking only for
HDMI. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260424090942.3060291-2-ankit.k.nautiyal@intel.com
|
|
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251031102020.95349-3-marco.crivellari@suse.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
Adding system_dfl_wq to encourage its use when unbound work should be used.
The old system_unbound_wq will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20251031102020.95349-2-marco.crivellari@suse.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
[WHY]
A situation has occurred where udl_handle_damage() executed successfully
and the kernel log appears normal, but the display fails to show any output.
This is because the call to udl_get_urb() in udl_crtc_helper_atomic_enable()
failed without generating any error message.
[HOW]
1. Increase timeout of getting urb.
2. Add error messages when calling udl_get_urb() failed in
udl_crtc_helper_atomic_enable().
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)")
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: <stable@vger.kernel.org> # v3.4+
Link: https://patch.msgid.link/20260424124427.657-1-oushixiong1025@163.com
|
|
xe_gt_suspend_prepare() doesn't perform any MMIO operation that requires
forcewake in it's code path. Drop it.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>$
Link: https://patch.msgid.link/20260427092928.1181893-4-raag.jadav@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
xe_guc_pc_stop() doesn't perform any MMIO operation that requires
forcewake in it's code path. Move it before pc_set_cur_freq() which
writes to RPNSWREQ and actually requires it.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260427092928.1181893-3-raag.jadav@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
xe_guc_pc_stop() doesn't return any meaningful value. Refactor it into
void function.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260427092928.1181893-2-raag.jadav@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
On all platforms supported by the Xe driver, BCS engines are part of the
GT forcewake domain, not the RENDER domain. Fix the engine list
definition to match the spec. This mistake didn't really cause any
real problems because the forcewake domain here was only used in a
couple assertions that aren't really necessary and included in the
information dumped during error capture.
Bspec: 66696, 66534, 67609, 71185, 74417, 75242, 78286
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-10-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
xe_hw_engine_mmio_write32() is only used in a single place and is easily
replaced by a regular xe_mmio_write32() call. Register read/write
interfaces are already complicated enough with MCR vs non-MCR handling,
so we should avoid adding extra wrappers that just make it more
confusing what to use.
xe_hw_engine_mmio_write32() did have a forcewake assertion that we're
dropping here, but that assertion wasn't entirely correct anyway. It was
checking hwe->domain which is currently set to XE_FW_RENDER for the BCS
engine, even though BCS engines reside in the GT domain.
v2:
- Drop prototype in header file as well. (Shuicheng)
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-9-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
The STOP_RING bit in MI_MODE is already clear by default out of hardware
reset and will only be '1' if the driver intentionally sets it after
that.
The logic of clearing this bit appears to originate from very
early (pre-GuC, pre-execlist) code in i915 where we needed to stop the
ring before performing a host-initiated engine reset; after the reset
the STOP_RING bit needed to be cleared to allow execution to resume.
None of that is relevant to Xe (or even modern i915) since STOP_RING
isn't necessary for execlist-based engine resets (and even if it were,
Xe doesn't initiate any engine resets; the GuC handles that now).
Bspec: 60356, 60184
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-8-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
The write GFX_MODE to disable engine "legacy mode" and to enable MSI-X
support was unnecessarily open-coded in xe_hw_engine_enable_ring();
it's preferable to do such programming in the engine_entries[] RTP table
since gets reflected/verified in debugfs, and will also automatically
ensure that the register is properly saved/restored around engine
resets. This also helps consolidate common logic that was duplicated
between the main driver initialization path and the dead-code execlist
initialization path.
This also allows us to drop GFX_MODE from the list of extra registers to
be added to the GuC ADS' save-restore list since all registers on the
RTP table are added automatically.
v2:
- Actually use the xe_rtp_match_has_msix match function added.
(Shuicheng)
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-7-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
None of these functions modify the Xe device parameter, and marking it
as const will avoid warnings when the callsite wants to pass a const
pointer.
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-6-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
The register located at $base+0x29c is referred to as GFX_MODE in the
bspec. Although many other registers have RING_* prefixes for
historical reasons, this register does not, so using a name that does
not match the bspec just makes it harder to recognize/find.
Also, GFX_MODE is a masked register (updating bits [15:0] requires that
the corresponding bit(s) in [31:16] are also set), so add the
XE_REG_OPTION_MASKED flag to the register definition; this will become
important when we start programming this register via RTP tables in a
future patch.
Finally swap the order of the register's two bit definitions to match
our regular coding style of descending order for register bits/fields.
Bspec: 45928
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-5-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
The write to RING_HWSTAM to disable hardware status page writes on
interrupt was unnecessarily open-coded in xe_hw_engine_enable_ring();
it's preferable to do such programming in the engine_entries[] RTP table
since gets reflected/verified in debugfs, and will also automatically
ensure that the register is properly saved/restored around engine
resets.
In this case the HWSTAM register wasn't explicitly added to the GuC ADS'
save-restore list, so there was the potential for the value to be lost
on engine resets. This doesn't seem to have happened in practice, so
likely the GuC firmware is automatically saving/restoring this register
on our behalf, but we shouldn't rely on this implicit behavior going
forward.
One other slight change with this patch is that HWSTAM will now be
programmed on the vestigial execlist (non-GuC) initialization path.
Since the register's default value is 0x0 and the documentation
indicates that it's only legal to leave a single bit unmasked at a time,
this likely would have been an illegal situation if the execlist code
were actually usable.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-4-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
Xe1 platforms used the BLIT_CCTL register to specify the MOCS value that
would be used for BCS engine instructions that did not have a way of
specifying a MOCS index directly. From Xe2 onward, all BCS instructions
now have explicit instruction fields for specifying a MOCS index and the
BLIT_CCTL register is now a dummy register with no valid fields.
Although continuing to write to it today has no effect, the register
could repurposed in future platforms, so restrict the BLIT_CCTL RTP
entry to only apply to Xe1 platforms.
Bspec: 60280
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-3-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
All RTP table entries are required to have at least one rule. In cases
where an entry should apply unconditionally across all platforms we've
been using a graphics version range of 12.00 - forever since this covers
all platforms supported by the driver. However if the primary GT is
disabled via configfs (not actually possible today, but probably
possible in the future) or if we have a future platform that lacks a
primary GT and only supports media/display, this rule would cause
important programming to fail to apply on the media GT.
Add a simple match function that just always returns true
unconditionally. This solves the worries above while also being more
immediately human-readable.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-2-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
Most register programming for engine setup happens via RTP tables in
hw_engine_setup_default_state(). Move the programming of RCU_MODE[0]
which enables the platform's CCS engine(s) there. This both makes the
code more consistent (other RCU_MODE register programming is already
happening in this RTP table) and improves debuggability (since RTP
contents and checks of their correct programming are exposed via
debugfs). It also helps consolidate the regular driver initialization
paths with the vestigial and currently unused execlist (i.e., non-GuC)
initialization.
With the original programming, the RCU_MODE register (which is a single
global register, not a per-engine register) was getting re-programmed
with the same value during the initialization of each CCS engine. When
moved to the RTP table, we use the xe_rtp_match_first_render_or_compute
match function so that it will just be programmed once, while doing the
initialization for the first RCS/CCS engine, which avoids the redundant
and unnecessary repetition.
We can also safely drop the explicit addition of RCU_MODE from the GuC
ADS save-restore list now since all registers programmed via RTP tables
are automatically added to the GuC's list.
v2:
- Only enable CCS engines on Xe_HP and later. Even though Xe_LP
platforms technically have a CCS engine, it's never been enabled on
i915 or Xe due to other issues on these old platforms.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-1-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
Although the bspec currently indicates that steered reads/writes to L3
register ranges are never terminated for physically present instances
(regardless of fusing) on Xe2, it turns out this is information is
incorrect. The hardware architects have also confirmed that the current
documentation is wrong (or that possibly the wording was intended to be
interpreted in a different way), but have not yet provided an official
spec update.
All of our driver's writes to registers in these ranges are done as
multicast, so steering is not actually important to proper driver
operation; the only impact of this documentation mistake is that on some
fused-down SKUs where the first L3 bank is absent we're not able to
properly read back the values that were written to those registers to
confirm that the writes were applied correctly (e.g., when using the
register-save-restore-check debugfs interface).
Since we don't have an official spec update yet, let's assume that
Xe2/Xe3 use the same fuse => steering logic as Xe3p. I.e., remove
L3BANK and NODE register ranges from the "INSTANCE0" steering group and
add handle them with dedicated handling according to the L3 fuses. From
testing on various fused-down platforms this does appear to give proper
steering and fix the failures reported by IGT's
igt@xe_debugfs@check-gt-reg-sr test.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7706
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patch.msgid.link/20260421-xe2_l3bank_steering-v1-1-613158a27383@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
DOORBELL_BLOCK_n[0-63] is an array of GPU control register pages.
Each block is memory-mappable and contains a single DOORBELL register
used to trigger actions in the GPU.
Add definitions for the DOORBELL_BLOCK registers using the register! macro
so they can be used by future Tyr interfaces.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-6-8abfff8a0204@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
Now that Tyr uses the register! macro, it no longer needs to define a
custom register struct or read/write functions, so delete them.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-5-8abfff8a0204@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
Define the MMU_CONTROL register block with the kernel's register! macro
and replace the existing hand-written MMU register definitions with typed
register and field accessors.
This adds typed definitions for the MMU IRQ registers and the per-address
space MMU_AS_CONTROL registers, including TRANSTAB, MEMATTR, LOCKADDR,
COMMAND, FAULTSTATUS, STATUS, and TRANSCFG. It also introduces typed
enums for MMU commands, fault types, access types, address space modes,
memory attributes, and related MMU configuration fields.
For logical 64-bit MMU registers that are exposed as split 32-bit MMIO
registers, define both the typed 64-bit view and explicit low/high 32-bit
registers so the register layout remains documented without relying on
native 64-bit MMIO accesses.
This reduces open-coded bit manipulation, keeps MMU register layout
knowledge in one place, and makes the definitions easier to read and
maintain.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-4-8abfff8a0204@collabora.com
[aliceryhl: reformat long comment]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
Define the JOB_CONTROL register block with the kernel's register! macro
and replace the existing hand-written JOB IRQ register definitions with
typed register and field accessors.
This adds typed definitions for the raw status, clear, mask, and status
registers, including the per-CSG interrupt bits and the global interface
interrupt bit.
This reduces open-coded bit manipulation, keeps the JOB_CONTROL register
layout in one place, and makes the definitions easier to read and
maintain.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-3-8abfff8a0204@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
Currently, Tyr prints just the upper 16 bits of the GPU_ID in the hex id
field, namely ARCH_MAJOR, ARCH_MINOR, ARCH_REV, and PRODUCT_MAJOR. The
VERSION_* fields are already printed separately as "major", "minor", and
"status".
Print the full 32-bit GPU_ID register instead of shifting it, so the hex
id reflects the complete register contents.
Before this change:
mali-g610 id 0xa867 major 0x0 minor 0x0 status 0x5
After this change:
mali-g610 GPU_ID 0xa8670005 major 0x0 minor 0x0 status 0x5
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-2-8abfff8a0204@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
Define the GPU_CONTROL register block with the kernel's register! macro
and switch the current GPU control paths over to the new typed register
definitions.
This replaces manual register constants, bit masks, shifts, and the
hand-written GpuId parsing code with typed register and field accessors.
It also adds helpers for combining split 64-bit registers and uses the new
definitions in reset, L2 power-on, and GPU info readout/logging paths.
This reduces open-coded bit manipulation making the code easier to read
and maintain.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Co-developed-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-1-8abfff8a0204@collabora.com
[aliceryhl: reformat long comment]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
This code is more simply expressed using Option::filter instead of the
and_then with conditional.
This fixes the following warning with latest nightly Rust clippy build:
warning: manual implementation of `Option::filter`
--> drivers/gpu/nova-core/firmware.rs:391:14
|
391 | .and_then(|hdr| {
| ______________^
392 | | if hdr.bin_magic == BIN_MAGIC {
393 | | Some(hdr)
394 | | } else {
... |
397 | | })
| |______________^ help: try: `filter(|hdr| hdr.bin_magic == BIN_MAGIC)`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_filter
= note: `-D clippy::manual-filter` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::manual_filter)]`
Cc: stable@vger.kernel.org
Fixes: d6cb7319e64e ("gpu: nova-core: firmware: add support for common firmware header")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260423-fix-filter-v1-1-b3b197c65daf@nvidia.com
[aliceryhl: add Fixes: tag and quote the warning it fixes]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
Param used for setting FW trace mask at module load time. Other debugfs
entry exist to allow update at run time.
Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com>
Reviewed-by: Alessio Belle <alessio.belle@imgtec.com>
Link: https://patch.msgid.link/20260427-ftrace_fix-v3-2-e081530759a8@imgtec.com
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
|
|
Fix invalid data access by passing right data for debugfs entry.
[ 171.549793] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 171.559248] Mem abort info:
[ 171.562173] ESR = 0x0000000096000044
[ 171.566227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 171.573108] SET = 0, FnV = 0
[ 171.576448] EA = 0, S1PTW = 0
[ 171.579745] FSC = 0x04: level 0 translation fault
[ 171.584760] Data abort info:
[ 171.588012] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
[ 171.593734] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[ 171.598962] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 171.604471] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000083837000
[ 171.611358] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[ 171.618500] Internal error: Oops: 0000000096000044 [#1] SMP
[ 171.624222] Modules linked in: powervr drm_shmem_helper drm_gpuvm...
[ 171.656580] CPU: 0 UID: 0 PID: 549 Comm: bash Not tainted 7.0.0-rc2-g730b257ba723-dirty #13 PREEMPT
[ 171.665773] Hardware name: BeagleBoard.org BeaglePlay (DT)
[ 171.671296] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 171.678306] pc : pvr_fw_trace_mask_set+0x78/0x154 [powervr]
[ 171.683959] lr : pvr_fw_trace_mask_set+0x4c/0x154 [powervr]
[ 171.689593] sp : ffff8000835ebb90
[ 171.692929] x29: ffff8000835ebc00 x28: ffff000005c60f80 x27: 0000000000000000
[ 171.700130] x26: 0000000000000000 x25: ffff00000504af28 x24: 0000000000000000
[ 171.707324] x23: ffff00000504af50 x22: 0000000000000203 x21: 0000000000000000
[ 171.714518] x20: ffff000005c44a80 x19: ffff000005c457b8 x18: 0000000000000000
[ 171.721715] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaae8887580
[ 171.728908] x14: 0000000000000000 x13: 0000000000000000 x12: ffff8000835ebc30
[ 171.736095] x11: ffff00000504af2a x10: ffff00008504af29 x9 : 0fffffffffffffff
[ 171.743286] x8 : ffff8000835ebbf8 x7 : 0000000000000000 x6 : 000000000000002a
[ 171.750479] x5 : ffff00000504af2e x4 : 0000000000000000 x3 : 0000000000000010
[ 171.757674] x2 : 0000000000000203 x1 : 0000000000000000 x0 : ffff8000835ebba0
[ 171.764871] Call trace:
[ 171.767342] pvr_fw_trace_mask_set+0x78/0x154 [powervr] (P)
[ 171.772984] simple_attr_write_xsigned.isra.0+0xe0/0x19c
[ 171.778341] simple_attr_write+0x18/0x24
[ 171.782296] debugfs_attr_write+0x50/0x98
[ 171.786341] full_proxy_write+0x6c/0xa8
[ 171.790208] vfs_write+0xd4/0x350
[ 171.793561] ksys_write+0x70/0x108
[ 171.796995] __arm64_sys_write+0x1c/0x28
[ 171.800952] invoke_syscall+0x48/0x10c
[ 171.804740] el0_svc_common.constprop.0+0x40/0xe0
[ 171.809487] do_el0_svc+0x1c/0x28
[ 171.812834] el0_svc+0x34/0x108
[ 171.816013] el0t_64_sync_handler+0xa0/0xe4
[ 171.820237] el0t_64_sync+0x198/0x19c
[ 171.823939] Code: 32000262 b90ac293 1a931056 9134e293 (b9000036)
[ 171.830073] ---[ end trace 0000000000000000 ]---
Fixes: a331631496a0 ("drm/imagination: Simplify module parameters")
Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com>
Reviewed-by: Alessio Belle <alessio.belle@imgtec.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260427-ftrace_fix-v3-1-e081530759a8@imgtec.com
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
|
|
Fix a typo of "RGB332" in kerneldoc for the drm_crtc_fill_palette_332()
helper.
Fixes: 7ff61177b7116825 ("drm/color-mgmt: Prepare for RGB332 palettes")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/c413e45c8f752a532a4ff377f7a8b9eaab4a082a.1776757681.git.geert+renesas@glider.be
|
|
This driver is attached to a ~2000x80 screen, which is a lot more than
a single page. This causes out of memory errors in some rare cases.
Reported-by: soopyc <cassie@soopy.moe>
Closes: https://github.com/t2linux/fedora/issues/51
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Aditya Garg <gargaditya08@live.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 0670c2f56e45 ("drm/tiny: add driver for Apple Touch Bars in x86 Macs")
Cc: <stable@vger.kernel.org> # v6.15+
Link: https://patch.msgid.link/20260420-x86-tb-vmalloc-v1-1-7757ff657223@chaosmail.tech
|
|
display_get_pci_dev_of() gets a referenced PCI device via
pci_get_device(). Drop that reference when pci_enable_device() fails and
release it during the managed teardown path after pci_disable_device().
Without that, ofdrm leaks the pci_dev reference on both the error path
and the normal cleanup path.
Fixes: c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers")
Co-developed-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Co-developed-by: Taegyu Kim <tmk5904@psu.edu>
Signed-off-by: Taegyu Kim <tmk5904@psu.edu>
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260420002513.216-1-dbgh9129@gmail.com
|
|
drm_gem_fb_init_with_funcs()
drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions
using plain integer division:
unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses
drm_format_info_plane_width/height() which round up dimensions via
DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object
size check for certain pixel format and dimension combinations.
For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the
GEM size validation path sees height=0 instead of height=1. The
expression (height - 1) then wraps to UINT_MAX as an unsigned int,
causing min_size to overflow and wrap back to a small value. A tiny
GEM object therefore passes the size guard, yet when the GPU accesses
the chroma plane it will read or write memory beyond the object's
bounds.
Fix by replacing the open-coded divisions with drm_format_info_plane_width()
and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match
the calculation already used in framebuffer_check().
Fixes: 4c3dbb2c312c ("drm: Add GEM backed framebuffer library")
Cc: stable@vger.kernel.org # v4.14+
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260420013637.457751-1-ashutoshdesai993@gmail.com
|
