- 24 Aug, 2021 1 commit
-
-
Eric Yang authored
[Why] A cleaner solution, only done once on boot. [How] Remove previous workaround and configure an extra vmid one time on boot Reviewed-by:
Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com> Acked-by:
Solomon Chiu <solomon.chiu@amd.com> Signed-off-by:
Eric Yang <Eric.Yang2@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
- 20 Aug, 2021 3 commits
-
-
Michel Dänzer authored
schedule_delayed_work does not push back the work if it was already scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms after the first time GFXOFF was disabled and re-enabled, even if GFXOFF was disabled and re-enabled again during those 100 ms. This resulted in frame drops / stutter with the upcoming mutter 41 release on Navi 14, due to constantly enabling GFXOFF in the HW and disabling it again (for getting the GPU clock counter). To fix this, call cancel_delayed_work_sync when the disable count transitions from 0 to 1, and only schedule the delayed work on the reverse transition, not if the disable count was already 0. This makes sure the delayed work doesn't run at unexpected times, and allows it to be lock-free. v2: * Use cancel_delayed_work_sync & mutex_trylock instead of mod_delayed_work. v3: * Make amdgpu_device_delay_enable_gfx_off lock-free (Christian König) v4: * Fix race condition between amdgpu_gfx_off_ctrl incrementing adev->gfx.gfx_off_req_count and amdgpu_device_delay_enable_gfx_off checking for it to be 0 (Evan Quan) Cc: stable@vger.kernel.org Reviewed-by:
Evan Quan <evan.quan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> # v3 Acked-by: Christian König <christian.koenig@amd.com> # v3 Signed-off-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
-
Christian König authored
For some reason we run into an use case where a BO is already pinned into GTT, but should be pinned into VRAM|GTT again. Handle that case gracefully as well. Reviewed-by:
Shashank Sharma <Shashank.sharma@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Evan Quan authored
Considering Arcturus is a dedicated ASIC for computing, it will be more proper to drop the support for fan speed reading and setting. That's on the TODO list. Signed-off-by:
Rui Teng <rui.teng@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
-
- 18 Aug, 2021 9 commits
-
-
Lukas Bulwahn authored
Commit 04ed8459 ("drm/amdgpu: remove chash") removes the chash architecture and its corresponding config CHASH. There is still a reference to CHASH in the config DRM_AMDGPU in ./drivers/gpu/drm/Kconfig. Remove this obsolete reference to config CHASH. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_err error message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
YuBiao Wang authored
[Why] In some cases when we unload driver, warning call trace will show up in vram_mgr_fini which claims that LRU is not empty, caused by the ttm bo inside delay deleted queue. [How] We should flush delayed work to make sure the delay deleting is done. Signed-off-by:
YuBiao Wang <YuBiao.Wang@amd.com> Reviewed-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
-
Candice Li authored
Signed-off-by:
Candice Li <candice.li@amd.com> Reviewed-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
Hawking Zhang authored
aldebaran supports up to 16 xgmi physical nodes. Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
-
Evan Quan authored
We have a S3 issue on that SKU with BACO enabled. Will bring back this when that root caused. Signed-off-by:
-
Zhan Liu authored
[why] dcn301_calculate_wm_and_dl() causes flickering when external monitor is connected. This issue has been fixed before by commit 0e4c0ae5 ("drm/amdgpu/display: drop dcn301_calculate_wm_and_dl for now"), however part of the fix was gone after commit 2cbcb78c ("Merge tag 'amd-drm-next-5.13-2021-03-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next"). [how] Use dcn30_calculate_wm_and_dlg() instead as in the original fix. Fixes: 2cbcb78c ("Merge tag 'amd-drm-next-5.13-2021-03-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next") Signed-off-by:
Nikola Cornij <nikola.cornij@amd.com> Reviewed-by:
Zhan Liu <zhan.liu@amd.com> Tested-by:
Oliver Logush <oliver.logush@amd.com> Signed-off-by:
-
Zhigang Luo authored
MMSCH 1.0 doesn't have major/minor version, only verison. Signed-off-by:
Zhigang Luo <zhigang.luo@amd.com> Reviewed by Shaoyun.liu <Shaoyun.liu@amd.com> Signed-off-by:
-
Jonathan Kim authored
The TA has a limit to the amount of data that can be retrieved from GET_TOPOLOGY. For setups that exceed this limit, the xGMI topology needs to be re-initialized and data needs to be re-fetched from the extended link records by setting a flag in the shared command buffer. The number of hops and the number of links must be accumulated by the driver. Other data points are all fetched from the first request. Because the TA has already exceeded its link record limit, it cannot hold bidirectional information. Otherwise the driver would have to do more than two fetches so the driver has to reflect the topology information in the opposite direction. v2: squashed with internal reviewed fix Signed-off-by:
Jonathan Kim <jonathan.kim@amd.com> Reviewed-by:
-
- 16 Aug, 2021 27 commits
-
-
Nathan Chancellor authored
Clang + -Wimplicit-fallthrough warns: drivers/gpu/drm/radeon/radeon_fb.c:170:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] default: ^ drivers/gpu/drm/radeon/radeon_fb.c:170:2: note: insert 'break;' to avoid fall-through default: ^ break; 1 warning generated. Clang's version of this warning is a little bit more pedantic than GCC's. Add the missing break to satisfy it to match what has been done all over the kernel tree. Reviewed-by:Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Aric Cyr authored
This version brings along following fixes: - Ensure DCN save init registers after VM setup - Fix multi-display support for idle opt workqueue - Use vblank control events for PSR enable/disable - Create default dc_sink when fail reading EDID under MST Acked-by:
Wayne Lin <wayne.lin@amd.com> Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Tested-by:
-
Anthony Koo authored
Acked-by:
Anthony Koo <Anthony.Koo@amd.com> Tested-by:
-
Nicholas Kazlauskas authored
[Why] Compilation of the workqueue fails if not building with the DCN config option set. [How] Guard calls to the flush with the DCN config option to fix the build. Reviewed-by:
Roman Li <Roman.Li@amd.com> Acked-by:
-
Jake Wang authored
[Why] DM initializes VM context after DMCUB initialization. This results in loss of DCN_VM_CONTEXT registers after z10. [How] Notify DMCUB when VM setup is complete, and have DMCUB save init registers. v2: squash in CONFIG_DRM_AMD_DC_DCN3_1 fix Reviewed-by:
Jake Wang <haonan.wang2@amd.com> Tested-by:
-
Nicholas Kazlauskas authored
[Why] PSR can disable the HUBP along with the OTG when PSR is active. We'll hit a pageflip timeout when the OTG is disable because we're no longer updating the CRTC vblank counter and the pflip high IRQ will not fire on the flip. In order to flip the page flip timeout occur we should modify the enter/exit conditions to match DRM requirements. [How] Use our deferred handlers for DRM vblank control to notify DMCU(B) when it can enable or disable PSR based on whether vblank is disabled or enabled respectively. We'll need to pass along the stream with the notification now because we want to access the CRTC state while the CRTC is locked to get the stream state prior to the commit. Retain a reference to the stream so it remains safe to continue to access and release that reference once we're done with it. Enable/disable logic follows what we were previously doing in update_planes. The workqueue has to be flushed before programming streams or planes to ensure that we exit out of idle optimizations and PSR before these events occur if necessary. To keep the skip count logic the same to avoid FBCON PSR enablement requires copying the allow condition onto the DM IRQ parameters - a field that we can actually access from the worker. Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] The current implementation for idle optimization support only has a single work item that gets reshuffled into the system workqueue whenever we receive an enable or disable event. We can have mismatched events if the work hasn't been processed or if we're getting control events from multiple displays at once. This fixes this issue and also makes the implementation usable for PSR control - which will be addressed in another patch. [How] We need to be able to flush remaining work out on demand for driver stop and psr disable so create a driver specific workqueue instead of using the system one. The workqueue will be single threaded to guarantee the ordering of enable/disable events. Refactor the queue to allocate the control work and deallocate it after processing it. Pass the acrtc directly to make it easier to handle psr enable/disable in a later patch. Rename things to indicate that it's not just MALL specific. Reviewed-by:
-
Wayne Lin authored
[Why] While reading remote EDID via Startech 1-to-4 hub, occasionally we won't get response in time and won't light up corresponding monitor. Ideally, we can still add generic modes for userspace to choose to try to light up the monitor and which is done in drm_helper_probe_single_connector_modes(). So the main problem here is that we fail .mode_valid since we don't create remote dc_sink for this case. [How] Also add default dc_sink if we can't get the EDID. Reviewed-by:
-
Evan Quan authored
These registers have different address from other SMU V11 ASICs. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Evan Quan authored
As the fan control was guarded under manual mode before fan speed RPM/PWM setting. Thus the extra check is totally redundant. Signed-off-by:
-
Evan Quan authored
Currently, the readout of fan speed pwm is transited into percent-based and then pwm-based. However, the transition into percent-based is totally unnecessary and make the final output less accurate. Signed-off-by:
-
Evan Quan authored
The relationship "PWM = RPM / smu->fan_max_rpm" between fan speed PWM and RPM is not true for SMU11 ASICs. So, we need a new way to retrieving the fan speed RPM. Signed-off-by:
-
Evan Quan authored
The relationship "PWM = RPM / smu->fan_max_rpm" between fan speed PWM and RPM is not true for SMU11 ASICs. So, we need a new way to retrieving the fan speed PWM. Signed-off-by:
-
Evan Quan authored
As the relationship "PWM = RPM / smu->fan_max_rpm" between fan speed PWM and RPM is not true for SMU11 ASICs. So, both the RPM and PWM settings need to be saved. Signed-off-by:
-
Evan Quan authored
The relationship "PWM = RPM / smu->fan_max_rpm" between fan speed PWM and RPM is not true for SMU11 ASICs. So, we need a new way to perform the fan speed RPM setting. Signed-off-by:
-
Candice Li authored
Delete ras_if->name in the RAS ctx structure and remove related lines. Signed-off-by:
-
Yifan Zhang authored
KFDSVMRangeTest.SetGetAttributesTest randomly fails in stress test. Note: Google Test filter = KFDSVMRangeTest.* [==========] Running 18 tests from 1 test case. [----------] Global test environment set-up. [----------] 18 tests from KFDSVMRangeTest [ RUN ] KFDSVMRangeTest.BasicSystemMemTest [ OK ] KFDSVMRangeTest.BasicSystemMemTest (30 ms) [ RUN ] KFDSVMRangeTest.SetGetAttributesTest [ ] Get default atrributes /home/yifan/brahma/libhsakmt/tests/kfdtest/src/KFDSVMRangeTest.cpp:154: Failure Value of: expectedDefaultResults[i] Actual: 4294967295 Expected: outputAttributes[i].value Which is: 0 /home/yifan/brahma/libhsakmt/tests/kfdtest/src/KFDSVMRangeTest.cpp:154: Failure Value of: expectedDefaultResults[i] Actual: 4294967295 Expected: outputAttributes[i].value Which is: 0 /home/yifan/brahma/libhsakmt/tests/kfdtest/src/KFDSVMRangeTest.cpp:152: Failure Value of: expectedDefaultResults[i] Actual: 4 Expected: outputAttributes[i].type Which is: 2 [ ] Setting/Getting atrributes [ FAILED ] the root cause is that svm work queue has not finished when svm_range_get_attr is called, thus some garbage svm interval tree data make svm_range_get_attr get wrong result. Flush work queue before iterate svm interval tree. Signed-off-by:
Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Kenneth Feng authored
change the workload type for some cards as it is needed. Signed-off-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
-
Kenneth Feng authored
This reverts commit 0979d432. Revert this because it does not apply to all the cards. Signed-off-by:
-
Candice Li authored
Signed-off-by:
-
Jiange Zhao authored
When guest received FLR notification from host, it would lock adapter into reset state. There will be no more job submission and hardware access after that. Then it should send a response to host that it has prepared for host reset. Signed-off-by:
Jiange Zhao <Jiange.Zhao@amd.com> Signed-off-by:
Peng Ju Zhou <PengJu.Zhou@amd.com> Reviewed-by:
Emily.Deng <Emily.Deng@amd.com> Signed-off-by:
-
Kevin Wang authored
the following clock is only support voltage DPM, change attribute to RO: 1. pp_dpm_sclk 2. pp_dpm_mclk 3. pp_dpm_fclk Signed-off-by:
Kevin Wang <kevin1.wang@amd.com> Reviewed-by:
-
Kevin Wang authored
the following message is allowed in sriov mode: 1. GetEnabledSmuFeaturesLow 2. GetEnabledSmuFeaturesHigh Signed-off-by:
-
Kevin Wang authored
v1: 1. change return value to avoid smu driver probe fails when FEATURE_PPT is not enabled. 2. if FEATURE_PPT is not enabled, set power limit value to 0. v2: instead dev_err with dev_warn Signed-off-by:
-
Kevin Wang authored
v1: 1. skip to load smu firmware in sriov mode for aldebaran chip 2. using vbios pptable if in sriov mode. v2: clean up smu driver code in sriov code path Signed-off-by:
-
Kevin Wang authored
the following feature is wrong, it will cause sysnode of pp_features show error: 1. DPM_XGMI 2. VCN_DPM Signed-off-by:
-
Jack Zhang authored
Why: Previously hw fence is alloced separately with job. It caused historical lifetime issues and corner cases. The ideal situation is to take fence to manage both job and fence's lifetime, and simplify the design of gpu-scheduler. How: We propose to embed hw_fence into amdgpu_job. 1. We cover the normal job submission by this method. 2. For ib_test, and submit without a parent job keep the legacy way to create a hw fence separately. v2: use AMDGPU_FENCE_FLAG_EMBED_IN_JOB_BIT to show that the fence is embedded in a job. v3: remove redundant variable ring in amdgpu_job v4: add tdr sequence support for this feature. Add a job_run_counter to indicate whether this job is a resubmit job. v5 add missing handling in amdgpu_fence_enable_signaling Signed-off-by:
Jingwen Chen <Jingwen.Chen2@amd.com> Signed-off-by:
Jack Zhang <Jack.Zhang7@hotmail.com> Reviewed-by:
-
