- 25 Mar, 2020 11 commits
-
-
Alex Deucher authored
Check the platform caps in the vbios pptable to decide whether to enable automatic AC/DC transitions. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
Check of the pointer exists and we are actually on AC power. v2: fix error message to reflect AC/DC mode. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043Reviewed-by:
-
Evan Quan authored
PMFW may boots those ASICs with DC mode. Need to set it back to AC mode. v2: split from Evan's original patch (Alex) Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043Reviewed-by:
-
Alex Deucher authored
The smu_v11_0 version works for navi1x. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043Reviewed-by:
-
Alex Deucher authored
Add a common smu11 helper to set the AC/DC power source. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043Reviewed-by:
-
Evan Quan authored
This is needed to tell the SMU firmware what state is in in certain cases. DC mode does not allow overclocking for example. v2: split Evan's original patch (Alex) Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043Reviewed-by:
-
Yintian Tao authored
There is one one corner case at dma_fence_signal_locked which will raise the NULL pointer problem just like below. ->dma_fence_signal ->dma_fence_signal_locked ->test_and_set_bit here trigger dma_fence_release happen due to the zero of fence refcount. ->dma_fence_put ->dma_fence_release ->drm_sched_fence_release_scheduled ->call_rcu here make the union fled “cb_list” at finished fence to NULL because struct rcu_head contains two pointer which is same as struct list_head cb_list Therefore, to hold the reference of finished fence at drm_sched_process_job to prevent the null pointer during finished fence dma_fence_signal [ 732.912867] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 732.914815] #PF: supervisor write access in kernel mode [ 732.915731] #PF: error_code(0x0002) - not-present page [ 732.916621] PGD 0 P4D 0 [ 732.917072] Oops: 0002 [#1] SMP PTI [ 732.917682] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G OE 5.4.0-rc7 #1 [ 732.918980] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 [ 732.920906] RIP: 0010:dma_fence_signal_locked+0x3e/0x100 [ 732.938569] Call Trace: [ 732.939003] <IRQ> [ 732.939364] dma_fence_signal+0x29/0x50 [ 732.940036] drm_sched_fence_finished+0x12/0x20 [gpu_sched] [ 732.940996] drm_sched_process_job+0x34/0xa0 [gpu_sched] [ 732.941910] dma_fence_signal_locked+0x85/0x100 [ 732.942692] dma_fence_signal+0x29/0x50 [ 732.943457] amdgpu_fence_process+0x99/0x120 [amdgpu] [ 732.944393] sdma_v4_0_process_trap_irq+0x81/0xa0 [amdgpu] v2: hold the finished fence at drm_sched_process_job instead of amdgpu_fence_process v3: resume the blank line Signed-off-by:Yintian Tao <yttao@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Dennis Li authored
Set ComputePGMRSRC1.VGPRS as 0x3f to clear all ArcVGPRs. Signed-off-by:
Dennis Li <Dennis.Li@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Mario Kleiner authored
Commit '16f17eda ("drm/amd/display: Send vblank and user events at vsartup for DCN")' introduces a new way of pageflip completion handling for DCN, and some trouble. The current implementation introduces a race condition, which can cause pageflip completion events to be sent out one vblank too early, thereby confusing userspace and causing flicker: prepare_flip_isr(): 1. Pageflip programming takes the ddev->event_lock. 2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED 3. Releases ddev->event_lock. --> Deadline for surface address regs double-buffering passes on target pipe. 4. dc_commit_updates_for_stream() MMIO programs the new pageflip into hw, but too late for current vblank. => pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete in current vblank due to missing the double-buffering deadline by a tiny bit. 5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires, dm_dcn_crtc_high_irq() gets called. 6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the pageflip has been completed/will complete in this vblank and sends out pageflip completion event to userspace and resets pflip_status = AMDGPU_FLIP_NONE. => Flip completion event sent out one vblank too early. This behaviour has been observed during my testing with measurement hardware a couple of time. The commit message says that the extra flip event code was added to dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events in case the pflip irq doesn't fire, because the "DCH HUBP" component is clock gated and doesn't fire pflip irqs in that state. Also that this clock gating may happen if no planes are active. This suggests that the problem addressed by that commit can't happen if planes are active. The proposed solution is therefore to only execute the extra pflip completion code iff the count of active planes is zero and otherwise leave pflip completion handling to the pflip irq handler, for a more race-free experience. Note that i don't know if this fixes the problem the original commit tried to address, as i don't know what the test scenario was. It does fix the observed too early pageflip events though and points out the problem introduced. Fixes: 16f17eda ("drm/amd/display: Send vblank and user events at vsartup for DCN") Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
-
Yassine Oudjana authored
Works stable without the overrides. Signed-off-by:
Yassine Oudjana <y.oudjana@protonmail.com> Signed-off-by:
-
Zhigang Luo authored
This reverts commit 29e2501f. Signed-off-by:
Zhigang Luo <zhigang.luo@amd.com> Signed-off-by:
-
- 20 Mar, 2020 4 commits
-
-
shaoyunl authored
RLCG is enabled by host driver, no need to enable it in guest for none-PSP load path Signed-off-by:
shaoyunl <shaoyun.liu@amd.com> Reviewed-by:
-
John Clements authored
MMHub EDC becomes dirty after BACO reset EDC registers should be cleared early on in reset phase Reviewed-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
https://github.com/ckhu-mediatek/linux.git-tagsDave Airlie authored
Mediatek DRM Next for Linux 5.7 This include MT8183 DPI support. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.freedesktop.org/patch/msgid/1584580683.29614.5.camel@mtksdaap41
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-next-5.7-2020-03-19: amdgpu: - SR-IOV fixes - RAS fixes - Fallthrough cleanups - Kconfig fix for ACP - Fix load balancing with VCN - DC fixes - GPU reset fixes - Various cleanups scheduler: - Revert job distribution optimization - Add a helper to pick the least loaded scheduler Signed-off-by:
-
- 19 Mar, 2020 25 commits
-
-
Colin Ian King authored
There are spelling mistakes in pr_err messages and a comment. Fix these. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Nathan Chancellor authored
clang warns: drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:6: warning: variable 'shadow' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (offset == grbm_cntl || offset == grbm_idx) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:757:6: note: uninitialized use occurs here if (shadow) { ^~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:2: note: remove the 'if' if its condition is always true if (offset == grbm_cntl || offset == grbm_idx) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:738:13: note: initialize the variable 'shadow' to silence this warning bool shadow; ^ = 0 1 warning generated. shadow is only assigned in one condition and used as the condition for another if statement; combine the two if statements and remove shadow to make the code cleaner and resolve this warning. Fixes: 2e0cc4d4 ("drm/amdgpu: revise RLCG access path") Link: https://github.com/ClangBuiltLinux/linux/issues/936Suggested-by:Joe Perches <joe@perches.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
James Zhu authored
fix typo for vcn2.5/jpeg2.5 idle check Signed-off-by:
James Zhu <James.Zhu@amd.com> Reviewed-by:
Leo Liu <leo.liu@amd.com> Signed-off-by:
-
James Zhu authored
fix typo for vcn2/jpeg2 idle check Signed-off-by:
-
James Zhu authored
fix typo for vcn1 idle check Signed-off-by:
-
Zhigang Luo authored
The CAP fw is for enabling driver compatibility. Currently, it only enabled for vega10 VF. Signed-off-by:
-
John Clements authored
issue smu cmd to disable all features upon baco entry for arcturus to mitigate potential dirty I2C controller on boot Reviewed-by:
-
Yintian Tao authored
Originally, only the PTE valid is taken in consider. The PRT case is missied when bo update which raise problem. We need add condition for PRT case. v2: add PRT condition for amdgpu_vm_bo_update_mapping, too v3: fix one typo error Signed-off-by:
-
Dmytro Laktyushkin authored
Adds logic that will determine if pipes need merging during validation. Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Chris Park <Chris.Park@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
-
Wyatt Wood authored
[Why] The scratch space can be used to pass data between x86 and DMCUB. DMCUB will manage the actually mapping of CW7 internally, driver does not program the window. [How] Allocate extra space within the DMUB service's framebuffer for this scratch space and expose them from the service for use in DC. Signed-off-by:
Wyatt Wood <wyatt.wood@amd.com> Reviewed-by:
-
Yongqiang Sun authored
[Why] before update dpp DTO, we check dppclks in context to determine it is changed or not, but dppclks in context will be updated anyways after flip is done, so compare dppclks in context will always get an equal result. [How] Add pipe dpp clks in dccg and compare values between dccg and context. Signed-off-by:
Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by:
-
Nikola Cornij authored
[why] Causes regression with MST DSC displays not lighting up after DPMS [how] Revert commit 8cc426d7 ("drm/amd/display: Program DSC during timing programming") Signed-off-by:
Nikola Cornij <nikola.cornij@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Yongqiang Sun authored
[Why] underflow happened when playing video on 1366x768 + 4K clone mode due to incorrect handle watermark change flag and lower down clocks to early. [How] Check watermark change flag when decide doing optimized, and check optimized required flag to do clock update. Signed-off-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
-
Charlene Liu authored
[why] this register not exist in some asic, based on request remove this from dc. [how] add guard for sanization. Signed-off-by:
Charlene Liu <Charlene.Liu@amd.com> Reviewed-by:
-
Martin Tsai authored
[Why] We should check MST BU support capability on output port before building vsc info packet. [How] Add a new definition for port and sink capability check. Signed-off-by:
Martin Tsai <martin.tsai@amd.com> Reviewed-by:
Wenjing Liu <Wenjing.Liu@amd.com> Acked-by:
-
Sung Lee authored
[WHY] In headless boot cases, self refresh control registers are not programmed on boot. In certain hybrid graphics cases this may cause cstate entering to get blocked causing a hang. [HOW] Program self refresh control register on boot. Signed-off-by:
Sung Lee <sung.lee@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Wenjing Liu authored
[why] DP doesn't have message id as the first byte of an hdcp message, current hdcp psp unifies HDMI and DP message so that it is required when reading DP HDCP messages in hdcp_ddc, a message id needs to be added as the first byte of the HDCP message. The id is currently assigned as a magic number which is not a good coding practice. [how] Replace magic numbers with macro defined in hdcp headers. Signed-off-by:
Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by:
-
Wyatt Wood authored
[Why] We want to be able to enable/disable psr on dmcub and fallback to dmcu when necessary. [How] Use dc config option to do so. Signed-off-by:
-
Wyatt Wood authored
[Why] The default value for disable_dmcu is true, even for asics that require dmcu. [How] Set flag properly per asic. Signed-off-by:
-
Roman Li authored
[Why] The PSR enablement was dependent on swizzle as a workaround for non-pageflipping fb console. It's no longer required. [How] Remove PSR-enable dependency on swizzle mode. Signed-off-by:
Roman Li <roman.li@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] This is enabled by default on Renoir but there's userspace/API support to actually make use of this. Since we're not passing this down through surface updates, let's explicitly disable this for now. This fixes "dcn20_program_front_end_for_ctx" warnings associated with incorrect/unexpected programming sequences performed while this is enabled. [How] Disable it at the topmost level in DM in case anyone tries to flip this to enabled for any of the other ASICs like Navi10/14. Signed-off-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] A "dcn20_program_front_end_for_ctx" warning is observed on Renoir. Since the resource definition doesn't explicitly disable triplebuffer flips like Navi10 DC actually attempts to go and setup triplebuffering even when we pass in false to the plane state. If we hit a full update after triplebuffering has been setup we see the assertion since we don't expect full updates while performing triplebuffer flips. Normally this would get reset back to false whne we pass in the new plane state, but since we never actually copy the flag when doing surface updates this doesn't happen. [How] Copy the flag onto the plane update based on the requested surface update state. Signed-off-by:
-
Dmytro Laktyushkin authored
Right now only stream count is used to avoid split. This change updates the W/A to check plane count instead. Signed-off-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Acked-by:
-
Yongqiang Sun authored
[Why] When hotplug a HDMI monitor during entering S0i3 or DPMSOFF state due to entering infinite loop when calling vbios to program pixel clocks. In this scenario, pll is enabled but phy is not, and there is not a programing guide for this case. [How] Before we having the proper programing guide, before disable pll, doing a phy enable and disable to avoid the issue. Signed-off-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Isabel Zhang authored
[Why] Due to previous code changes displays which are in active state immediately transition to the active and added state. This makes the two states redundant and unnecessary. [How] Instead of updating the device state to active and added after successful addition, change state to inactive if addition failed. Also, change references to active and added state to just added state. Signed-off-by:
Isabel Zhang <isabel.zhang@amd.com> Reviewed-by:
-
