| Age | Commit message (Collapse) | Author |
|---|
|
Bridges using DRM_BRIDGE_OP_HDMI are now expected to also provide a
supported HDMI version. This is not yet enforced, but will become
mandatory once the migration to the new caps-based HDMI connector
initialization API is completed.
Since inno_hdmi_phy_config.pixelclock does not exceed 165 MHz for any of
the chip variants handled by the driver, advertise HDMI 1.2 as the
supported version.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS, Rock 5B
Link: https://patch.msgid.link/20261001-bridge-advert-hdmi-caps-v1-2-f8806570e243@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Bridges using DRM_BRIDGE_OP_HDMI are now expected to also provide a
supported HDMI version. This is not yet enforced, but will become
mandatory once the migration to the new caps-based HDMI connector
initialization API is completed.
Since max_mode_clock_khz does not exceed 165 MHz for any of the chip
variants handled by the driver, advertise HDMI 1.2 as the supported
version and set the bridge's max_tmds_char_rate so the connector limit
inferred from supported_hdmi_ver is overridden by the chip-specific
hardware constraints.
drm_bridge_connector_atomic_check() runs
drm_atomic_helper_connector_hdmi_check(), which rejects modes whose
computed TMDS character rate exceeds the connector limit before invoking
the driver's .tmds_char_rate_valid() hook, making
adv7511_bridge_hdmi_tmds_char_rate_valid() redundant. Drop it.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS, Rock 5B
Link: https://patch.msgid.link/20261001-bridge-advert-hdmi-caps-v1-1-f8806570e243@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes
amd-drm-fixes-7.3-2026-10-15:
amdgpu:
- UVD fix
- TTM sched entity fixes
- SMU 14 fix
- Userptr leak fixes
- Runpm ref count fix
- CRIU fix
- UserQ fixes
- USB4 fix
- SDMA 3 fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20261015221002.1728931-1-alexander.deucher@amd.com
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
An OA uAPI fix by zeroing OA buffer at allocation,
and other 3 small fixes around eviction and shrinker.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/atDNMV-Aohu6s0gE@intel.com
|
|
Switch PF VF-context provisioning to explicitly allocate IDs from
the dedicated shareable ID pool.
Also, lets remove the legacy GuC ID reservation API now that all VFs
provisioning paths use the shareable allocation helpers.
v2: Use local variable for max shareable GuC IDs in fair profile (Satya)
Assisted-by: Claude:claude-5-sonnet
Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Link: https://patch.msgid.link/20261014100907.77877-5-piotr.piorkowski@intel.com
Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
|
|
Switch GuC submission to explicitly allocate IDs from the usable
ID pool.
Also lets configure the GuC ID manager according to the device operating
mode during submission initialization. Use dedicated initialization
paths for native, PF and VF modes to expose the appropriate usable and
shareable GuC ID ranges.
v2: Use xe_root_mmio_gt() to get the primary GT so no NULL check is
needed (Sashiko).
Assisted-by: Claude:claude-5-sonnet
Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Link: https://patch.msgid.link/20261014100907.77877-4-piotr.piorkowski@intel.com
Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
|
|
Expand the GuC ID manager KUnit coverage to exercise the new
usable/shareable pool model.
v2: Use KUNIT_EXPECT instead of KUNIT_ASSERT inside the locked section
so the mutex is not leaked on failure (Sashiko).
v3: Guard failed ID reservations before releasing test allocations.
v4: Avoid releasing unreserved ID ranges after failed test reservations.
v5: Fix check_used() cleanup and add missing reservation guards (Sashiko).
v6: Use guard() for the ID manager lock, simplify the skip helper and
replace magic numbers with named constants (Satya).
Assisted-by: Claude:claude-5-sonnet
Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Link: https://patch.msgid.link/20261014100907.77877-3-piotr.piorkowski@intel.com
Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
|
|
Modify the GuC identifier manager so that it distinguishes between
usable GuC IDs allocated for GuC submissions, and shareable those that
can be shared with VFs. Both pools are represented as a single bitmap
and may overlap.
Let's Replace the single-pool accounting model with separate usable and
shareable pools, add helpers for pool accounting and limits, and update
debug reporting.
For now, let's keep the current allocation behaviour by mapping both pools
onto the same GuC ID space. This prepares the ID manager for separate
management of submission IDs and VF allocations in following changes.
v2: Do not change how VF IDs are allocated in the legacy path (Sashiko)
v3: Fix shareable spare quota accounting to include
PF-exclusive usable IDs.
v4: Do not apply spare quota to VF-exclusive shareable IDs (Sashiko)
Drop redundant checks and asserts (Satya)
v5: Add quota helper and unify -ENOSPC check in shareable path (Satya)
Assisted-by: Claude:claude-5-sonnet
Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Link: https://patch.msgid.link/20261014100907.77877-2-piotr.piorkowski@intel.com
Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
|
|
The driver has no USB power management callbacks, so the USB core
unbinds it before system suspend and binds it again on resume. The DRM
device is unregistered and registered again on every suspend and resume
cycle, userspace driving the Touch Bar through it (such as tiny-dfr)
loses its device, and the Touch Bar stays dark after resume.
Implement suspend and resume with drm_mode_config_helper_suspend() and
drm_mode_config_helper_resume(), so the device stays registered and the
last committed state is restored on resume. If the device was reset
while suspended, repeat the probe-time handshake first.
Fixes: 0670c2f56e45 ("drm/tiny: add driver for Apple Touch Bars in x86 Macs")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Vasilij Markin <vasilij.kernel@tototo.si>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20261015-appletbdrm-pm-v3-1-47377176619a@tototo.si
|
|
The driver already allocates its private data via
devm_drm_bridge_alloc(), which initializes the bridge funcs pointer.
Remove the leftover manual assignment in the probe function.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20261001-bridge-alloc-conv-v1-2-f0a1fe040a86@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Bridge drivers are expected to use devm_drm_bridge_alloc() instead of
devm_kzalloc() for allocating and partially initializing a private
driver struct embedding a struct drm_bridge.
Perform the API conversion and drop the now redundant manual
initialization of the drm_bridge funcs pointer, following the pattern
established by commit 9c399719cfb9 ("drm: convert many bridge drivers
from devm_kzalloc() to devm_drm_bridge_alloc() API").
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20261001-bridge-alloc-conv-v1-1-f0a1fe040a86@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
A revert for the blend mode property patch being applied twice and a
patch to reset the device when frozen in virtio, a power state fix for
vc4, a Kconfig fix for amdxdna, an error handling, reference counting,
and a null pointer dereference fix for rocket, a revert for dma-buf for
a commit introducing a dangling reference, a locking fix for exec, and a
fix for panthor to handle 10-core GPUs.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/atCZfcTvshZx6mcA@houat
|
|
The "Disable NULL query for Anyhit Shader" tuning uses
xe_rtp_match_first_render_or_compute to program RT_CTRL once per GT.
On a GT with no render (RCS) engine, that match falls back to a
compute (CCS) engine instead, so the tuning is still written even
though RT_CTRL's ray-tracing logic has no hardware behind it there.
A CRI compute-only GT hits exactly this path, causing
igt@xe_debugfs@check-gt-reg-sr to report a save-restore mismatch:
Mismatch on 0xe530, expected 0x400 got 0x0
Restrict the rule to ENGINE_CLASS(RENDER) so it only applies where
ray-tracing hardware is actually present. Every other in-tree platform
in this version range (BMG, LNL, PTL, NVL) always has a render engine,
which xe_rtp_match_first_render_or_compute already resolves ahead of
any compute engine, so this is a no-op for them.
Assisted-by: LLM
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
Fixes: 8d8431298f69 ("drm/xe/xe3: Disable null query for anyhit shader")
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20261012171901.19508-6-nitin.r.gote@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
SDMA can randomly hang on Polaris 10. Hard to reproduce,
but has been occurring sporadically in the Mesa CI
on the RADV Polaris 10 job even when Mesa isn't using
the SDMA engine.
When Mesa actually uses the SDMA on Polaris, the hang
becomes more frequent and the reproduction rate goes up
significantly in the CI system.
We don't know why the hangs occur, but it seems
that inserting a single NOP packet before each
POLL_REGMEM and FENCE packet works around it.
At the moment it's unclear which GPUs are affected,
so let's apply this to SDMA 3.x for now.
Note that this issue is not documented or acknowledged by AMD.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c343a27ed90823d08de125f7c447d96d056b75d9)
Cc: stable@vger.kernel.org
|
|
amdgpu_gem_object_close() detaches the user queue eviction fence from
the BO before it checks bo_va->ref_count, so closing any handle of a BO
removes the fence, even when the file still has another handle to the
BO and the bo_va with its GPU mappings stays. The BO can then be evicted
without suspending the user queues of the file, which keep accessing it
through mappings that are only marked for update.
Seen on navi31 with a SDMA user queue: a BO opened twice in the same
file (GEM_FLINK + GEM_OPEN) loses its eviction fence when the second
handle is closed (traced attach/detach of the fence):
attach bo=ffff8c78a6c84c00
GEM_CLOSE handle=7
detach bo=ffff8c78a6c84c00
while handle 6 and the mapping are still in use.
Only detach the fence when the last reference to the bo_va goes away,
matching amdgpu_gem_object_open(), which attaches it only when the
bo_va is created. With this the fence stays until the file is closed.
Fixes: 31f7efcdca4d ("drm/amdgpu: enable eviction fence")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 8387982f03d4026b7dc11b0b5e3118298eee4d6a)
Cc: stable@vger.kernel.org
|
|
allocate_usb4_bandwidth_for_stream() and allocate_usb4_bandwidth() both
use ASSERT(stream->sink) before dereferencing stream->sink->link. ASSERT
is compiled out in production builds, so a NULL stream->sink causes a
NULL pointer dereference.
link_set_dpms_off() already guards two earlier accesses to stream->sink
with explicit NULL checks, confirming that stream->sink can legitimately
be NULL. The subsequent call to deallocate_usb4_bandwidth() had no
equivalent guard.
Replace the ASSERT() calls with proper NULL checks that return false
early, and add a matching stream->sink guard at the call site in
link_set_dpms_off() consistent with the surrounding pattern.
v2: Keep the existing ASSERT() calls for diagnostics (to report
unexpected NULL sink), and add explicit NULL checks that return false
before dereferencing stream->sink. Also add a matching stream->sink
guard at the deallocation call site in link_set_dpms_off(). (Alex)
Fixes: 8fa813b7fd1e ("drm/amd/display: Remove sink usage from DPMS")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Dominik Kaszewski <dominik.kaszewski@amd.com>
Cc: George Zhang <george.zhang@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Roman Li <roman.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 98029a0ce61feb52c563f65349dd9b25f672e355)
Cc: stable@vger.kernel.org
|
|
This was supposed to loop over the individual evicted list, as the
kernel and always_valid evicted lists were already handled in
amdgpu_vm_validate.
Without this, BOs that were created and evicted before a userq was made
would never end up in an eviction fence rearm.
Also add the missing ref to the BO before drm_exec locks and refs it.
Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4")
Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 18decfc9e8cc0fa70b6de9944cc27a37729edfbd)
Cc: stable@vger.kernel.org
|
|
The uapi documents drm_amdgpu_gem_list_handles_entry.alignment as
"physical start_addr alignment in bytes", and GEM_OP
GET_GEM_CREATE_INFO returns the same value in bytes, but
GEM_LIST_HANDLES returns tbo.page_alignment, which is in pages. For a BO
created with a 64 KiB alignment on navi31:
GET_GEM_CREATE_INFO: alignment=65536
GEM_LIST_HANDLES: alignment=16
so a user such as CRIU that recreates BOs from this list uses the wrong
alignment. Convert it to bytes.
Fixes: f9db1fc52ceb ("drm/amdgpu: Add ioctl to get all gem handles for a process")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit aa4493ae949c13e79aba0731394dd7a7e431342b)
Cc: stable@vger.kernel.org
|
|
amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of
the BO list and looks up the user pages. Those ranges are only freed when
amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks
them under the notifier lock. If amdgpu_cs_patch_jobs(),
amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of
amdgpu_cs_submit() fails, nothing frees them: neither
amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range.
Each such CS then leaks the range, its hmm_pfns array (8 bytes per page
of the userptr BO) and the BO reference the range holds. An IB on a ring
that patches the CS in place (e.g. VCN) with an unmapped va_start fails
in amdgpu_cs_patch_ibs() and takes this path.
Free the ranges on those error paths. Ranges amdgpu_cs_submit() already
dropped are NULL, so freeing them again is a no-op.
Fixes: fec8fdb54e8f ("drm/amdgpu: fix userptr HMM range handling v2")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c52a9542ed7cfd527feb938bd0accada2ac8d267)
Cc: stable@vger.kernel.org
|
|
amdgpu_debugfs_gpr_read() drops its runtime PM reference right after
reading the wave registers. When copying them to userspace fails, it
jumps to the err label, which drops the reference a second time. A read
into a bad buffer on Navi31 either steals a reference somebody else
holds (power/runtime_usage goes from 1 to 0) or underflows the count:
amdgpu 0000:03:00.0: Runtime PM usage count underflow!
The registers are already in the kernel buffer at that point, so finish
the hardware access first and copy the buffer with a single
copy_to_user() instead of the put_user() loop with its own error path.
Fixes: 9eee152aab56 ("drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 31035bbd74f7c3e10c163db875b8e67f8b50ee6a)
Cc: stable@vger.kernel.org
|
|
When amdgpu_hmm_range_alloc() fails amdgpu_gem_userptr_ioctl() returns
-ENOMEM right away and skips the cleanup every other error path goes
through. The GEM object, the bo->parent reference on the VM root and the
MMU notifier registration are all left behind.
Use release_object here, not user_pages_done, range is still NULL at
this point.
Fixes: e095b55155ef ("drm/amdgpu: use user provided hmm_range buffer in amdgpu_ttm_tt_get_user_pages")
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bbe739e407a542073ec1a7872b14843566b4919e)
Cc: stable@vger.kernel.org
|
|
add zero fan stop temperature support on smu 14.0.2
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5905
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Reviewed-by: Kevin Wang <kevin.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f990c94a2633d0ead477eb1b174e254a6d292e66)
Cc: stable@vger.kernel.org
|
|
Pair mutex_init() with mutex_destroy() on the GART window allocation
failure path and in amdgpu_ttm_buffer_entity_fini(). This is a no-op
without CONFIG_DEBUG_MUTEXES, but it keeps lockdep from seeing a live
mutex after the entity is freed or re-initialized.
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 03ac40aeed034a0a0d5824ad26f8fbe1f6463698)
Cc: stable@vger.kernel.org
|
|
amdgpu_ttm_buffer_entity_init() checks num_gart_windows after
drm_sched_entity_init() has already attached the entity to a
scheduler run-queue. Returning -EINVAL from that check leaks the
entity.
Move the ARRAY_SIZE() check before any resources are acquired.
Fixes: 2c3725572561 ("drm/amdgpu: statically assign gart windows to ttm entities")
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4000d1cdd1eacd3422267d6c8b4f1c9333b0317e)
Cc: stable@vger.kernel.org
|
|
The PASS_MASK is for a different register not for UVD_FW_START.
It was a mistake to check this flag. It should be enough to check
that the register is non-zero.
Fixes: 889a2cfd889c ("drm/amdgpu/uvd3.1: Don't validate the firmware when already validated")
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20261006211607.75407-1-timur.kristof@gmail.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9dee462c83259ca769aa1bf82228adee9831685c)
Cc: stable@vger.kernel.org
|
|
The GFX, compute and SDMA branches of AMDGPU_INFO_UQ_FW_AREAS work out
-EFAULT when the result can't be copied to userspace but return 0 all
the same, so the caller goes on with a buffer that was never written.
On navi31, querying any of the three into a read-only page returns 0,
while e.g. AMDGPU_INFO_DEV_INFO returns -EFAULT for the same page.
Return the result of the copy.
v2: return copy_to_user() ? -EFAULT : 0 directly (Christian)
Fixes: 90c448fef312 ("drm/amdgpu: add new AMDGPU_INFO subquery for userq objects")
Fixes: 44b69cf1d35c ("drm/amdgpu: Update AMDGPU_INFO_UQ_FW_AREAS query for compute")
Fixes: 0030595c3e8b ("drm/amdgpu: Update AMDGPU_INFO_UQ_FW_AREAS query for sdma")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
PMFW can report clocks outside or between advertised DPM levels.
Report a clock below DPM0 as a special active S level.
Mark the nearest level active for a discrete DPM table.
Clamp a clock above the table range to the maximum DPM level.
Keep reporting the actual clock for a fine-grained DPM table.
Signed-off-by: Kevin Wang <kevin.wang@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Support set pcie bif feature mask to support error
injection.
Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use uniras core to invoke ras command.
Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
the register c2pmsg_127 design only applies to dGPU not
APU platform, so hard code ras block feature mask on APU
platform.
Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Remove unused tracepoint "amdgpu_reset_reg_dumps", flagged by UT=1,
from amdgpu/amdgpu_trace.h
Signed-off-by: Omer El Idrissi <omer.e.idrissi@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
navi10_force_clk_levels() and sienna_cichlid_force_clk_levels()
return success when a DPM frequency lookup or soft frequency range
update fails. smu_force_smuclk_levels() then records the requested
clock mask even though the operation failed.
Return the helper error from both callbacks instead to improve
observability. No obvious reason to clobber the return values here.
Fixes: db439ca21b81f ("drm/amd/powerplay: add function force_clk_levels for navi10")
Fixes: b455159c05313 ("drm/amdgpu/powerplay: add initial swSMU support for sienna_cichlid (v2)")
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
In sriov, fb-sharing can be disabled via the xgmi ta. For this scenario,
hive_id alone is insufficient for determining peer accessibility.
fb-sharing enable flag needs to be checked as well.
v2: Move fb-sharing gate to amdgpu_xgmi_same_hive from
amdgpu_dmabuf_is_xgmi_accessible. All xgmi connectivity checks need it.
Signed-off-by: Will Aitken <will.aitken@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
VFs support same SDMA 7.1 queue reset capabilities as baremetal.
Set use_mmio=false for amdgpu_mes_reset_legacy_queue as actual MES 12.1
queue reset code never uses mmio.
Signed-off-by: Victor Skvortsov <victor.skvortsov@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
SDMA can randomly hang on Polaris 10. Hard to reproduce,
but has been occurring sporadically in the Mesa CI
on the RADV Polaris 10 job even when Mesa isn't using
the SDMA engine.
When Mesa actually uses the SDMA on Polaris, the hang
becomes more frequent and the reproduction rate goes up
significantly in the CI system.
We don't know why the hangs occur, but it seems
that inserting a single NOP packet before each
POLL_REGMEM and FENCE packet works around it.
At the moment it's unclear which GPUs are affected,
so let's apply this to SDMA 3.x for now.
Note that this issue is not documented or acknowledged by AMD.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
XCP unplug currently restores the partition minors' device pointers to
the synthetic p_ddev and frees that device while files opened through
those minors may still be active. Those files acquired drm_device
references on the primary ddev because the minors were redirected at
XCP allocation time. After unplug reverses the redirection, close paths
operate on the already-freed p_ddev, causing a use-after-free and
p_ddev refcount underflow while leaking the matching primary-device
references.
Split teardown into two phases. amdgpu_xcp_dev_unplug() only calls
drm_dev_unplug() so new opens fail, leaving minor->dev pointing at the
primary device. amdgpu_xcp_dev_fini() restores the partition device
pointers and frees p_ddev from amdgpu_driver_release_kms(), when the
primary drm_device reaches final release and all references held by
redirected files have been dropped.
Signed-off-by: Luqmaan Irshad <luqmaan.irshad@amd.com>
Reviewed-by: Yunxiang Li <Yunxiang.Li@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Calling amdgpu_vm_bo_update() this early is unnecessary. moving it to
amdgpu_cs_vm_handling is the correct location for this function and is
required to allow the VM to initialize without waking up sleep.
Signed-off-by: Shahyan Soltani <shahyan.soltani@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Every remaining caller of adev->gfx.rlc.funcs->update_spm_vmid() passes
NULL for ring, since the only callers that ever passed a real ring
were removed earlier in this series. Drop the parameter, and the
dead SR-IOV one-VF ring-replay code in gfx_v11_0/gfx_v12_0/gfx_v12_1
that only ran when ring was non-NULL.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The SPM reserved VMID is fixed now, so retargeting RLC_SPM_VMID to
job->vmid on every submission is dead code. Remove
job->spm_update_needed and the update_spm_vmid() calls in
amdgpu_vm_flush() and amdgpu_ib_schedule().
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use the spm vmid which is dedicated for the SPM only and update
the function paths accordingly.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The RLC bring-up paths programmed the RLC_SPM_VMID field to a hardcoded
0xf as the idle default. Now that the dedicated SPM VMID is tracked in
vm_manager.spm_vmid, use it directly so the idle default matches the
VMID the reservation path hands out.
No functional change: spm_vmid is the top VMID (0xf) on all affected
generations (gfx7 through gfx12).
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Set vm_manager.spm_vmid to the top GFXHUB VMID so the SPM reservation
path hands out a fixed, isolated VMID on gfx12 instead of borrowing
one from the graphics pool. This also covers gfx12.1, whose VMID setup
is handled in this file.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Set vm_manager.spm_vmid to the top GFXHUB VMID so the SPM reservation
path hands out a fixed, isolated VMID on gfx11 instead of borrowing
one from the graphics pool.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Set vm_manager.spm_vmid to the top GFXHUB VMID so the SPM reservation
path hands out a fixed, isolated VMID on gfx10 instead of borrowing
one from the graphics pool.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_gem_metadata_ioctl() handles AMDGPU_GEM_METADATA_OP_GET_METADATA
and AMDGPU_GEM_METADATA_OP_SET_METADATA and returns r otherwise, which
is 0 from the successful amdgpu_bo_reserve(). Any other op therefore
succeeds without doing anything.
Convert the if/else chain into a switch and return -EINVAL for unknown
ops.
v2: use a switch statement instead of if/else if/else (Christian)
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_gem_object_close() detaches the user queue eviction fence from
the BO before it checks bo_va->ref_count, so closing any handle of a BO
removes the fence, even when the file still has another handle to the
BO and the bo_va with its GPU mappings stays. The BO can then be evicted
without suspending the user queues of the file, which keep accessing it
through mappings that are only marked for update.
Seen on navi31 with a SDMA user queue: a BO opened twice in the same
file (GEM_FLINK + GEM_OPEN) loses its eviction fence when the second
handle is closed (traced attach/detach of the fence):
attach bo=ffff8c78a6c84c00
GEM_CLOSE handle=7
detach bo=ffff8c78a6c84c00
while handle 6 and the mapping are still in use.
Only detach the fence when the last reference to the bo_va goes away,
matching amdgpu_gem_object_open(), which attaches it only when the
bo_va is created. With this the fence stays until the file is closed.
Fixes: 31f7efcdca4d ("drm/amdgpu: enable eviction fence")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Route MESAPI_MISC__SETUP_MES_DBGEXT to the pipe named in the setup
request instead of the default MISC pipe, so each MES pipe can be
pointed at its own dbgext log region. Under unified MES the default is
the KIQ pipe, so both setup requests landed there and the scheduler
pipe never got a log buffer.
Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com>
Reviewed-by: Shaoyun Liu <Shaoyun.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
allocate_usb4_bandwidth_for_stream() and allocate_usb4_bandwidth() both
use ASSERT(stream->sink) before dereferencing stream->sink->link. ASSERT
is compiled out in production builds, so a NULL stream->sink causes a
NULL pointer dereference.
link_set_dpms_off() already guards two earlier accesses to stream->sink
with explicit NULL checks, confirming that stream->sink can legitimately
be NULL. The subsequent call to deallocate_usb4_bandwidth() had no
equivalent guard.
Replace the ASSERT() calls with proper NULL checks that return false
early, and add a matching stream->sink guard at the call site in
link_set_dpms_off() consistent with the surrounding pattern.
v2: Keep the existing ASSERT() calls for diagnostics (to report
unexpected NULL sink), and add explicit NULL checks that return false
before dereferencing stream->sink. Also add a matching stream->sink
guard at the deallocation call site in link_set_dpms_off(). (Alex)
Fixes: 8fa813b7fd1e ("drm/amd/display: Remove sink usage from DPMS")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Dominik Kaszewski <dominik.kaszewski@amd.com>
Cc: George Zhang <george.zhang@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Roman Li <roman.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Under unified MES both pipes of each XCC run MES firmware, each with its
own scheduler context, and the firmware attaches the dbgext log buffer
only to the pipe that received SETUP_MES_DBGEXT. With a single region
per XCC only one pipe's messages were collected.
Give every (xcc, pipe) its own region in the log buffer, pass the target
pipe in the setup request, and arm, detach and drain every region. Tag
output with the source XCC and pipe ("0"-sched/"1"-kiq) when more than one
region is logged; single-region output is unchanged.
Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com>
Reviewed-by: Shaoyun Liu <Shaoyun.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Set vm_manager.spm_vmid to the top GFXHUB VMID so the SPM reservation
path hands out a fixed, isolated VMID on gfx9 instead of borrowing one
from the graphics pool.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
