- 15 Sep, 2020 40 commits
-
-
Bhawanpreet Lakha authored
[Why] Previously we were only calling add_topology when hdcp was being enabled. Now we call add_topology by default so the ERROR messages are printed if the firmware is not loaded. This error message is not relevant for normal display functionality so no need to print a ERROR message. [How] Change DRM_ERROR to DRM_INFO Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alvin Lee authored
[Why] There are situations where we go from 2 pipe to 1 pipe in MPO, but this isn't a pipe split being lost -- it's a plane disappearing in (i.e. video overlay goes away) so we lose one pipe. In these situations we don't want to disable the pipe in a separate operation from the rest of the pipe programming sequence. We only want to disable a pipe in a separate operation when we're actually disabling pipe split. [How] Make sure the pipe being lost has the same stream AND plane as the old top pipe to ensure. Signed-off-by:
Alvin Lee <alvin.lee2@amd.com> Acked-by:
-
Zhan Liu authored
[Why] PSR needs to be enabled on DCN30. This is the driver part of PSR enablement. Also disabled retired DMCU on driver side, since DMCU is not supported on DCN30 anymore. [How] Add necessary changes to enable PSR on DCN30. Signed-off-by:
Zhan Liu <zhan.liu@amd.com> Acked-by:
-
Roman Li authored
[Why] ABM feature initialization was not executed due to early return. dm_late_init() had an early return in case if DMCU is not used. With the implementation of ABM on DMUB, DMCU can be disabled but ABM still needs to be initialized. [How] Remove verification for DMCU from the top of the function. The existing logic will handle the case when DMCU is not used. Signed-off-by:
Roman Li <roman.li@amd.com> Acked-by:
-
George Shen authored
[Why] The function set_mst_bandwidth is poorly name since it isn't clear what it does, and it also does not reflect any part of the allocation sequence described in the DP spec. [How] Rename the function set_mst_bandwidth to set_throttled_vcp_size. Signed-off-by:
George Shen <george.shen@amd.com> Acked-by:
-
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:
-
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:
-
