- 02 Jul, 2020 35 commits
-
-
Alex Deucher authored
Used for renoir. Acked-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
Renoir uses integrated_system_info table v12. The table has the same layout as v11 with respect to this data. Just reuse the existing code for v12 for stable. Fixes incorrectly reported vram info in the driver output. Acked-by:
-
Evan Quan authored
Fix the compile error below: drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function 'smu_v11_0_init_microcode': >> arch/arc/include/asm/bug.h:22:2: error: implicit declaration of function 'pr_warn'; did you mean 'pci_warn'? [-Werror=implicit-function-declaration] 22 | pr_warn("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \ | ^~~~~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:176:3: note: in expansion of macro 'BUG' 176 | BUG(); Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Changes that are fast don't require updating DLG parameters making this call unnecessary. Considering this is an expensive call it should not be done on every flip. DML touches clocks, p-state support, DLG params and a few other DC internal flags and these aren't expected during fast. A hang has been reported with this change when called on every flip which suggests that modifying these fields is not recommended behavior on fast updates. [How] Guard the validation to only happen if update type isn't FAST. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1191 Fixes: a24eaa5c ("drm/amd/display: Revalidate bandwidth before commiting DC updates") Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by:
Roman Li <Roman.Li@amd.com> Signed-off-by:
-
Pierre-Loup A. Griffais authored
It's otherwise properly supported, just needs exposing to userspace. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Pierre-Loup A. Griffais <pgriffais@valvesoftware.com> Signed-off-by:
-
Joseph Greathouse authored
Add support for GWS in Arcturus, which needs MEC2 firmware #48 or above. Fix the MEC2 version check for Vega 10 GWS support, since Vega 10 firmware adds 0x8000 to the actual firmware revision. We were previously declaring support where it did not exist. Signed-off-by:
Joseph Greathouse <Joseph.Greathouse@amd.com> Reviewed-by:
Kent Russell <kent.russell@amd.com> Signed-off-by:
-
Hawking Zhang authored
This reverts commit 2eee0229. Fallback to a stable base until we have a correct new one Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Monk Liu authored
issue: originally we kickoff IB test asynchronously with driver's init, thus the IB test may still running when the driver loading done (modprobe amdgpu done). if we shutdown VM immediately after amdgpu driver loaded then GPU may hang because the IB test is still running fix: flush the delayed_init routine at the bottom of device_init to avoid driver loading done prior to the IB test completes Signed-off-by:
Monk Liu <Monk.Liu@amd.com> Acked-by:
-
Joseph Greathouse authored
Update PROCESS_QUANTUM, the time the hardware scheduler allows processes to run before switching to other processes when it becomes over-subscribed. Increase this to 10ms, to allow processes to better amortize their task switch times. Update HQD Quantum, the amount of time that an active queue stays attached to the CP before we forcibly switch it for another active queue for fairness. Setting these so that HQD < PROCESS makes it easier to ensure that we get fairness when we have multiple active queues on the device. Otherwise we may start process-swapping before we get to all the queues in a CP. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Dmytro Laktyushkin authored
In case of certain display configurations we want to allow max detile buffer utilization by using 4 to 1 mpc combine Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Eric Bernstein <Eric.Bernstein@amd.com> Acked-by:
Eryk Brol <eryk.brol@amd.com> Signed-off-by:
-
Aric Cyr authored
Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Acked-by:
-
Jing Zhou authored
[Why] Register key for AE or QA do regression test. New edid status for check. [How] Add register key edid_read_retry_times. Add new edid status EDID_FALL_BACK. Signed-off-by:
Jing Zhou <Jing.Zhou@amd.com> Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
-
Anthony Koo authored
[Header Changes] - Add command for notification of active streams to DMUB Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Jaehyun Chung authored
[Why] In cases where refresh range is slightly below 10, FreeSync is not active or supported. Need to round values before checking refresh range in order to have FreeSync supported in these cases. [How] Remove redundant values and round values before checking valid refresh range. Signed-off-by:
Jaehyun Chung <jaehyun.chung@amd.com> Reviewed-by:
-
Anthony Koo authored
Signed-off-by:
-
jinlong zhang authored
[Why] For special DP convert VGA dongle, core_link_read_dpcd for DP_DOWNSTREAM_PORT_0 always return fail, then dongle_type will be set to DISPLAY_DONGLE_NONE, which will cause desktop resolution abnormal. [How] If dpcd for DP_DOWNSTREAM_PORT_0 read fail, skip set dongle_type = DISPLAY_DONGLE_NONE. Signed-off-by:
jinlong zhang <jinlong.zhang@amd.com> Reviewed-by:
Wenjing Liu <Wenjing.Liu@amd.com> Acked-by:
-
Yongqiang Sun authored
[Why] SMU may return error code to driver, but driver only check if response is OK. [How] Check SMU response instead of reg_wait, assert in case of reponse isn't OK. Signed-off-by:
Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Anthony Koo authored
Signed-off-by:
-
Joshua Aberback authored
[Why] We want to keep the same buffer allocated for use during multiple hardware initializations. [How] - allocate gpu memory buffer on clock manager construct - free gpu memory buffer on clock manager destruct Signed-off-by:
Joshua Aberback <joshua.aberback@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
Wyatt Wood authored
[Why] Debug flags are not set by default. [How] Set debug flags to 0 Signed-off-by:
Wyatt Wood <wyatt.wood@amd.com> Reviewed-by:
-
Wenhui Sheng authored
The legacy way to initialize discovery_tmr_size is using DISCOVERY_TMR_SIZE, while after we reduce DISCOVERY_TMR_SIZE from 64KB to 4KB, variable discovery_tmr_size is also reduced to 4KB, this is not correct, it still should be 64KB, discovery_tmr_size will be used to calculate ip_discovery reserved mem's start address and size. Using DISCOVERY_TMR_OFFSET to init discovery_tmr_size instead. Signed-off-by:
Wenhui Sheng <Wenhui.Sheng@amd.com> Reviewed-by:
-
Evan Quan authored
To follow conventional style. And this unnecessary "@" confuses our userspace tool. Signed-off-by:
-
Likun Gao authored
Update sienna_cichlid driver if header file to match pptable changes. Signed-off-by:
Likun Gao <Likun.Gao@amd.com> Acked-by:
-
Likun Gao authored
Copy board parameters directly instead of set each parameter for sienna_cichlid. Signed-off-by:
-
Wenhui Sheng authored
Only read first 4K data instead of whole TMR block, so we can reduce the time in full access mode. Signed-off-by:
-
Wenhui Sheng authored
After we move request full access before set ip blocks, we can merge atombios init block of SRIOV and baremetal together. Signed-off-by:
-
Wenhui Sheng authored
From SIENNA_CICHLID, HW introduce a new protection feature which can control the FB, doorbell and MMIO write access for VF, so guest driver should request full access before ip discovery, or we couldn't access ip discovery data in FB. Signed-off-by:
-
Wenhui Sheng authored
Init soc15 reg base early enough so we can touch mailbox related registers in request full access for sriov before set_ip_blocks, vi&nv arch doesn't use reg base in virt ops. v2: fix reg_base_init missed in bare metal case. Signed-off-by:
-
Wenhui Sheng authored
Move request init data to virt detection func, so we can insert request full access between request init data and set ip blocks. Signed-off-by:
-
Felix Kuehling authored
When there is no graphics support, KFD can use more of the VMIDs. Graphics VMIDs are only used for video decoding/encoding and post processing. With two VCE engines, there is no reason to reserve more than 2 VMIDs for that. Signed-off-by:
-
Felix Kuehling authored
The KFD VMID assignment was hard-coded in a few places. Consolidate that in a single variable adev->vm_manager.first_kfd_vmid. The value is still assigned in gmc-ip-version-specific code. Signed-off-by:
-
Alex Jivin authored
Port functionality from the Radeon driver to support UVD and VCE power management. Signed-off-by:
Alex Jivin <alex.jivin@amd.com> Reviewed-by:
-
Alex Jivin authored
Port functionality from the Radeon driver to support VCE clock control. Signed-off-by:
-
Alex Jivin authored
Port functionality from the Radeon driver to support UVD clock control. Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-next-5.9-2020-07-01: amdgpu: - DC DMUB updates - HDCP fixes - Thermal interrupt fixes - Add initial support for Sienna Cichlid GPU - Add support for unique id on Arcturus - Major swSMU code cleanup - Skip BAR resizing if the bios already did id - Fixes for DCN bandwidth calculations - Runtime PM reference count fixes - Add initial UVD support for SI - Add support for ASSR on eDP links - Lots of misc fixes and cleanups - Enable runtime PM on vega10 boards that support BACO - RAS fixes - SR-IOV fixes - Use IP discovery table on renoir - DC stream synchronization fixes amdkfd: - Track SDMA usage per process - Fix GCC10 compiler warnings - Locking fix radeon: - Default to on chip GART for AGP boards on all arches - Runtime PM reference count fixes UAPI: - Update comments to clarify MTYPE From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701155041.1102829-1-alexander.deucher@amd.comSigned-off-by:
Dave Airlie <airlied@redhat.com>
-
- 01 Jul, 2020 5 commits
-
-
Ivan Mironov authored
I updated my system with Radeon VII from kernel 5.6 to kernel 5.7, and following started to happen on each boot: ... BUG: kernel NULL pointer dereference, address: 0000000000000128 ... CPU: 9 PID: 1940 Comm: modprobe Tainted: G E 5.7.2-200.im0.fc32.x86_64 #1 Hardware name: System manufacturer System Product Name/PRIME X570-P, BIOS 1407 04/02/2020 RIP: 0010:lock_bus+0x42/0x60 [amdgpu] ... Call Trace: i2c_smbus_xfer+0x3d/0xf0 i2c_default_probe+0xf3/0x130 i2c_detect.isra.0+0xfe/0x2b0 ? kfree+0xa3/0x200 ? kobject_uevent_env+0x11f/0x6a0 ? i2c_detect.isra.0+0x2b0/0x2b0 __process_new_driver+0x1b/0x20 bus_for_each_dev+0x64/0x90 ? 0xffffffffc0f34000 i2c_register_driver+0x73/0xc0 do_one_initcall+0x46/0x200 ? _cond_resched+0x16/0x40 ? kmem_cache_alloc_trace+0x167/0x220 ? do_init_module+0x23/0x260 do_init_module+0x5c/0x260 __do_sys_init_module+0x14f/0x170 do_syscall_64+0x5b/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... Error appears when some i2c device driver tries to probe for devices using adapter registered by `smu_v11_0_i2c_eeprom_control_init()`. Code supporting this adapter requires `adev->psp.ras.ras` to be not NULL, which is true only when `amdgpu_ras_init()` detects HW support by calling `amdgpu_ras_check_supported()`. Before 9015d60c, adapter was registered by -> amdgpu_device_ip_init() -> amdgpu_ras_recovery_init() -> amdgpu_ras_eeprom_init() -> smu_v11_0_i2c_eeprom_control_init() after verifying that `adev->psp.ras.ras` is not NULL in `amdgpu_ras_recovery_init()`. Currently it is registered unconditionally by -> amdgpu_device_ip_init() -> pp_sw_init() -> hwmgr_sw_init() -> vega20_smu_init() -> smu_v11_0_i2c_eeprom_control_init() Fix simply adds HW support check (ras == NULL => no support) before calling `smu_v11_0_i2c_eeprom_control_{init,fini}()`. Please note that there is a chance that similar fix is also required for CHIP_ARCTURUS. I do not know whether any actual Arcturus hardware without RAS exist, and whether calling `smu_i2c_eeprom_init()` makes any sense when there is no HW support. Cc: stable@vger.kernel.org Fixes: 9015d60c ("drm/amdgpu: Move EEPROM I2C adapter to amdgpu_device") Signed-off-by:
Ivan Mironov <mironov.ivan@gmail.com> Tested-by:
Bjorn Nostvold <bjorn.nostvold@gmail.com> Signed-off-by:
-
Alex Deucher authored
The failures with ROCm only happen with noretry=1, so enable runtime pm when noretry=0 (the current default). Reviewed-by:
Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com> Signed-off-by:
-
Alex Deucher authored
Add a switch statement to simplify asic checks. Note that BACO is not supported on APUs, so there is no need to check them. Reviewed-by:
-
Nirmoy Das authored
The release_firmware() function is NULL tolerant so we do not need to check for NULL param before calling it. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
-
Mukul Joshi authored
[ 150.887733] ====================================================== [ 150.893903] WARNING: possible circular locking dependency detected [ 150.905917] ------------------------------------------------------ [ 150.912129] kfdtest/4081 is trying to acquire lock: [ 150.917002] ffff8f7f3762e118 (&mm->mmap_sem#2){++++}, at: __might_fault+0x3e/0x90 [ 150.924490] but task is already holding lock: [ 150.930320] ffff8f7f49d229e8 (&dqm->lock_hidden){+.+.}, at: destroy_queue_cpsch+0x29/0x210 [amdgpu] [ 150.939432] which lock already depends on the new lock. [ 150.947603] the existing dependency chain (in reverse order) is: [ 150.955074] -> #3 (&dqm->lock_hidden){+.+.}: [ 150.960822] __mutex_lock+0xa1/0x9f0 [ 150.964996] evict_process_queues_cpsch+0x22/0x120 [amdgpu] [ 150.971155] kfd_process_evict_queues+0x3b/0xc0 [amdgpu] [ 150.977054] kgd2kfd_quiesce_mm+0x25/0x60 [amdgpu] [ 150.982442] amdgpu_amdkfd_evict_userptr+0x35/0x70 [amdgpu] [ 150.988615] amdgpu_mn_invalidate_hsa+0x41/0x60 [amdgpu] [ 150.994448] __mmu_notifier_invalidate_range_start+0xa4/0x240 [ 151.000714] copy_page_range+0xd70/0xd80 [ 151.005159] dup_mm+0x3ca/0x550 [ 151.008816] copy_process+0x1bdc/0x1c70 [ 151.013183] _do_fork+0x76/0x6c0 [ 151.016929] __x64_sys_clone+0x8c/0xb0 [ 151.021201] do_syscall_64+0x4a/0x1d0 [ 151.025404] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 151.030977] -> #2 (&adev->notifier_lock){+.+.}: [ 151.036993] __mutex_lock+0xa1/0x9f0 [ 151.041168] amdgpu_mn_invalidate_hsa+0x30/0x60 [amdgpu] [ 151.047019] __mmu_notifier_invalidate_range_start+0xa4/0x240 [ 151.053277] copy_page_range+0xd70/0xd80 [ 151.057722] dup_mm+0x3ca/0x550 [ 151.061388] copy_process+0x1bdc/0x1c70 [ 151.065748] _do_fork+0x76/0x6c0 [ 151.069499] __x64_sys_clone+0x8c/0xb0 [ 151.073765] do_syscall_64+0x4a/0x1d0 [ 151.077952] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 151.083523] -> #1 (mmu_notifier_invalidate_range_start){+.+.}: [ 151.090833] change_protection+0x802/0xab0 [ 151.095448] mprotect_fixup+0x187/0x2d0 [ 151.099801] setup_arg_pages+0x124/0x250 [ 151.104251] load_elf_binary+0x3a4/0x1464 [ 151.108781] search_binary_handler+0x6c/0x210 [ 151.113656] __do_execve_file.isra.40+0x7f7/0xa50 [ 151.118875] do_execve+0x21/0x30 [ 151.122632] call_usermodehelper_exec_async+0x17e/0x190 [ 151.128393] ret_from_fork+0x24/0x30 [ 151.132489] -> #0 (&mm->mmap_sem#2){++++}: [ 151.138064] __lock_acquire+0x11a1/0x1490 [ 151.142597] lock_acquire+0x90/0x180 [ 151.146694] __might_fault+0x68/0x90 [ 151.150879] read_sdma_queue_counter+0x5f/0xb0 [amdgpu] [ 151.156693] update_sdma_queue_past_activity_stats+0x3b/0x90 [amdgpu] [ 151.163725] destroy_queue_cpsch+0x1ae/0x210 [amdgpu] [ 151.169373] pqm_destroy_queue+0xf0/0x250 [amdgpu] [ 151.174762] kfd_ioctl_destroy_queue+0x32/0x70 [amdgpu] [ 151.180577] kfd_ioctl+0x223/0x400 [amdgpu] [ 151.185284] ksys_ioctl+0x8f/0xb0 [ 151.189118] __x64_sys_ioctl+0x16/0x20 [ 151.193389] do_syscall_64+0x4a/0x1d0 [ 151.197569] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 151.203141] other info that might help us debug this: [ 151.211140] Chain exists of: &mm->mmap_sem#2 --> &adev->notifier_lock --> &dqm->lock_hidden [ 151.222535] Possible unsafe locking scenario: [ 151.228447] CPU0 CPU1 [ 151.232971] ---- ---- [ 151.237502] lock(&dqm->lock_hidden); [ 151.241254] lock(&adev->notifier_lock); [ 151.247774] lock(&dqm->lock_hidden); [ 151.254038] lock(&mm->mmap_sem#2); This commit fixes the warning by ensuring get_user() is not called while reading SDMA stats with dqm_lock held as get_user() could cause a page fault which leads to the circular locking scenario. Signed-off-by:Mukul Joshi <mukul.joshi@amd.com> Reviewed-by:
-
