- 25 Jan, 2022 24 commits
-
-
Hawking Zhang authored
Switch to common helper to query rlcg access flag specified by sriov host driver for gfx10 Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
Zhou, Peng Ju <PengJu.Zhou@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Hawking Zhang authored
Switch to common helper to query rlcg access flag specified by sriov host driver for gfx9 Signed-off-by:
-
Hawking Zhang authored
Query rlc indirect register access approach specified by sriov host driver per ip blocks Signed-off-by:
-
Yang Li authored
Eliminate the follow smatch warning: drivers/gpu/drm/amd/display/dc/dml/calcs/dce_calcs.c:3415 bw_calcs() warn: inconsistent indenting Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Yongzhi Liu authored
[why] Resource release is needed on the error handling path to prevent memory leak. [how] Fix this by adding kfree on the error handling path. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Yongzhi Liu <lyz_cs@pku.edu.cn> Signed-off-by:
-
Jiapeng Chong authored
Clean the following coccicheck warning: ./drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c:7035:2-4: WARNING: possible condition with no effect (if == else). Reported-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Xin Xiong authored
This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. Reviewed-by:
Xin Xiong <xiongx18@fudan.edu.cn> Signed-off-by:
Xin Tan <tanxin.ctf@gmail.com> Signed-off-by:
-
Alex Deucher authored
Some architectures (e.g., ARM) throw an compilation error if the udelay is too long. In general udelays of longer than 2000us are not recommended on any architecture. Switch to msleep in these cases. Reviewed-by:
-
Alex Deucher authored
Some architectures (e.g., ARM) have relatively low udelay limits. On most architectures, anything longer than 2000us is not recommended. Change the check to align with other similar checks in DC. Reviewed-by:
-
Alex Deucher authored
Older radeon boards (r2xx-r5xx) had secondary PCI functions which we solely there for supporting multi-head on OSs with special requirements. Add them to the unsupported list as well so we don't attempt to bind to them. The driver would fail to bind to them anyway, but this does so in a cleaner way that should not confuse the user. Acked-by:
-
Guchun Chen authored
In multiple GPU configuration, when failed to send a SMU message, it's hard to figure out which GPU has such problem. So it's not comfortable to user. [40190.142181] amdgpu: [powerplay] last message was failed ret is 65535 [40190.242420] amdgpu: [powerplay] failed to send message 201 ret is 65535 [40190.392763] amdgpu: [powerplay] last message was failed ret is 65535 [40190.492997] amdgpu: [powerplay] failed to send message 200 ret is 65535 [40190.743575] amdgpu: [powerplay] last message was failed ret is 65535 [40190.843812] amdgpu: [powerplay] failed to send message 282 ret is 65535 Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Guchun Chen authored
NULL pointer check has guarded it already. calltrace: amdgpu_ttm_gart_bind+0x49/0xa0 [amdgpu] amdgpu_ttm_alloc_gart+0x13f/0x180 [amdgpu] amdgpu_bo_create_reserved+0x139/0x2c0 [amdgpu] ? amdgpu_ttm_debugfs_init+0x120/0x120 [amdgpu] amdgpu_bo_create_kernel+0x17/0x80 [amdgpu] amdgpu_ttm_init+0x542/0x5e0 [amdgpu] Fixes: 1b08dfb8 ("drm/amdgpu: remove gart.ready flag") Signed-off-by:
-
Rajib Mahapatra authored
[Why] During resume path, dpcd_set_source_specific_data is taking extra time when core_link_write_dpcd fails on DP_SOURCE_OUI+0x03 and DP_SOURCE_MINIMUM_HBLANK_SUPPORTED. Here,aux->transfer fails with multiple retries and consume significant amount time during S0i3 resume. [How] Not to call dpcd_set_source_specific_data during resume path when there is no oled panel connected and achieve faster resume during S0i3. Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Signed-off-by:
Rajib Mahapatra <rajib.mahapatra@amd.com> Signed-off-by:
-
Evan Quan authored
As all those related APIs are already well protected by adev->pm.mutex. Signed-off-by:
-
Evan Quan authored
As all those related APIs are already well protected by adev->pm.mutex. Signed-off-by:
-
Evan Quan authored
As those APIs related are already well protected by adev->pm.mutex. Signed-off-by:
-
Evan Quan authored
As all those related APIs are already well protected by adev->pm.mutex and smu->message_lock. Signed-off-by:
-
Evan Quan authored
As all those related APIs are already well protected by adev->pm.mutex and smu->message_lock. Signed-off-by:
-
Evan Quan authored
As those related APIs are already protected by adev->pm.mutex. Signed-off-by:
-
Evan Quan authored
As all those APIs are already protected either by adev->pm.mutex or smu->message_lock. Signed-off-by:
-
Evan Quan authored
Suppress the warning below on building htmldocs: drivers/gpu/drm/amd/include/amd_shared.h:103: warning: Enum value 'AMD_IP_BLOCK_TYPE_NUM' not described in enum 'amd_ip_block_type' Fixes: 6ee27ee2 ("drm/amd/pm: avoid duplicate powergate/ungate setting") Signed-off-by:
-
Lang Yu authored
It doesn't work under IP discovery mode. Make it work! Signed-off-by:
Lang Yu <Lang.Yu@amd.com> Reviewed-by:
Alex Deucher <aleander.deucher@amd.com> Signed-off-by:
-
Mario Limonciello authored
Yellow carp has been outputting versions like `1093.24.0`, but this is supposed to be 69.24.0. That is the MSB is being interpreted incorrectly. The MSB is not part of the major version, but has generally been treated that way thus far. It's actually the program, and used to distinguish between two programs from a similar family but different codebase. Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
shaoyunl authored
VF acces the EEPROM is blocked by security policy, we might need other way to get SKUs info for VF v2: squash in compilation fix from Luben Signed-off-by:
shaoyunl <shaoyun.liu@amd.com> Acked-by:
Kent Russell <kent.russell@amd.com> Signed-off-by:
-
- 21 Jan, 2022 2 commits
-
-
Xiaojian Du authored
This patch will fix the page fault caused by uninitialized variables. Error Log: ...... [ 130.246323] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 131.963112] [drm] PCIE GART of 512M enabled (table at 0x0000008000000000). [ 131.963130] BUG: unable to handle page fault for address: 000000000002db80 [ 131.963181] #PF: supervisor write access in kernel mode [ 131.963210] #PF: error_code(0x0002) - not-present page [ 131.963233] PGD 0 P4D 0 [ 131.963253] Oops: 0002 [#1] SMP NOPTI [ 131.963273] CPU: 3 PID: 1411 Comm: modprobe Not tainted 5.13.0+ #1 [ 131.963338] RIP: 0010:osq_lock+0x4d/0x120 [ 131.963381] Code: 10 00 00 00 00 48 c7 02 00 00 00 00 89 42 14 87 07 85 c0 0f 84 d0 00 00 00 83 e8 01 48 98 48 03 0c c5 00 d9 ea 9c 48 89 4a 08 <48> 89 11 44 8b 42 10 45 85 c0 0f 85 af 00 00 00 55 48 89 fe 65 4c [ 131.963460] RSP: 0018:ffffa40481717768 EFLAGS: 00010202 [ 131.963483] RAX: fffffffffffffffe RBX: ffffa40481717920 RCX: 000000000002db80 [ 131.963520] RDX: ffff9256fecedb80 RSI: ffff9256cbed2e80 RDI: ffffa40481717ac4 [ 131.963547] RBP: ffffa40481717808 R08: ffffa40481717920 R09: 00000000ffffffff [ 131.963582] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 [ 131.963609] R13: ffffa40481717ac4 R14: ffffa40481717ab8 R15: ffff9256c9480000 [ 131.963646] FS: 00007f23d9b9c540(0000) GS:ffff9256fecc0000(0000) knlGS:0000000000000000 [ 131.963687] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 131.963721] CR2: 000000000002db80 CR3: 0000000008444000 CR4: 00000000000506e0 [ 131.963758] Call Trace: [ 131.963772] ? __ww_mutex_lock.isra.0+0x3a2/0x760 [ 131.963810] ? prb_read_valid+0x1c/0x20 [ 131.963830] ? console_unlock+0x2fe/0x4f0 [ 131.963849] __ww_mutex_lock_interruptible_slowpath+0x16/0x20 [ 131.963882] ww_mutex_lock_interruptible+0x83/0x90 [ 131.963908] amdgpu_bo_create_reserved+0xf0/0x1e0 [amdgpu] [ 131.964237] amdgpu_bo_create_kernel+0x17/0x80 [amdgpu] [ 131.964509] amdgpu_gmc_vram_checking+0x41/0xf0 [amdgpu] [ 131.964807] gmc_v10_0_hw_init+0x105/0x120 [amdgpu] [ 131.965108] amdgpu_device_init.cold+0x1aa4/0x1e3e [amdgpu] ...... Signed-off-by:
Xiaojian Du <Xiaojian.Du@amd.com> Reviewed-by:
Yang Wang <kevinyang.wang@amd.com> Signed-off-by:
-
Stanley.Yang authored
Pmfw read ecc info registers and store values in eccinfo_table in the following order umc0 ch_inst 0, 1, 2 ... 7 umc1 ch_inst 0, 1, 2 ... 7 ... umc3 ch_inst 0, 1, 2 ... 7 Driver should convert eccinfo_table_idx to channel_index according to channel_idx_tbl. Signed-off-by:
Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by:
Tao Zhou <tao.zhou1@amd.com> Signed-off-by:
-
- 20 Jan, 2022 10 commits
-
-
Zhan Liu authored
[Why] FIFO reset is only necessary for fast boot sequence, where otg is disabled and dig fe is enabled when changing dispclk. Fast boot is only enabled on embedded displays. [How] Change FIFO reset condition to "embedded display only". Signed-off-by:
Zhan Liu <zhan.liu@amd.com> Reviewed-by:
Charlene Liu <charlene.liu@amd.com> Signed-off-by:
-
Zhan Liu authored
[Why] DCN301 has seamless boot enabled. With MPC split enabled at the same time, system will hang. [How] Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have ODM combine enabled on DCN301, pipe split is not necessary here. Signed-off-by:
-
Eric Huang authored
SDMA FW fixes the hang issue for adding heavy-weight TLB flush on Arcturus, so we can enable it. Signed-off-by:
Eric Huang <jinhuieric.huang@amd.com> Acked-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Jonathan Kim authored
Debug VRAM access through SDMA has several broken parts resulting in silent MMIO fallback. BO kernel creation takes the location of the cpu addr pointer, not the pointer itself for address kmap. drm_dev_enter return true on success so change access check. The source BO is reserved but not pinned so find the address using the cursor offset relative to its memory domain start. Signed-off-by:
Jonathan Kim <jonathan.kim@amd.com> Reviewed-by:
-
Christian König authored
That's just a leftover from old radeon days and was preventing CS and GART bindings before the hardware was initialized. But nowdays that is perfectly valid. The only thing we need to warn about are GART binding before the table is even allocated. Signed-off-by:
-
Stanley.Yang authored
Signed-off-by:
-
mziya authored
Remove set but unused variable. warning: variable 'umc_reg_offset' set but not used Signed-off-by:
mziya <Mohammadzafar.ziya@amd.com> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
yipechai authored
Remove repeated calls. Signed-off-by:
yipechai <YiPeng.Chai@amd.com> Reviewed-by:
-
Xiaojian Du authored
This patch will modify a pair of functions for pcie port wreg/rreg. AMD GPU have had an independent NBIO block from SOC15 arch. If the dirver wants to read/write the address space of the pcie devices, it has to go through the NBIO block. This patch will move the pcie port wreg/rreg functions to "amdgpu_device.c", so that to reuse the functions on the future GPU ASICs. Signed-off-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Xiaojian Du authored
This patch will add vram check function for GMC block. It will write pattern data to the vram and then read back from the vram, so that to verify the work status of vram. This patch will cover gmc v6/7/8/9/10. Signed-off-by:
-
- 18 Jan, 2022 4 commits
-
-
Minghao Chi authored
Return value from amdgpu_bo_create_kernel() directly instead of taking this in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
CGEL ZTE <cgel.zte@gmail.com> Signed-off-by:
-
Qiang Ma authored
I met a bug recently and the kernel log: [ 330.171875] radeon 0000:03:00.0: couldn't schedule ib [ 330.175781] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD (-22)! In radeon drivers, using UVD suspend is as follows: if (rdev->has_uvd) { uvd_v1_0_fini(rdev); radeon_uvd_suspend(rdev); } In radeon_ib_schedule function, we check the 'ring->ready' state, but in uvd_v1_0_fini funciton, we've cleared the ready state. So, just modify the suspend code flow to fix error. Reviewed-by:Leo Liu <leo.liu@amd.com> Signed-off-by:
Qiang Ma <maqianga@uniontech.com> Signed-off-by:
-
Yongzhi Liu authored
pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, thus a matching decrement is needed on the error handling path to keep the counter balanced. Signed-off-by:
-
Isabella Basso authored
The calcs folder has FPU code on it, which should be isolated inside the DML folder as per https://patchwork.freedesktop.org/series/93042/. This commit aims single-handedly to correct the location of such FPU code and does not refactor any functions. Changes since v2: - Corrected problems to compile when DCN was disabled. Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
Isabella Basso <isabbasso@riseup.net> Signed-off-by:
-
