| Age | Commit message (Collapse) | Author |
|---|
|
rk3066_hdmi.c calls drm_bridge_connector_init(), but
ROCKCHIP_RK3066_HDMI selects neither DRM_BRIDGE_CONNECTOR nor
DRM_DISPLAY_HELPER, whose module carries the bridge-connector code. A
configuration with ROCKCHIP_RK3066_HDMI as the only enabled Rockchip
output option fails to link:
aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/rk3066_hdmi.o: in function `rk3066_hdmi_bind':
rk3066_hdmi.c:(.text+0x7a4): undefined reference to `drm_bridge_connector_init'
aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/rk3066_hdmi.o: in function `rk3066_hdmi_bridge_atomic_enable':
rk3066_hdmi.c:(.text+0xe74): undefined reference to `drm_atomic_helper_connector_hdmi_update_infoframes'
Select both, like ROCKCHIP_CDN_DP, ROCKCHIP_LVDS and ROCKCHIP_RGB do.
DRM_BRIDGE_CONNECTOR in turn selects DRM_DISPLAY_HDMI_STATE_HELPER,
which resolves the second symbol.
Fixes: 57d6811e8a6d ("drm/rockchip: rk3066_hdmi: switch to drm bridge")
Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260813144019.12089-3-royalnet026@gmail.com
|
|
dw_dp-rockchip.c calls drm_bridge_connector_init(), but ROCKCHIP_DW_DP
does not select DRM_BRIDGE_CONNECTOR. A configuration with
ROCKCHIP_DW_DP as the only enabled Rockchip output option fails to
link:
aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/dw_dp-rockchip.o: in function `dw_dp_rockchip_bind':
dw_dp-rockchip.c:(.text+0x1d4): undefined reference to `drm_bridge_connector_init'
Five other Rockchip encoder options that call
drm_bridge_connector_init() (ROCKCHIP_ANALOGIX_DP, ROCKCHIP_CDN_DP,
ROCKCHIP_DW_HDMI_QP, ROCKCHIP_LVDS, ROCKCHIP_RGB) already select it,
which masks the gap in any configuration that enables one of them.
ROCKCHIP_INNO_HDMI is covered through its DRM_INNO_HDMI core option.
The same change was posted by Marius Dinu in March and dropped when
the failure stopped reproducing in his build. The failure is
configuration-dependent - any other enabled option that selects
DRM_BRIDGE_CONNECTOR hides it - and it still reproduces on current
drm-misc-next with the configuration described above.
Select DRM_BRIDGE_CONNECTOR like the other users do.
Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support")
Link: https://lore.kernel.org/r/aneNCDU12OzG99UX@venus # ack to handle this apart from the dw-dp series
Link: https://lore.kernel.org/r/20260319155051.1944-1-m95d+git@psihoexpert.ro # earlier submission by Marius Dinu
Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260813144019.12089-2-royalnet026@gmail.com
|
|
dw_hdmi_qp_set_sample_rate() open-coded its own N and CTS lookup
tables and search/compute helpers, but it lacked the out-of-table
CTS fallback needed by strict HDMI sinks at TMDS rates not in the
table. The original LG G3 OLED audio mute (linux-rockchip 070633)
was caused by dw_hdmi_qp_find_cts() returning 0 at 185.625 MHz,
leaving AUDPKT_ACR_CTS_OVR_EN clear and falling back to the
controller's internal CTS auto-measurement, which produces incorrect
timing on the wire at out-of-table rates.
The shared drm_hdmi_acr_get_n_cts() helper in
drivers/gpu/drm/display/drm_hdmi_helper.c already implements the
correct behaviour: it has the HDMI 1.4b spec N/CTS tables, and for
TMDS rates not in the table it computes CTS = (TMDS * N) / (128 * Fs)
inline (the canonical HDMI spec formula). It is already used by
drivers/gpu/drm/msm/hdmi/hdmi_audio.c.
Convert dw_hdmi_qp_set_sample_rate() to call the helper. This
removes ~200 lines of open-coded tables and search functions
(dw_hdmi_qp_find_n, _compute_n, _find_cts, _audio_math_diff,
_match_tmds_n_table, common_tmds_n_table[], common_tmds_cts_table[])
and fixes the strict-sink audio mute as a side effect of using the
helper's complete N+CTS path.
Tested on R76S (RK3576) running Linux 7.0.1, against the LG G3 OLED
(the sink that originally reported the mute in linux-rockchip
070633) at four TMDS rates spanning HDMI 1.4 and HDMI 2.0:
TMDS Mode Audio with v3
148.5 MHz 1080p60 8-bit plays
185.625 MHz 1080p60 10-bit plays
297 MHz 1080p100 8-bit plays
594 MHz 3840p60 8-bit plays
Without this change, the LG G3 mutes audio at 185.625, 297, and
594 MHz (every rate outside dw-hdmi-qp's open-coded CTS table,
which contained only 148.5 MHz and below). With this change,
drm_hdmi_acr_get_n_cts() supplies the correct CTS at every rate --
table-canonical at 148.5 / 297 / 594 MHz, and computed via the
HDMI 1.4b formula at 185.625 MHz. The 148.5 MHz row is a
regression check confirming the in-table path is unchanged.
The Kogan KALED43XU9210STA (a permissive HDMI 2.0 sink that plays
audio at all rates with or without this change) was used as a
no-regression control: audio plays at 594 MHz with v3 loaded.
The open-coded N table in dw-hdmi-qp included optimised N values
for some TMDS rates that are not in the helper's table (e.g.
various non-CEA rates between 28-162 MHz). For those rates the
helper's fallback returns N = 128 * Fs / 1000, which is the same
value dw_hdmi_qp_compute_n() returned when no table optimisation
was needed; no audio regression has been observed at the rates
tested above.
Reported-by: Simon Wright <simon@symple.nz>
Closes: https://lore.kernel.org/linux-rockchip/ME3P282MB21960D9D68BFF520316BDFCEA83E2@ME3P282MB2196.AUSP282.PROD.OUTLOOK.COM/
Suggested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Simon Wright <simon@symple.nz>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, both HDMI controllers
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/86fcf349-0a7a-4618-9001-612371b0f71b@symple.nz
|
|
Commit 3392291fc509 ("drm/msm: Fix shrinker deadlock") dropped the only
use of the ticket arg, but at the time left drm_gem_lru_scan() unchanged
to avoid conflicts with in-flight panthor shrinker support. This commit
is the followup to remove the unused arg.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260901164544.642985-1-robin.clark@oss.qualcomm.com
|
|
rockchip_dp_drm_encoder_enable() uses sprintf() to format a device tree
path into a 32-byte stack buffer. Device tree paths are not limited to
this size, so a sufficiently long path can overflow the buffer.
Use snprintf() with the destination size to truncate the generated name
and keep the writes within bounds.
Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588")
Cc: stable@vger.kernel.org
Signed-off-by: Yudi Yang <2000jedi@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260901195511.2761251-1-2000jedi@gmail.com
|
|
dispc_plane_state_dma_addr() and dispc_plane_state_p_uv_addr() are
basically the same as drm_fb_dma_get_gem_addr(), without the support for
formats with block parameters. Since the driver doesn't support any of
those formats, the result is the same.
Switch to drm_fb_dma_get_gem_addr() for getting the framebuffer addresses.
Drop the const modifier on "struct drm_plane_state *state" for
dispc_plane_setup() so that the state can be passed to
drm_fb_dma_get_gem_addr().
Using the helper also future proofs the driver in case block parameters
are added for more formats, especially the common sub-sampled YUV
formats.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patch.msgid.link/20260903063142.3770509-1-wenst@chromium.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
During early probe, use the last page as a canary for BAR sizing, CCS
sizing, identity map setup etc. If something is wrong the last page is
where we will likely find it. Hit it with everything we have. For now
this is gated behind a debug config option, so shouldn't trigger on
production.
Main motivation is around CCS sizing where on some BMG cards the CCS
offset is programmed misaligned, for whatever reason, and our handling
of that was busted, as found by Linus, leading to some amount of CCS
storage getting pulled into the allocator as normal VRAM.
Nothing in our CI farm has such a misaligned offset it would seem,
however I did get this to pop on my b570, which does also have the
misaligned CCS offset:
Tile 0: Running VRAM memtest...
Tile 0: VRAM bounds overlap CCS region! VRAM sizing is incorrect.
With the fix from Linus, this goes away:
Tile 0: Running VRAM memtest...
Tile 0: VRAM memtest completed.
For the VRAM health check itself, this adds:
- CPU access to the last page (BAR).
- GPU access to the last page (identity map).
- CCS overlap check. This one is more involved, but overall idea is
fill the last page with a known pattern, and also save the CCS state
for the first 4M of VRAM to some scratch memory. We then zero the CCS
storage for that same range, all using the proper CCS copy instruction.
At this point we readback the last page, and check if the pattern we
wrote changed. Finally we restore the CCS state. This works since CCS
1:1 maps with VRAM, so the start of the raw CCS, should map to the
start of VRAM. This successfully catches the issue that Linus found
and fixed.
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260902124117.918018-12-matthew.auld@intel.com
|
|
The flush is gated by the WA, since there would no valid use for it
otherwise, but for some very special usecases allow bypassing the WA.
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260902124117.918018-11-matthew.auld@intel.com
|
|
Previously, we called devm_ioremap_wc() for the entire PCI LMEM BAR (which
can be significantly larger than usable memory, e.g., mapping 16G for a
10G card), and then simply assigned subsets of this global mapping to each
tile.
By moving the devm_ioremap_wc() call into vram_region_init() and mapping
on a per-tile basis, we restrict the virtual address space to exactly
the usable_size of each tile. The other big win is that the core kernel
will place a guard page at the end of each per-tile mapping to help
catch OOB CPU writes (e.g. into the flat CCS storage) by triggering an
immediate page fault instead of silent memory corruption.
As a consequence the global vram->mapping is now NULL. But that was
unused anyway, with CPU access already correctly routed through the per
tile mapping.
v2 (Sashiko)
- Make sure to update the panic flow to now use the root tile.
Assisted-by: Gemini:gemini-3.1-pro-preview
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260902124117.918018-10-matthew.auld@intel.com
|
|
So we can easily check if a machine had the CCS bug, when looking back
over bug reports where we have the same machine with newer kernel.
Example print for a machine with the CCS bug:
FLAT_CCS base:27bbff800, aligned:no
v2 (Matt B):
- Unconditionally print the base + alignment
Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation")
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@kernel.org
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260902124117.918018-9-matthew.auld@intel.com
|
|
When VRAM limit (usable_size) is no longer 2M aligned (e.g. because flat
CCS storage size rounds it down to 4K), we must map the tail of the
identity mapping using 4K pages.
This removes the 2M alignment assert (which pops) and introduces a 4K
fallback in the identity map programming loop to handle the last 2M
chunk of usable VRAM.
This now also ensures we are only mapping the usable portion of VRAM.
Might be possible to skip backporting this. The assert that pops should
be harmless and is only on debug builds plus only a stray write would
hit CCS, which technically get mapped.
Assisted-by: Gemini:gemini-3.1-pro-preview
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260902124117.918018-8-matthew.auld@intel.com
|
|
intel_crtc_duplicate_state() resets use_dsb to false but not
use_flipq, letting a stale true value survive into the new state.
Reset use_flipq alongside use_dsb.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260902140848.915941-1-mika.kahola@intel.com
|
|
This is a resubmission of commit d79716401a95 ("drm/amd/display: use
plane color_mgmt_changed to track colorop changes") whose change was
reverted by commit 0461ba9a7994 ("Merge tag 'amd-drm-next-7.3-2026-07-02'
of https://gitlab.freedesktop.org/agd5f/linux into drm-next") during a
merge conflict resolution.
Original commit message:
```
Ensure the driver tracks changes in any colorop property of a plane
color pipeline by using the same mechanism of CRTC color management and
update plane color blocks when any colorop property changes. It fixes an
issue observed on gamescope settings for night mode which is done via
shaper/3D-LUT updates.
```
Fixes: 0461ba9a7994 ("Merge tag 'amd-drm-next-7.3-2026-07-02' of https://gitlab.freedesktop.org/agd5f/linux into drm-next")
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
Link: https://patch.msgid.link/20260807115712.22423-1-mwen@igalia.com
|
|
Add bandwidth check to determine whether a given audio sample rate and
channel count can be carried within the hblank period for HDMI TMDS mode.
Use this check to prune unsupported sample rates from each SAD in the
ELD during intel_audio_compute_config(). SADs with no remaining
supported rates are removed entirely.
Sample rates are pruned rather than channel counts, since compressed
formats (e.g. AC-3) are associated with specific channel counts.
v2:
- Use DIV64_U64_ROUND_UP() instead of DIV_ROUND_UP_ULL() to avoid
do_div() truncating the 64-bit divisor to 32-bit, which caused
audio_packets_line to be wildly inflated and all SADs to be pruned.
- Guard intel_audio_hdmi_eld_compute_config() against HDMI FRL modes.
(Remove it when BW calculations for FRL are added.)
v3:
- Rebase
v4:
- Rework SAD removal into a single-pass, two-pointer compaction
instead of memmove-ing the tail on every removal. (Jani)
v5:
- Drop the FRL guard, i915 doesn't support FRL yet. (Ankit)
- s/required_tmds/hblank_audio_min (Ankit)
- Add HDMI_TMDS_AUDIO_PACKETS_LINE_MAX macro
instead of a magic number 18. (Ankit)
- Use drm_eld_sad_get()/drm_eld_sad_set() instead of
raw ELD byte access. (Ankit)
- Drop extra blank line. (Ankit)
BSpec: 68944
Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Vinod Govindapillai <vinod.govindapillai@intel.com>
Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Assisted-by: GitHub-Copilot:claude-opus-4.6
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260901103639.617757-3-chaitanya.kumar.borah@intel.com
|
|
As we plan to add audio BW calculation in i915,
intel_audio_compute_config() would need the final output_format
and pipe_bpp to correctly determine audio bandwidth constraints.
Move the intel_audio_compute_config() call to after
intel_hdmi_compute_formats() returns, ensuring the audio
configuration is computed with the final parameters.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260901103639.617757-2-chaitanya.kumar.borah@intel.com
|
|
[WHY]
resource_can_pipe_disable_cursor() disables the hardware cursor on a
pipe when a higher layer fully covers that pipe's recout, to avoid
double-cursor and scaling artifacts.
When merging pipe-split halves of the same overlay layer, the inner
loop walks every pipe above the current one and looks for siblings
sharing test_pipe's layer_index. Because test_pipe itself satisfies
that condition, it can be treated as its own split partner. That
incorrectly doubles r2.width and makes the covering check succeed even
when the overlay does not fully contain the underlying pipe.
On horizontally split or multi-quadrant layouts this causes the cursor
to disappear over overlay regions while input/coordinate mapping remains
correct.
[HOW]
Skip test_pipe when searching for a pipe-split sibling on the same
layer, so only the other half of the split plane is merged into r2.
Signed-off-by: Yuling Li <yulingli@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 85ccd2c39cca9351d4db393e24acea8bf943d350)
|
|
If a queue fails to map that we need to return the error code back
to the caller and not overwrite with a success specifically.
Accumulate the failure and return that.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 42a0197d10039e9518c0324c43331eb22b44d5f8)
|
|
Psp runtime DB is for dGPUs only.
Signed-off-by: Kanala Ramalingeswara Reddy <Kanala.RamalingeswaraReddy@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit dce8195027f146467c9378efb2bb1b0859cb735e)
Cc: stable@vger.kernel.org
|
|
Update to the latest stable fw versions where userqueues
is working as it is expected with major fixes.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 69fa36e3ac92f2544ee7a1b719ec212b8247a2da)
Cc: stable@vger.kernel.org
|
|
Update to the latest stable fw versions where userqueues
is working as it is expected with major fixes.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit d50201b891604ab97f305d4a20d888ba93305b48)
Cc: stable@vger.kernel.org
|
|
In amdgpu_devcoredump_print_ibs(), the NO_CPU_ACCESS VRAM path passed
cursor.start/4 and cursor.size/4 to amdgpu_device_mm_access(), but that
function's pos/size parameters are byte offsets/lengths (confirmed by
amdgpu_ttm_vram_mm_access() and leading to wrong size calculation.
Similarly with that change the off index needs to be calculated
based on dword since that is a u32 type.
Fixes: 7b15fc2d1f1a ("drm/amdgpu: dump job ibs in the devcoredump")
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1bd613b0ed98a23575b18674c94b8b3392614681)
Cc: stable@vger.kernel.org
|
|
Reading /sys/kernel/debug/kfd/mqds while a process holds an active KFD
queue triggers a NULL pointer dereference because the for loop that
calls mqd_mgr->debugfs_show_mqd() is incorrectly placed outside the
if (pqn->q) block that initializes mqd_mgr.
The queue list can contain entries where pqn->q is NULL (kernel queues
where only pqn->kq is valid). In the original code:
if (pqn->q) {
...
mqd_mgr = q->device->dqm->mqd_mgrs[mqd_type];
size = mqd_mgr->mqd_stride(...);
}
for (xcc = 0; xcc < num_xccs; xcc++) { // WRONG: outside if block
mqd = q->mqd + size * xcc;
r = mqd_mgr->debugfs_show_mqd(m, mqd);
}
When iterating over a queue node where pqn->q is NULL:
1. The if (pqn->q) block is skipped
2. mqd_mgr remains uninitialized (NULL from declaration)
3. The for loop executes anyway
4. mqd_mgr->debugfs_show_mqd(m, mqd) dereferences NULL
The crash manifests as:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor instruction fetch in kernel mode
RIP: 0010:0x0
Call Trace:
pqm_debugfs_mqds+0x10c/0x1d0 [amdgpu]
kfd_debugfs_mqds_by_process+0x9b/0x110 [amdgpu]
seq_read_iter+0x132/0x4b0
...
Fix by moving the for loop inside the if (pqn->q) block, so mqd_mgr
and related variables are only used when properly initialized.
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5689
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260831130051.2031435-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 8bfe29d5c798940f797aa24135d2734c3ffce9de)
Cc: stable@vger.kernel.org
|
|
get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity,
which is zeroed by reset_bw_alloc_struct() and only populated once
DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled.
link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler,
calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED
is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED
has ever fired for that link. A connected USB4/DPIA tunneling device
that reports an estimated-bandwidth change before ever reporting a
capability change drives a division by zero in this IRQ path.
link_dpia_send_bw_alloc_request() already guards the same
bw_granularity division; add the identical guard here rather than
introducing a new pattern.
Fixes: 8e5cfe547bf3 ("drm/amd/display: upstream link_dp_dpia_bw.c")
Reviewed-by: Alex Hung <alex.hung@amd.com>
Assisted-by: gkh_clanker_t1000
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)
Cc: stable@vger.kernel.org
|
|
In encode-to-linear conversions, LUT entries should be uniformly
distributed across the input range: non-linear encodings are already
approximately perceptually uniform, so every input code carries the same
weight. A fixed count per region does the opposite, concentrating
entries on the darker values and leaving few for the bright end, whereas
halving distribution spaces all 256 entries uniformly. This holds for
any encoded input, so remove the PQ/sRGB condition from commit
"drm/amd/display: use halving distribution for PQ/sRGB linearizing LUT"
and apply halving to all encode-to-linear operations
(pre-defined TF or user LUTs).
It fixes the following IGT kms_colorop subtests:
- plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut
- plane-XR30-XR30-gamma_2_2-gamma_2_2_inv-gamma_2_2
Fixes: a71d2b051f33 ("drm/amd/display: use halving distribution for PQ/sRGB linearizing LUT")
Reviewed-by: Alex Hung <alex.hung@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 6df7c9c307e72e7f13829e94edc89134f0764775)
|
|
[WHY]
For some eDP panels VESA aux backlight control is necessary,
otherwise they stay black.
[HOW]
When AUX backlight control is used, select BACKLIGHT_CONTROL_VESA_AUX for
panels that advertise panel_luminance_control.
Reviewed-by: Hansen Dsouza <hansen.dsouza@amd.com>
Signed-off-by: Roman Li <Roman.Li@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 42f698bd061d76d5f4c84a195e465cfbeec775e4)
|
|
[WHY/HOW]
Integer values for
dml2_core_calcs_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport_params
should not have the const qualifier.
This prevents using different values of the inputs when the
function is called again.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Austin Zheng <Austin.Zheng@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 342280aae4f33816e8d07c15cb538a3b375a7f8f)
Cc: stable@vger.kernel.org
|
|
[WHY]
Splash screen corruption on some 8K monitors.
[HOW]
Set GPUVM min page size to 4K for DCN35/36 to use the correct DML2
calculations, avoiding the corruption path observed during splash.
Fixes: 115009d11ccf ("drm/amd/display: Add DCN35 DML2 support")
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Roman Li <Roman.Li@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 2cbfb03dead5088a7bdfe2ce392a5caa3d1b3719)
Cc: stable@vger.kernel.org
|
|
[WHY]
A kernel compilation warning was reported caused by upstream of DCN5/6.
[HOW]
Using plain integer as NULL pointer. Assign NULL to the
VActiveLatencyHidingMargin/VActiveLatencyHidingUs pointer members in
dml2_core_dcn5_funcs_mode_programming.c, and pass NULL for the pointer
arguments to calculate_first_second_splitting() in
dml2_pmo_dcn6_stage_optimizers.c.
Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6")
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit d96880560e9f35ba7f8de1b3f90032c8c3eaea88)
|
|
amdgpu_debugfs_vm_bo_status_info() prints the "Idle BOs" section by
iterating lists->needs_update, the same list already printed just
above under "Moved BOs". struct amdgpu_vm_bo_status has a dedicated
idle list, populated whenever a BO's state machine settles, but it
was never read here, so genuinely idle BOs never show up in the
debugfs output and the "Idle BOs" section duplicates "Moved BOs"
instead.
Iterate lists->idle for the "Idle BOs" section.
Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4")
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 451bfc778a8c364841837def00ba15936f72762b)
Cc: stable@vger.kernel.org
|
|
For different address types the variable PAGE_SHIFT might
not work well and it's better to use the GPU specific one
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3494b77d10375e0f9ab784e9b20763339844b55b)
Cc: stable@vger.kernel.org
|
|
Update queue reset required MES version for MES 12.1 to 0x7b since we
change the implementation from detect-and-reset method to
per-queue-reset method.
Signed-off-by: Amber Lin <amber.lin@amd.com>
Reviewed-by: Michael Chen <michael.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 2160a5cbf0b7917adce4b55421306b614b4a2c8f)
|
|
Don't apply to KIQ. Seems to cause problems on KIQ
on some ARM platforms.
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5658
Fixes: 91cf34bc5a55 ("drm/amdgpu/gfx8: align mqd settings with KFD")
Reviewed-by: Jesse Zhang <jesse.zhang@amd.com>
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 6aae7bab029cdccae9a7157facfe36bfc35fc940)
Cc: stable@vger.kernel.org
|
|
The BAR0 fallback read path was introduced as a workaround for SR-IOV VFs
where the VRAM aperture is not available during early init. Restrict this
workaround to only SR-IOV VFs where it's needed.
Reported-by: gloveless@jqluv.com
Fixes: cba4928cdffa ("drm/amdgpu: reduce early full GPU access during SR-IOV init")
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260826185102.2269511-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit d8a0affd207c813bd063fa2c27786f449eaf92b8)
|
|
MES (Micro Engine Scheduler) does not perform heavy-weight TLB
invalidation after unmapping queues, unlike HWS which does this
automatically. This causes a race condition where in-flight DMA
descriptors can access memory that has been unmapped, leading to page
faults and GPU queue hangs during SVM page migration.
The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest
failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU
compute queue hangs with packets submitted but never consumed.
Add kfd_flush_tlb() calls after MES queue removal in two locations:
- evict_process_queues_cpsch(): after all queues removed during eviction
- suspend_queues(): after debug/criu queue suspension (with mem_fence barrier)
This ensures all in-flight memory accesses from unmapped queues are
flushed before memory is freed or migrated.
Signed-off-by: Priya Hosur <Priya.Hosur@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77)
Cc: stable@vger.kernel.org
|
|
Add the ioctl infrastructure to support exporting and importing BOs
to facilitate NPA based memory sharing across GPUs in a rack scale
setup.
Proposed userspace:
https://github.com/ROCm/rocm-systems/blob/35959f8e1260c7cee3e51a740e320be3856ee4ff/projects/rocr-runtime/libhsakmt/src/memory.c#L971
https://github.com/ROCm/rocm-systems/blob/35959f8e1260c7cee3e51a740e320be3856ee4ff/projects/rocr-runtime/libhsakmt/src/memory.c#L1036
v2: Move the ioctl wire-up to the end of the series.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Horatio Zhang <hongkun.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add an optional callback for driver-specific cleanup when the GEM
handle of an object is freed. This will be used by AMDGPU to enable
freeing of memory exported to other nodes in a UALink pod once all
user mode references are gone.
The callback is called outside the object_name_lock and before
releasing the reference count on the GEM object
Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Derive mtype_remote in gmc_v12_1_get_npa_flags() from
gmc_v12_1_get_mtypes() so the module-parameter override and ASIC
defaults are honored instead of recomputing with hard-coded values.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add an amdgpu_mtype_remote module parameter so the MTYPE used for remote
memory accesses can be overridden. For now only MTYPE_NC and MTYPE_UC
are selectable (0 = MTYPE_NC, 1 = MTYPE_UC); it defaults to the
ASIC-dependent value. Currently, it is used only for GFX 12.1.
The MTYPEs resolved for both local and remote memory are logged once.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_ualink_map_npa_to_dmabuf() created the NPA import BO in the
CPU/SYSTEM domain and then moved it to NPA. SYSTEM is use_tt=true, so TTM
attaches a host-page ttm_tt that the null move to NPA leaves behind. On
dma-buf export, ttm_bo_populate() then fills that ttm_tt with system
pages, spiking host RAM by the entire NPA window size.
Create the BO directly in the NPA domain (use_tt=false) so no ttm_tt is
ever attached, and relocate it to the exact remote window.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When two threads import the same UALINK handle concurrently, the first
xa_insert() succeeds and the second gets -EBUSY. Convert -EBUSY to
-EAGAIN so user-space retries instead of seeing a spurious error.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Mirror the read-only ualink info attributes on each secondary compute
partition as a per-partition ualink node, so a partition-scoped consumer
(e.g. a container that only sees its partition's device node) can read
the ualink identity and state. Partition 0 shares the primary device,
which already exposes that node, so it is skipped. An inactive partition
device won't be having any attributes listed under ualink node.
The per-partition attributes are served by thin wrappers that delegate
to the existing device-level info show functions. A reference on the
info kobject is held for the node's lifetime so it cannot be freed
while a partition still uses it.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Assisted-by: Claude (claude-opus-4.7)
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Deactivate accelerator from vpod during hw_fini sequence.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Move more IP version specific related things to ualink version file.
Use soc v1.0 IH client id defintion and define mpnht interrupt source
id in ivsrcid header.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_ualink_manager_stop() only called xa_destroy() on the exporter,
importer and handle-invalid xarrays, which frees the internal tree but
not the node objects. Entries still present at teardown thus leaked the
nodes, left NPA addresses mapped and kept exported BOs pinned.
Free the entries in all three xarrays explicitly, without exchanging any
NPA protocol messages (the F/W is already halted by
amdgpu_ualink_sw_fini()): mark connections down so the drained workers
and teardown take the message-free path, drain in-flight exporter
cleanup work to empty handle_invalid_xa, then free the remaining
importer and exporter entries before the NPA allocator is torn down.
Also factor the shared importer-node release into
amdgpu_ualink_release_imp_xa_node(), drop/drain stale remote interrupts
in the IRQ handler when the accelerator is not ACTIVE, and refuse outbound
messages in amdgpu_ualink_send_command() when not ACTIVE so an in-flight
cleanup worker cannot emit onto torn-down peer/SDMA state or block
waiting for a response that will never arrive.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add namestring for ualink
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
An already-ACTIVE accelerator with an unchanged vpod_id skipped
re-activation, so growing or shrinking a live vPod left staying GPUs
with links/GART built for the old member set. Detect membership changes
(owned snapshot vs firmware read-back) and bounce affected ACTIVE peers
once the integrity check passes. Firmware requires a full metadata
reload while halted, so a full deactivate/activate is needed rather than
per-peer deltas.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add UALINK:-tagged dev_info/dev_warn logging along the vpod commit ->
update_accel_state -> integrity -> activate path so failing and -EAGAIN
peer-wait cases are visible without dynamic debug. Also fix a wrong
print arg (vpod->id -> vpod->addr_mode) in the invalid addr mode
message.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
remote->active_accel_bits aliased info->vpod.active_accel_bits, which
psp_ual_query_info() refreshes on every commit. Teardown
(peer_remote_fini / gart unmap) then iterated the new set instead of the
one sw_init mapped, orphaning drm_mm nodes in the shared GTT manager.
Make active_accel_bits an owned snapshot copied at sw_init time. Drop the
now-redundant not-initialised guard in metadata_npa_unmapping(), since the
earlier remote->ring_bo NULL-check already covers that case.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
For updating the vpod configuration, use similar logic in both sideband
and inband paths.
In inband path, force the vpod id as invalid when ppod configuration is
done. Remove the redundant query call after station configuration as it
station configuration doesn't affect vpod configuration.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Keep state transitions under lock. Validate the ppod/vpod config or both
based on the state passed by ASP. When a config update is received, if
the GPU is already active on a vpod, local vpod gpu integrity check is
skipped to keep minimal disruption. A gpu removed from the vpod will get
the new vpod id as 0. A GPU is not expected to transition directly from a
valid/nonzero vpod id to another valid vpod id. It needs to be removed
from the existing vpod first.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
