- 02 Aug, 2019 40 commits
-
-
John Clements authored
Removed loading duplicate instances of SDMA FW for Arcturus. We use a single image for all instances. Signed-off-by:
John Clements <john.clements@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
John Clements authored
Arcturus has 8 instances of SDMA. Update host to PSP interface to handle it. Signed-off-by:
-
John Clements authored
We don't need to handle it like other asics. Signed-off-by:
-
John Clements authored
Print the response in hex with the apprpriate mask. Signed-off-by:
-
John Clements authored
Add support for the arcturus specific psp metadata to the amdgpu firmware and properly parse it when loading it. Signed-off-by:
-
John Clements authored
Add arcturus cases to psp init sewquence. Signed-off-by:
-
John Clements authored
Remove duplicate break. Signed-off-by:
-
Evan Quan authored
vcn dpm on is a prerequisite for vcn power gate control. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
-
Evan Quan authored
Hook up the SW SMU power profile switch in KFD routine. Signed-off-by:
Kevin Wang <kevin1.wang@amd.com> Signed-off-by:
-
Evan Quan authored
Enable arcturus power profile retrieval and setting. Signed-off-by:
-
Evan Quan authored
This can prevent CPU to use the out-dated copy. Signed-off-by:
-
Tao Zhou authored
ce can also trigger interrupt, and even both ce and ue error can be found in one ras query, distinguishing between ce and ue in interrupt handler is uncessary. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Suggested-by:
Guchun Chen <guchun.chen@amd.com> Reviewed-by:
-
Tao Zhou authored
we only read error information for correctable error in interrupt handler, gpu reset is unnecessary since there is no data lost in correctable error Signed-off-by:
-
Tao Zhou authored
the initial value of ecc error count can be adjusted Signed-off-by:
-
Tao Zhou authored
enable umc ce interrupt and initialize ecc error count Signed-off-by:
-
Tao Zhou authored
correctable error can also trigger interrupt in some ras blocks Signed-off-by:
-
Tao Zhou authored
umc error address query can get ce/ue error address and clear error status Signed-off-by:
-
Tao Zhou authored
use umc_for_each_channel to make code simpler Signed-off-by:
-
Tao Zhou authored
common function for all umc versions, loop for each umc channel is a frequent used operation in umc block, define it as a macro to simplify code Signed-off-by:
-
Tao Zhou authored
add initialization for new members of amdgpu_umc structure Signed-off-by:
-
Tao Zhou authored
expose more parameters and functions of specific umc version to common umc layer, so amdgpu_umc layer and other blocks could access them Signed-off-by:
-
Tao Zhou authored
clearing MCA_STATUS is enough to reset the whole MCA, writing zero to MCA_ADDR is unnecessary Signed-off-by:
-
Kevin Wang authored
too frequently to update mertrics table will cause smu internal error. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] DRM private objects have no hw_done/flip_done fencing mechanism on their own and cannot be used to sequence commits accordingly. When issuing commits that don't touch the same set of hardware resources like page-flips on different CRTCs we can run into the issue below because of this: 1. Client requests non-blocking Commit #1, has a new dc_state #1, state is swapped, commit tail is deferred to work queue 2. Client requests non-blocking Commit #2, has a new dc_state #2, state is swapped, commit tail is deferred to work queue 3. Commit #2 work starts, commit tail finishes, atomic state is cleared, dc_state #1 is freed 4. Commit #1 work starts, commit tail encounters null pointer deref on dc_state #1 In order to change the DC state as in the private object we need to ensure that we wait for all outstanding commits to finish and that any other pending commits must wait for the current one to finish as well. We do this for MEDIUM and FULL updates. But not for FAST updates, nor would we want to since it would cause stuttering from the delays. FAST updates that go through dm_determine_update_type_for_commit always create a new dc_state and lock the DRM private object if there are any changed planes. We need the old state to validate, but we don't actually need the new state here. [How] If the commit isn't a full update then the use after free can be resolved by simply discarding the new state entirely and retaining the existing one instead. With this change the sequence above can be reexamined. Commit #2 will still free Commit #1's reference, but before this happens we actually added an additional reference as part of Commit #2. If an update comes in during this that needs to change the dc_state it will need to wait on Commit #1 and Commit #2 to finish. Then it'll swap the state, finish the work in commit tail and drop the last reference on Commit #2's dc_state. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204181 Fixes: 004b3938 ("drm/amd/display: Check scaling info when determing update type") Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by:
David Francis <david.francis@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] By passing through the dm_determine_update_type_for_commit for atomic commits that can be done asynchronously we are incurring a performance penalty by locking access to the global private object and holding that access until the end of the programming sequence. This is also allocating a new large dc_state on every access in addition to retaining all the references on each stream and plane until the end of the programming sequence. [How] Shift the determination for async update before validation. Return early if it's going to be an async update. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] We previously allowed framebuffer swaps as async updates for cursor planes but had to disable them due to a bug in DRM with async update handling and incorrect ref counting. The check to block framebuffer swaps has been added to DRM for a while now, so this check is redundant. The real fix that allows this to properly in DRM has also finally been merged and is getting backported into stable branches, so dropping this now seems to be the right time to do so. [How] Drop the redundant check for old_fb != new_fb. With the proper fix in DRM, this should also fix some cursor stuttering issues with xf86-video-amdgpu since it double buffers the cursor. IGT tests that swap framebuffers (-varying-size for example) should also pass again. Signed-off-by:
-
Colin Ian King authored
Currenly the error check on variable instance is always false because it is a uint32_t type and this is never less than zero. Fix this by making it an int type. Addresses-Coverity: ("Unsigned compared against 0") Fixes: 7d0e6329 ("drm/amdgpu: update more sdma instances irq support") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Matt Coffin authored
[Why] Before this change, the fan control state on smu_v11 was not able to be changed because the capability check for checking if the fan control capability existed was inverted. [How] The capability check for fan control in smu_v11_0_auto_fan_control was inverted, to correctly check for the absence, instead of presence of fan control capabilities. Reviewed-by:
Matt Coffin <mcoffin13@gmail.com> Signed-off-by:
-
Colin Ian King authored
There are a few spelling mistakes "unknow" -> "unknown" and "enabeld" -> "enabled". Fix these. Signed-off-by:
-
Jia-Ju Bai authored
In radeon_connector_set_property(), there is an if statement on line 743 to check whether connector->encoder is NULL: if (connector->encoder) When connector->encoder is NULL, it is used on line 755: if (connector->encoder->crtc) Thus, a possible null-pointer dereference may occur. To fix this bug, connector->encoder is checked before being used. This bug is found by a static analysis tool STCheck written by us. Signed-off-by:Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
-
Colin Ian King authored
There are two occurrances of off-by-one upper bound checking of indexes causing potential out-of-bounds array reads. Fix these. Addresses-Coverity: ("Out-of-bounds read") Fixes: cb33363d ("drm/amd/powerplay: add smu feature name support") Fixes: 6b294793 ("drm/amd/powerplay: add smu message name support") Signed-off-by: -
KyleMahlkuch authored
During kexec some adapters hit an EEH since they are not properly shut down in the radeon_pci_shutdown() function. Adding radeon_suspend_kms() fixes this issue. Signed-off-by:
KyleMahlkuch <kmahlkuc@linux.vnet.ibm.com> Signed-off-by:
-
Jay Cornwall authored
Following bitmap layout logic introduced by: "drm/amdgpu: support get_cu_info for Arcturus". v2: squash in fixup for gfx_v9_0.c (Alex) v3: squash in debug print output fix Signed-off-by:
Jay Cornwall <Jay.Cornwall@amd.com> Signed-off-by:
-
Le Ma authored
This change is because SE/SH layout on Arcturus is 8*1, different from 4*2(or 4*1) on Vega ASICs. Currently the cu bitmap array is 4x4 size, and besides the bitmap is used widely across SW stack. To mostly reduce the scale of impact, we make the cu bitmap array compatible with SE/SH layout on Arcturus. Then the store of cu bits of each shader array for Arcturus will be like below: SE0,SH0 --> bitmap[0][0] SE1,SH0 --> bitmap[1][0] SE2,SH0 --> bitmap[2][0] SE3,SH0 --> bitmap[3][0] SE4,SH0 --> bitmap[0][1] SE5,SH0 --> bitmap[1][1] SE6,SH0 --> bitmap[2][1] SE7,SH0 --> bitmap[3][1] Signed-off-by:Le Ma <le.ma@amd.com> Reviewed-by:
-
Kent Russell authored
The registers used for VG20 are different in that certain performance counters were split off to TXCLK3/4. Vega10/12 doesn't have this, so add a new vg20_get_pcie_usage to reflect this change. Signed-off-by:
Kent Russell <kent.russell@amd.com> Reviewed-by:
-
Kent Russell authored
These are added for VG20, and are needed for PCIe bandwidth. Signed-off-by:
-
Andrey Grodzovsky authored
Fixes GPU reset crash. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
-
Felix Kuehling authored
Memory used by KFD applications can contain sensitive information that should not be leaked to other processes. The current approach to prevent leaks is to clear VRAM at allocation time. This is not effective because memory can be reused in other ways without being cleared. Synchronously clearing memory on the allocation path also carries a significant performance penalty. Stop clearing memory at allocation time. Instead mark the memory for wipe on release. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Felix Kuehling authored
Wipe VRAM memory containing sensitive data when moving or releasing BOs. Clearing the memory is pipelined to minimize any impact on subsequent memory allocation latency. Use of a poison value should help debug future use-after-free bugs. When moving BOs, the existing ttm_bo_pipelined_move ensures that the memory won't be reused before being wiped. When releasing BOs, the BO is fenced with the memory fill operation, which results in queuing the BO for a delayed delete. v2: Move amdgpu_amdkfd_unreserve_memory_limit into amdgpu_bo_release_notify so that KFD can use memory that's still being cleared in the background Signed-off-by:
-
Felix Kuehling authored
This memory allocation flag will be used to indicate BOs containing sensitive data that should not be leaked to other processes. Signed-off-by:
-
