- 15 Sep, 2020 39 commits
-
-
Aric Cyr authored
[Why] When pipe locks are being taken we wait for flip pending to clear first. In some cases the pipe mapping is changed and the pending we're checking for will never clear. [How] Don't check disabled pipes for flip pending. Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Acked-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Aidan Gratton authored
[HOW & WHY] Change max EDID size constant to 1280 to support 10-block EDIDs. Signed-off-by:
Aidan Gratton <Aidan.Gratton@amd.com> Acked-by:
-
Ashley Thomas authored
[why] When link training failures occur for eDP, dp_disable_link_phy is called which powers OFF eDP panel. After link training retry delay, the next retry begins by calling dp_enable_link_phy which does not issue a correspnding eDP panel power ON, leaving panel powered OFF which leads to display OFF/dark. [how] Power ON eDP before next link training retry. Signed-off-by:
Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by:
-
Harmanprit Tatla authored
[Why] Currently clearing the wrong bit for CP_IRQ, and logic on when to clear needs to be fixed. [How] Corrected bit to clear and improved logic for decision to clear. Signed-off-by:
Harmanprit Tatla <harmanprit.tatla@amd.com> Acked-by:
-
Wesley Chalmers authored
[WHY] Only the first pipe in ODM combine group should have nonzero recout offset. All other pipes should have recout offset 0; otherwise there will be gaps in the image. [HOW] Set recout.x to 0 if the pipe is not the leftmost ODM pipe. When computing viewports, calculate the horizontal offset of a pipe's src based on the current pipe's position in the ODM group, plus whatever offset the leftmost ODM pipe has; otherwise there will be discontinuity in the image. Since ODM combine can only combine pipes horizontally, nothing needs to be done for recout.y. Signed-off-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Acked-by:
-
Wenjing Liu authored
[why] The cr training aux rd interval is modified without following specs requirements. According to the commit message the change was not intended to modify the value. Therefore it looks like it is caused by a typo in the change. Signed-off-by:
Wenjing Liu <wenjing.liu@amd.com> Acked-by:
-
Aric Cyr authored
Signed-off-by:
-
Anthony Koo authored
Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Rodrigo Siqueira authored
During the load processes for Renoir, our display code needs to retrieve the SMU clock and voltage table, however, this operation can fail which means that we have to check this scenario. Currently, we are not handling this case properly and as a result, we have seen the following dmesg log during the boot: RIP: 0010:rn_clk_mgr_construct+0x129/0x3d0 [amdgpu] ... Call Trace: dc_clk_mgr_create+0x16a/0x1b0 [amdgpu] dc_create+0x231/0x760 [amdgpu] This commit fixes this issue by checking the return status retrieved from the clock table before try to populate any bandwidth. Signed-off-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by:
-
Aric Cyr authored
Disable triplebuffering by default. Signed-off-by:
-
Wenjing Liu authored
Signed-off-by:
-
Joshua Aberback authored
[Why] This assert triggers a false negative because there are more than 4 MPCCs on many asics. [How] - change assert comparisson - remove unused variable Signed-off-by:
Joshua Aberback <joshua.aberback@amd.com> Acked-by:
-
Harmanprit Tatla authored
[Why] Currently we do not clear the CP_IRQ bit upon receiving it. [How] Added a function to clear CP_IRQ bit. Signed-off-by:
-
JinZe.Xu authored
[Why] If plane has changed, dcn20_detect_pipe_changes doesn't update dc_plane_state->update_flags, and the following dcn20_program_pipe can't reprogram hubp correctly. [How] Add a new flags bit "plane_changed" in pipe_ctx->update_flags.If old plane isn’t identical to new plane, this bit will be set and guide “dcn20_program_pipe” to programing HUBP correctly. Signed-off-by:
JinZe.Xu <JinZe.Xu@amd.com> Acked-by:
-
Naveed Ashfaq authored
[why] Changing to smaller modes on OLED panel caused a blue screen crash as driver reported dram change during vactive when it shouldn't [how] Added an extra condition to prevent incorrect dram change timing Signed-off-by:
Naveed Ashfaq <Naveed.Ashfaq@amd.com> Acked-by:
-
Aric Cyr authored
Signed-off-by:
-
Anthony Koo authored
Signed-off-by:
-
Jiansong Chen authored
This avoids smu issue when enabling runtime pptable update for sienna_cichlid and so on. Runtime pptable udpate is needed for test and debug purpose. Signed-off-by:
Jiansong Chen <Jiansong.Chen@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Flora Cui authored
use bool directly Signed-off-by:
Flora Cui <flora.cui@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
-
Mukul Joshi authored
SDMA utilization calculations are enabled/disabled by writing to SDMAx_PUB_DUMMY_REG2 register. Currently, enable this only for Arcturus. Signed-off-by:
Mukul Joshi <mukul.joshi@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Aurabindo Pillai authored
[Why&How] Since there is no need for accessing crtc state in the interrupt handler, interrupts need not be disabled well in advance, and can be moved to commit_tail where it should be. Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Aurabindo Pillai authored
[Why&How] Currently commit_tail holds global locks and wait for dependencies which is against the DRM API contracts. Inorder to fix this, IRQ handler should be able to run without having to access crtc state. Required parameters are copied over so that they can be directly accessed from the interrupt handler Reviewed-by:
-
Aurabindo Pillai authored
[Why&How] To refactor DM IRQ management, all fields used by IRQ is best moved to a separate struct so that main amdgpu_crtc struct need not be changed Location of the new struct shall be in DM Reviewed-by:
-
John Clements authored
Output RAS init status If RAS init fails, teardown RAS context Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
YueHaibing authored
If KFD_SUPPORT_IOMMU_V2 is not set, gcc warns: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device.c:121:37: warning: ‘raven_device_info’ defined but not used [-Wunused-const-variable=] static const struct kfd_device_info raven_device_info = { ^~~~~~~~~~~~~~~~~ As Huang Rui suggested, Raven already has the fallback path, so it should be out of IOMMU v2 flag. Suggested-by:Huang Rui <ray.huang@amd.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
-
Changfeng authored
It needs to add ta DTM/HDCP print to get HDCP/DTM version info when cat amdgpu_firmware_info Signed-off-by:
Changfeng <Changfeng.Zhu@amd.com> Reviewed-by:
-
Jiansong Chen authored
It's in accordance with pmfw 65.8.0 for navy_flounder. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Signed-off-by:
-
Likun Gao authored
Update drive if file for sienna_cichlid. Signed-off-by:
Likun Gao <Likun.Gao@amd.com> Reviewed-by:
-
Andrey Grodzovsky authored
Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
-
Andrey Grodzovsky authored
XGMI support is more complicated than single device support as questions of synchronization between the device recovering from PCI error and other members of the hive are required. Leaving this for next round. Signed-off-by:
-
Andrey Grodzovsky authored
Reuse exsisting functions from GPU recovery to avoid code duplications. Signed-off-by:
-
Andrey Grodzovsky authored
Cache the PCI state on boot and before each case where we might loose it. v2: Add pci_restore_state while caching the PCI state to avoid breaking PCI core logic for stuff like suspend/resume. v3: Extract pci_restore_state from amdgpu_device_cache_pci_state to avoid superflous restores during GPU resets and suspend/resumes. v4: Style fixes. Signed-off-by:
-
Andrey Grodzovsky authored
Wait for HW/PSP initiated ASIC reset to complete before starting the recovery operations. v2: Remove typo Signed-off-by:
-
Andrey Grodzovsky authored
DPC recovery involves ASIC reset just as normal GPU recovery so block SW GPU schedulers and wait on all concurrent GPU resets. Signed-off-by:
-
Andrey Grodzovsky authored
At this point the ASIC is already post reset by the HW/PSP so the HW not in proper state to be configured for suspension, some blocks might be even gated and so best is to avoid touching it. v2: Rename in_dpc to more meaningful name Signed-off-by:
-
Andrey Grodzovsky authored
Add PCI Downstream Port Containment (DPC) with basic recovery functionality v2: remove pci_save_state to avoid breaking suspend/resume v3: Fix style comments v4: Improve description. Signed-off-by:
-
Liu ChengZhe authored
In function flr_work, we should do gpu recovery when no job is running. Fix the logic by inverting it. v2: modify the description Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Liu ChengZhe <ChengZhe.Liu@amd.com> Signed-off-by:
-
Dennis Li authored
In the resume stage of GPU recovery, start_cpsch will call pm_init which set pm->allocated as false, cause the next pm_release_ib has no chance to release ib memory. Add pm_release_ib in stop_cpsch which will be called in the suspend stage of GPU recovery. Reviewed-by:
Dennis Li <Dennis.Li@amd.com> Signed-off-by:
-
Dennis Li authored
The crash log as the below: [Thu Aug 20 23:18:14 2020] general protection fault: 0000 [#1] SMP NOPTI [Thu Aug 20 23:18:14 2020] CPU: 152 PID: 1837 Comm: kworker/152:1 Tainted: G OE 5.4.0-42-generic #46~18.04.1-Ubuntu [Thu Aug 20 23:18:14 2020] Hardware name: GIGABYTE G482-Z53-YF/MZ52-G40-00, BIOS R12 05/13/2020 [Thu Aug 20 23:18:14 2020] Workqueue: events amdgpu_ras_do_recovery [amdgpu] [Thu Aug 20 23:18:14 2020] RIP: 0010:evict_process_queues_cpsch+0xc9/0x130 [amdgpu] [Thu Aug 20 23:18:14 2020] Code: 49 8d 4d 10 48 39 c8 75 21 eb 44 83 fa 03 74 36 80 78 72 00 74 0c 83 ab 68 01 00 00 01 41 c6 45 41 00 48 8b 00 48 39 c8 74 25 <80> 78 70 00 c6 40 6d 01 74 ee 8b 50 28 c6 40 70 00 83 ab 60 01 00 [Thu Aug 20 23:18:14 2020] RSP: 0018:ffffb29b52f6fc90 EFLAGS: 00010213 [Thu Aug 20 23:18:14 2020] RAX: 1c884edb0a118914 RBX: ffff8a0d45ff3c00 RCX: ffff8a2d83e41038 [Thu Aug 20 23:18:14 2020] RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffff8a0e2e4178c0 [Thu Aug 20 23:18:14 2020] RBP: ffffb29b52f6fcb0 R08: 0000000000001b64 R09: 0000000000000004 [Thu Aug 20 23:18:14 2020] R10: ffffb29b52f6fb78 R11: 0000000000000001 R12: ffff8a0d45ff3d28 [Thu Aug 20 23:18:14 2020] R13: ffff8a2d83e41028 R14: 0000000000000000 R15: 0000000000000000 [Thu Aug 20 23:18:14 2020] FS: 0000000000000000(0000) GS:ffff8a0e2e400000(0000) knlGS:0000000000000000 [Thu Aug 20 23:18:14 2020] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Thu Aug 20 23:18:14 2020] CR2: 000055c783c0e6a8 CR3: 00000034a1284000 CR4: 0000000000340ee0 [Thu Aug 20 23:18:14 2020] Call Trace: [Thu Aug 20 23:18:14 2020] kfd_process_evict_queues+0x43/0xd0 [amdgpu] [Thu Aug 20 23:18:14 2020] kfd_suspend_all_processes+0x60/0xf0 [amdgpu] [Thu Aug 20 23:18:14 2020] kgd2kfd_suspend.part.7+0x43/0x50 [amdgpu] [Thu Aug 20 23:18:14 2020] kgd2kfd_pre_reset+0x46/0x60 [amdgpu] [Thu Aug 20 23:18:14 2020] amdgpu_amdkfd_pre_reset+0x1a/0x20 [amdgpu] [Thu Aug 20 23:18:14 2020] amdgpu_device_gpu_recover+0x377/0xf90 [amdgpu] [Thu Aug 20 23:18:14 2020] ? amdgpu_ras_error_query+0x1b8/0x2a0 [amdgpu] [Thu Aug 20 23:18:14 2020] amdgpu_ras_do_recovery+0x159/0x190 [amdgpu] [Thu Aug 20 23:18:14 2020] process_one_work+0x20f/0x400 [Thu Aug 20 23:18:14 2020] worker_thread+0x34/0x410 When GPU hang, user process will fail to create a compute queue whose struct object will be freed later, but driver wrongly add this queue to queue list of the proccess. And then kfd_process_evict_queues will access a freed memory, which cause a system crash. v2: The failure to execute_queues should probably not be reported to the caller of create_queue, because the queue was already created. Therefore change to ignore the return value from execute_queues. Reviewed-by:
-
- 14 Sep, 2020 1 commit
-
-
Daniel Vetter authored
Paul needs 1a21e5b9 ("drm/ingenic: Fix leak of device_node pointer") and 3b5b005e ("drm/ingenic: Fix driver not probing when IPU port is missing") from -fixes to be able to merge further ingenic patches into -next. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
