- Mar 19, 2025
-
-
Victor Skvortsov authored
VFs cannot read the NAK_COUNTER register. This information is only available through PMFW metrics. Signed-off-by:
Victor Skvortsov <victor.skvortsov@amd.com> Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com>
-
Candice Li authored
Add active_umc_mask to ras init_flags. Signed-off-by:
Candice Li <candice.li@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com>
-
- Mar 18, 2025
-
-
lijo lazar authored
Add description for debug_mask bit options. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com>
-
lijo lazar authored
In certain cases, it's desirable to avoid PMFW log transactions to system memory. Add a mask bit to decide whether to allocate smu pool in device memory or system memory. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
No need to make the workload profile setup dependent on the results of cancelling the delayed work thread. We have all of the necessary checking in place for the workload profile reference counting, so separate the two. As it is now, we can theoretically end up with the call from begin_use happening while the worker thread is executing which would result in the profile not getting set for that submission. It should not affect the reference counting. v2: bail early if the the profile is already active (Lijo) Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
No need to make the workload profile setup dependent on the results of cancelling the delayed work thread. We have all of the necessary checking in place for the workload profile reference counting, so separate the two. As it is now, we can theoretically end up with the call from begin_use happening while the worker thread is executing which would result in the profile not getting set for that submission. It should not affect the reference counting. v2: bail early if the the profile is already active (Lijo) Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Candice Li authored
Add EEPROM I2C address support for smu v13_0_12. Signed-off-by:
Candice Li <candice.li@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com>
-
Alex Deucher authored
We need to make sure the workload profile ref counts are balanced. This isn't currently the case because we can increment the count on submissions, but the decrement may be delayed as work comes in. Track when we enable the workload profile so the references are balanced. v2: switch to a mutex and active flag v3: fix mutex init Fixes: 1443dd3c ("drm/amd/pm: fix and simplify workload handling") Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
We need to make sure the workload profile ref counts are balanced. This isn't currently the case because we can increment the count on submissions, but the decrement may be delayed as work comes in. Track when we enable the workload profile so the references are balanced. v2: switch to a mutex and active flag v3: fix mutex init Fixes: 8fdb3958 ("drm/amdgpu/gfx: add ring helpers for setting workload profile") Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Kenneth Feng <kenneth.feng@amd.com> Tested-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Harish Kasiviswanathan authored
For certain ASICs where dequeue_wait_count don't need to be initialized, pm_config_dequeue_wait_counts_v9 return without filling in the packet information. However, the calling function interprets this as a success and sends the uninitialized packet to firmware causing hang. Fix the above bug by not calling pm_config_dequeue_wait_counts_v9 for ASICs that don't need the value to be initialized. v2: Removed redudant code. Tidy up code based on review comments v3: Don't call pm_config_dequeue_wait_counts_v9 for certain ASICs Fixes: <98a5af81> ("drm/amdkfd: Add pm_config_dequeue_wait_counts API") Signed-off-by:
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by:
Jonathan Kim <jonathan.kim@amd.com>
-
FengWei authored
Use max3() macro instead of nesting max() to simplify the return statement. Signed-off-by:
FengWei <feng.wei8@zte.com.cn> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Christian König authored
We keep the gang submission fence around in adev, make sure that it stays alive. v2: fix memory leak on retry Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
-
lijo lazar authored
XGMI and WAFL share the same versions. Use WAFL version if XGMI version is not present in discovery. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Asad Kamal <asad.kamal@amd.com>
-
Jie1zhang authored
The scheduler should restart only if the reset operation succeeds This ensures that new tasks are only submitted to the queues after a successful reset. Fixes: 9b5d6672 ("drm/amdgpu: Introduce conditional user queue suspension for SDMA resets") Suggested-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Jesse.Zhang <Jesse.zhang@amd.com> Reviewed-by:
Tim Huang <tim.huang@amd.com>
-
Tomasz Pakuła authored
Currently, it seems like the code was carried over from RDNA3 because it assumes two possible values to set. RDNA4, instead of having: 0: min SCLK 1: max SCLK only has 0: SCLK offset This change makes it so it only reports current offset value instead of showing possible min/max values and their indices. Moreover, it now only accepts the offset as a value, without the indice index. Additionally, the lower bound was printed as %u by mistake. Old: OD_SCLK_OFFSET: 0: -500Mhz 1: 1000Mhz OD_MCLK: 0: 97Mhz 1: 1259MHz OD_VDDGFX_OFFSET: 0mV OD_RANGE: SCLK_OFFSET: -500Mhz 1000Mhz MCLK: 97Mhz 1500Mhz VDDGFX_OFFSET: -200mv 0mv New: OD_SCLK_OFFSET: 0Mhz OD_MCLK: 0: 97Mhz 1: 1259MHz OD_VDDGFX_OFFSET: 0mV OD_RANGE: SCLK_OFFSET: -500Mhz 1000Mhz MCLK: 97Mhz 1500Mhz VDDGFX_OFFSET: -200mv 0mv Setting this offset: Old: "s 1 <offset>" New: "s <offset>" Closes: drm/amd#4036 Reviewed-by:
Yang Wang <kevinyang.wang@amd.com> Signed-off-by:
Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
fcui authored
Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
Flora Cui <flora.cui@amd.com>
-
- Mar 14, 2025
-
-
Alex Deucher authored
PCI_CLASS_ACCELERATOR_PROCESSING devices won't ever be the sysfb, so there is no need to free conflicting apertures. Reviewed-by:
Kent Russell <kent.russell@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
Move to probe so we can check the PCI device type and only apply the drm_firmware_drivers_only() check for PCI DISPLAY classes. Also add a module parameter to override the nomodeset kernel parameter as a workaround for platforms that have this hardcoded on their kernel command lines. Reviewed-by:
Kent Russell <kent.russell@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alexander Deucher authored
This reverts commit 08c6e5d0. Reason for revert: missing mutex init Change-Id: Iecf610eb82a3c03ca2a854f603b5e7a722f8c264
-
Taimur Hassan authored
This version brings along following fixes: - Use DPM table clk setting for dml2 soc dscclk - Update static soc table - Fix incorrect fw_state address in dmub_srv - Use HW lock mgr for PSR1 when only one eDP - Revert "Support for reg inbox0 for host->DMUB CMDs" - Change notification of link BW allocation - Fix message for support_edp0_on_dp1 - Guard against setting dispclk low for dcn31x - Prevent VStartup Overflow - Check pipe->stream before passing it to a function Acked-by:
Alex Hung <alex.hung@amd.com> Signed-off-by:
Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
Charlene Liu authored
[WHY] Not like dppclk/dispclk, dml2 will calculate the minimum required clocks. For dscclk, it is used for pure comparision. Reviewed-by:
Alvin Lee <alvin.lee2@amd.com> Signed-off-by:
Charlene Liu <Charlene.Liu@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
Charlene Liu authored
[WHY] Update the static soc table dcn3_5_soc. Reviewed-by:
Alvin Lee <alvin.lee2@amd.com> Signed-off-by:
Charlene Liu <Charlene.Liu@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
Lo-an Chen authored
[WHY] The fw_state in dmub_srv was assigned with wrong address. The address was pointed to the firmware region. [HOW] Fix the firmware state by using DMUB_DEBUG_FW_STATE_OFFSET in dmub_cmd.h. Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Lo-an Chen <lo-an.chen@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
Mario Limonciello authored
[WHY] DMUB locking is important to make sure that registers aren't accessed while in PSR. Previously it was enabled but caused a deadlock in situations with multiple eDP panels. [HOW] Detect if multiple eDP panels are in use to decide whether to use lock. Refactor the function so that the first check is for PSR-SU and then replay is in use to prevent having to look up number of eDP panels for those configurations. Fixes: 06fbedfa ("Revert "drm/amd/display: Use HW lock mgr for PSR1"") Closes: drm/amd#3965 Cc: stable@vger.kernel.org Reviewed-by:
ChiaHsuan Chung <chiahsuan.chung@amd.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
Dillon Varone authored
This reverts commit b4a8503f. Reason: Cursor movement causes system to hang. Reviewed-by:
Aric Cyr <aric.cyr@amd.com> Signed-off-by:
Dillon Varone <dillon.varone@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
Alex Deucher authored
We need to make sure the workload profile ref counts are balanced. This isn't currently the case because we can increment the count on submissions, but the decrement may be delayed as work comes in. Track when we enable the workload profile so the references are balanced. v2: switch to a mutex and active flag Fixes: 8fdb3958 ("drm/amdgpu/gfx: add ring helpers for setting workload profile") Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Kenneth Feng <kenneth.feng@amd.com> Tested-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
[WHY & HOW] The response of DP BW allocation is handled in Outbox ISR. When it failed to request the DP BW allocation, it sent another DPCD request in Outbox ISR immediately. The DP AUX reply also uses the Outbox ISR. So, no AUX reply happened in this case. Change to use HPD IRQ for the notification. Reviewed-by:
Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by:
Cruise Hung <Cruise.Hung@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
[WHY] The info message was wrong when support_edp0_on_dp1 is enabled [HOW] Use correct info message for support_edp0_on_dp1 Fixes: c1037b2e ("drm/amd/display: add a quirk to enable eDP0 on DP1") Reviewed-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
Yilin Chen <Yilin.Chen@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
[WHY] We should never apply a minimum dispclk value while in prepare_bandwidth or while displays are active. This is always an optimizaiton for when all displays are disabled. [HOW] Defer dispclk optimization until safe_to_lower = true and display_count reaches 0. Since 0 has a special value in this logic (ie. no dispclk required) we also need adjust the logic that clamps it for the actual request to PMFW. Reviewed-by:
Charlene Liu <charlene.liu@amd.com> Reviewed-by:
Chris Park <chris.park@amd.com> Reviewed-by:
Eric Yang <eric.yang@amd.com> Signed-off-by:
Jing Zhou <Jing.Zhou@amd.com> Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
[WHY & HOW] Fixed Overflow issue by clamping VStartup to max value of register. Reviewed-by:
Alvin Lee <alvin.lee2@amd.com> Signed-off-by:
Ryan Seto <ryanseto@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
Alex Hung authored
[WHAT & HOW] dp_is_128b_132b_signal dereferences pipe->stream so it is necessary to check it in advance. Also fix erroneous spaces and move a variable declaration to top. Reviewed-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com>
-
HDCP Locality Check is being moved to FW, add debug flags to control its behavior in existing hardware for validation purposes. Signed-off-by:
Dominik Kaszewski <dominik.kaszewski@amd.com> Reviewed-by:
Aurabindo Pillai <aurabindo.pillai@amd.com>
-
Xiang Liu authored
The mistake of computation for remain size of CPER ring will cause unbreakable while cycle when CPER ring overflow. Signed-off-by:
Xiang Liu <xiang.liu@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com>
-
Kenneth Feng authored
Shorten the gfx idle worker timeout. This is to sync with DAL when there is no activity on the screen. Original 1 second can not sync with DAL, so DAL can not apply MALL when the workload type is not bootup default. Signed-off-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Yang Wang <kevinyang.wang@amd.com>
-
Tao Zhou authored
Clear old data and save it in V3 format. v2: only format eeprom data for new ASICs. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com>
-
- Mar 13, 2025
-
-
Alex Deucher authored
There are a number of systems and cloud providers out there that have nomodeset hardcoded in their kernel parameters to block nouveau for the nvidia driver. This prevents the amdgpu driver from loading. Unfortunately the end user cannot easily change this. The preferred way to block modules from loading is to use modprobe.blacklist=<driver>. That is what providers should be using to block specific drivers. Drop the check to allow the driver to load even when nomodeset is specified on the kernel command line. Reviewed-by:
Kent Russell <kent.russell@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
David Belanger authored
Always use MTYPE_UC if UNCACHED flag is specified. This makes kernarg region uncached and it restores usermode cache disable debug flag functionality. Do not set MTYPE_UC for COHERENT flag, on GFX12 coherence is handled by shader code. Signed-off-by:
David Belanger <david.belanger@amd.com> Reviewed-by:
Felix Kuehling <felix.kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Wentao Liang authored
In gfx_v12_0_cp_gfx_load_me_microcode_rs64(), gfx_v12_0_pfp_fini() is incorrectly used to free 'me' field of 'gfx', since gfx_v12_0_pfp_fini() can only release 'pfp' field of 'gfx'. The release function of 'me' field should be gfx_v12_0_me_fini(). Fixes: 52cb80c1 ("drm/amdgpu: Add gfx v12_0 ip block support (v6)") Cc: stable@vger.kernel.org # 6.11+ Signed-off-by:
Wentao Liang <vulab@iscas.ac.cn> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Thadeu Cascardo authored
ctx->dmub_srv will de NULL if the ASIC does not support DMUB, which is tested in dm_dmub_sw_init. However, it will be dereferenced in dmub_hw_lock_mgr_cmd if should_use_dmub_lock returns true. This has been the case since dmub support has been added for PSR1. Fix this by checking for dmub_srv in should_use_dmub_lock. [ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 37.447808] #PF: supervisor read access in kernel mode [ 37.452959] #PF: error_code(0x0000) - not-present page [ 37.458112] PGD 0 P4D 0 [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88 [ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000 [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.572697] Call Trace: [ 37.575152] <TASK> [ 37.577258] ? __die_body+0x66/0xb0 [ 37.580756] ? page_fault_oops+0x3e7/0x4a0 [ 37.584861] ? exc_page_fault+0x3e/0xe0 [ 37.588706] ? exc_page_fault+0x5c/0xe0 [ 37.592550] ? asm_exc_page_fault+0x22/0x30 [ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.601107] dcn10_cursor_lock+0x1e1/0x240 [ 37.605211] program_cursor_attributes+0x81/0x190 [ 37.609923] commit_planes_for_stream+0x998/0x1ef0 [ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0 [ 37.619703] dc_update_planes_and_stream+0x78/0x140 [ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0 [ 37.629832] ? srso_return_thunk+0x5/0x5f [ 37.633847] ? mark_held_locks+0x6d/0xd0 [ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50 [ 37.642135] ? srso_return_thunk+0x5/0x5f [ 37.646148] ? lockdep_hardirqs_on+0x95/0x150 [ 37.650510] ? srso_return_thunk+0x5/0x5f [ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50 [ 37.658883] ? srso_return_thunk+0x5/0x5f [ 37.662897] ? wait_for_common+0x186/0x1c0 [ 37.666998] ? srso_return_thunk+0x5/0x5f [ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170 [ 37.675983] commit_tail+0xf5/0x1c0 [ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0 [ 37.684186] drm_atomic_commit+0xd6/0x100 [ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10 [ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130 [ 37.698054] drm_mode_cursor_common+0x501/0x670 [ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.707572] drm_mode_cursor_ioctl+0x48/0x70 [ 37.711851] drm_ioctl_kernel+0xf2/0x150 [ 37.715781] drm_ioctl+0x363/0x590 [ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.724165] amdgpu_drm_ioctl+0x41/0x80 [ 37.728013] __se_sys_ioctl+0x7f/0xd0 [ 37.731685] do_syscall_64+0x87/0x100 [ 37.735355] ? vma_end_read+0x12/0xe0 [ 37.739024] ? srso_return_thunk+0x5/0x5f [ 37.743041] ? find_held_lock+0x47/0xf0 [ 37.746884] ? vma_end_read+0x12/0xe0 [ 37.750552] ? srso_return_thunk+0x5/0x5f [ 37.754565] ? lock_release+0x1c4/0x2e0 [ 37.758406] ? vma_end_read+0x12/0xe0 [ 37.762079] ? exc_page_fault+0x84/0xe0 [ 37.765921] ? srso_return_thunk+0x5/0x5f [ 37.769938] ? lockdep_hardirqs_on+0x95/0x150 [ 37.774303] ? srso_return_thunk+0x5/0x5f [ 37.778317] ? exc_page_fault+0x84/0xe0 [ 37.782163] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 37.787218] RIP: 0033:0x784aa5ec3059 [ 37.790803] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1d 48 8b 45 c8 64 48 2b 04 25 28 00 0 [ 37.809553] RSP: 002b:0000784a9cdf90e0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 37.817121] RAX: ffffffffffffffda RBX: 0000784a9cdf917c RCX: 0000784aa5ec3059 [ 37.824256] RDX: 0000784a9cdf917c RSI: 00000000c01c64a3 RDI: 0000000000000020 [ 37.831391] RBP: 0000784a9cdf9130 R08: 0000000000000100 R09: 0000000000ff0000 [ 37.838525] R10: 0000000000000000 R11: 0000000000000246 R12: 0000025c01606ed0 [ 37.845657] R13: 0000025c00030200 R14: 00000000c01c64a3 R15: 0000000000000020 [ 37.852799] </TASK> [ 37.854992] Modules linked in: [ 37.864546] gsmi: Log Shutdown Reason 0x03 [ 37.868656] CR2: 0000000000000058 [ 37.871979] ---[ end trace 0000000000000000 ]--- [ 37.880976] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.885954] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.904703] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.909933] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.917068] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000 [ 37.924201] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.931336] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.938469] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.945602] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.953689] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.959435] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.966570] Kernel panic - not syncing: Fatal exception [ 37.971901] Kernel Offset: 0x30200000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 37.982840] gsmi: Log Shutdown Reason 0x02 Fixes: b5c764d6 ("drm/amd/display: Use HW lock mgr for PSR1") Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Cc: stable@vger.kernel.org Cc: Sun peng Li <sunpeng.li@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Daniel Wheeler <daniel.wheeler@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Rodrigo Siqueira <siqueira@igalia.com> Reviewed-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Shaoyun Liu authored
When MES is been used , the set_hw_resource_1 API is required to initialize MES internal context correctly Signed-off-by:
Shaoyun Liu <shaoyun.liu@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
-