- 29 Aug, 2018 3 commits
-
-
Christian König authored
Not used any more. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Oak Zeng authored
For compute vm acquired from amdgpu, vm.pasid is managed by kfd. Decouple pasid from such vm on process destroy to avoid duplicate pasid release. Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
-
Oak Zeng authored
To make a amdgpu vm to a compute vm, the old pasid will be freed and replaced with a pasid managed by kfd. Kfd can't reuse original pasid allocated by amdgpu because kfd uses different pasid policy with amdgpu. For example, all graphic devices share one same pasid in a process. v2: rebase (Alex) Signed-off-by:
-
- 28 Aug, 2018 7 commits
-
-
Michel Dänzer authored
Doing it earlier hits a WARN_ON_ONCE in amdgpu_bo_gpu_offset. Fixes: "drm/amdgpu: remove gart.table_addr" Reviewed-by:
-
Emily Deng authored
Fix the VMC page fault when the running sequence is as below: 1.amdgpu_gem_create_ioctl 2.ttm_bo_swapout->amdgpu_vm_bo_invalidate, as not called amdgpu_vm_bo_base_init, so won't called list_add_tail(&base->bo_list, &bo->va). Even the bo was evicted, it won't set the bo_base->moved. 3.drm_gem_open_ioctl->amdgpu_vm_bo_base_init, here only called list_move_tail(&base->vm_status, &vm->evicted), but not set the bo_base->moved. 4.amdgpu_vm_bo_map->amdgpu_vm_bo_insert_map, as the bo_base->moved is not set true, the function amdgpu_vm_bo_insert_map will call list_move(&bo_va->base.vm_status, &vm->moved) 5.amdgpu_cs_ioctl won't validate the swapout bo, as it is only in the moved list, not in the evict list. So VMC page fault occurs. Signed-off-by:
Emily Deng <Emily.Deng@amd.com> Reviewed-by:
-
Yintian Tao authored
It will be more safe to make full-acess include both phase1 and phase2. Then accessing special registeris wherever at phase1 or phase2 will not block any shutdown and suspend process under virtualization. Signed-off-by:
Yintian Tao <yttao@amd.com> Acked-by:
-
Christian König authored
Looks like a copy&paste error to me. Signed-off-by:
Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by:
-
Amber Lin authored
After merging KFD into amdgpu, move module parameters defined in KFD to amdgpu_drv.c, where other module parameters are declared. v2: add kernel-doc comments v3: rebase and fix parameter variable name (Alex) Signed-off-by:
Amber Lin <Amber.Lin@amd.com> Reviewed-by:
-
Amber Lin authored
After amdkfd is merged to amdgpu, CONFIG_HSA_AMD_MODULE no longer exists. Signed-off-by:
-
Amber Lin authored
Since KFD is only supported by single GPU driver, it makes sense to merge amdgpu and amdkfd into one module. This patch is the initial step: merge Kconfig and Makefile. v2: also remove kfd from drm Kconfig Signed-off-by:
-
- 27 Aug, 2018 30 commits
-
-
Andrey Grodzovsky authored
The fault reports the page number where the fault happend and not the exact faulty address. Update the print message to reflect that. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Signed-off-by:
-
David Francis authored
[Why] The dce_i2c_hw code contained four funtcions that were only called in one place and did not have a clearly delineated purpose. [How] Inline these functions, keeping the same functionality. This is not a functional change. The functions disable_i2c_hw_engine and release_engine_dce_hw were pulled into their respective callers. The most interesting part of this change is the acquire functions. dce_i2c_hw_engine_acquire_engine was pulled into dce_i2c_engine_acquire_hw, and dce_i2c_engine_acquire_hw was pulled into acquire_i2c_hw_engine. Some notes to show that this change is not functional: -Failure conditions in any function resulted in a cascade of calls that ended in a 'return NULL'. Those are replaced with a direct 'return NULL'. -The variable result is the one from dce_i2c_hw_engine_acquire_engine. The boolean result used as part of return logic was removed. -As the second half of dce_i2c_hw_engine_acquire_engine is only executed if that function is returning true and therefore exiting the do-while loop in dce_i2c_engine_acquire_hw, those lines were moved outside of the loop. Signed-off-by:
David Francis <David.Francis@amd.com> Acked-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
-
Eric Yang authored
[Why] On PCO and up, whenever SMU receive message to indicate active display count = 0. SMU will turn off 48MHZ TMDP reference clock by writing to 1 TMDP_48M_Refclk_Driver_PWDN. Once this clock is off, no PHY register will respond to register access. This means our current sequence of notifying display count along with requesting clock will cause driver to hang when accessing PHY registers after displays count goes to 0. [How] Separate the PPSMC_MSG_SetDisplayCount message from the SMU messages that request clocks, have display own sequencing of this message so that we can send it at the appropriate time. Do not redundantly power off HW when entering S3, S4, since display should already be called to disable all streams. And ASIC soon be powered down. Signed-off-by:
Eric Yang <Eric.Yang2@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
David Francis authored
[Why] The i2c code contains two structs that contain the same information as i2c_payload [How] Replace references to those structs with references to i2c_payload dce_i2c_transaction_request->status was written to but never read, so all references to it are removed Signed-off-by:
Jordan Lazare <Jordan.Lazare@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] Logging hardware state can be done by triggering a write to the debugfs file. It would also be useful to be able to read the hardware state from the debugfs file to be able to generate a clean log without timestamps. [How] Usage: cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log Threading is an obvious concern when dealing with multiple debugfs operations and blocking on global state in dm or dc seems unfavorable. Adding an extra parameter for the debugfs log context state is the implementation done here. Existing code that made use of DTN_INFO and its associated macros needed to be refactored to support this. We don't know the size of the log in advance so it reallocates the log string dynamically. Once the log has been generated it's copied into the user supplied buffer for the debugfs. This allows for seeking support but it's worth nothing that unlike triggering output via dmesg the hardware state might change in-between reads if your buffer size is too small. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
-
David Francis authored
[Why] Good spelling and grammar makes comments more pleasant and clearer. Linux has coding standards for comments that we should try to follow. [How] Fix obvious spelling and grammar issues Ensure all comments use '/*' and '*/' and multi-line comments follow linux convention Remove line-of-stars comments that do not separate sections of code and comments referring to lines of code that have since been removed Signed-off-by:
-
SivapiriyanKumarasamy authored
[Why] There is currently an intermittent hang from a memory leak in DTN stress testing. It is caused by unfreed memory during driver disable. [How] Do a dc_sink_release in the case that skips it incorrectly. Signed-off-by:
SivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Ken Chalmers authored
[Why] Now that we "scale" time delays correctly on Maximus (as of diags svn r170115), the forced "35 ms" wait time now becomes 35 ms * 500 = 17.5 seconds, which is far too long. Even having to repeat polling a register once causes excessive delays on Maximus. [How] Just use the regular wait time passed to the generic_reg_wait() function. This is sufficient for Maximus now, and it also means that there's one less "Maximus-only" code path in DAL. Also disable the "REG_WAIT taking a while:" message on Maximus, since things do take a while longer there and 1-2ms delays are not uncommon (and nothing to worry about). Signed-off-by:
Ken Chalmers <ken.chalmers@amd.com> Reviewed-by:
Eric Bernstein <Eric.Bernstein@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] We have logging methods for printing hardware state for newer ASICs but no way to trigger the log output. [How] Add support for triggering the output via writing to a debugfs file entry. Log output currently goes into dmesg for convenience, but accessing via a read should be possible later. Signed-off-by:
-
Leo (Sunpeng) Li authored
[Why] drm_handle_vblank is deprecated. Use drm_crtc_handle_vblank instead. Signed-off-by:
-
Tony Cheng authored
Signed-off-by:
Steven Chiu <Steven.Chiu@amd.com> Acked-by:
-
David Francis authored
[Why] The function pointers of the dce_i2c_hw struct were never accessed from outside dce_i2c_hw.c and had only one version. As function pointers take up space and make debugging difficult, and they are not needed in this case, they should be removed. [How] Remove the dce_i2c_hw_funcs struct and make static all functions that were previously a part of it. Reorder the functions in dce_i2c_hw.c. Signed-off-by:
-
Christian König authored
Should work on Vega10 as well, but with an obvious performance hit. Older APUs can be enabled as well, but will probably be more work. v2: fix error checking v3: use more general check Signed-off-by:
-
Christian König authored
Helper to get the PDE for a PD/PT. v2: improve documentation Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
-
Christian König authored
Add the necessary handling. Signed-off-by:
-
Christian König authored
Add a helper function to figure them out only once. v2: fix typo with memset v3: rebase on kfd changes (Alex) Signed-off-by:
-
Christian König authored
Just another leftover from radeon. Signed-off-by:
-
Christian König authored
We can't hold the mn_lock while allocating memory. Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Christian König authored
No more waiting for a fence done here. Signed-off-by:
-
Rex Zhu authored
1. initialize kiq before initialize gfx ring. 2. set kiq ring ready immediately when kiq initialize successfully. 3. split function gfx_v9_0_kiq_resume into two functions. gfx_v9_0_kiq_resume is for kiq initialize. gfx_v9_0_kcq_resume is for kcq initialize. Reviewed-by:Rex Zhu <Rex.Zhu@amd.com> Signed-off-by:
-
Rex Zhu authored
1. initialize kiq before initialize gfx ring. 2. set kiq ring ready immediately when kiq initialize successfully. 3. split function gfx_v8_0_kiq_resume into two functions. gfx_v8_0_kiq_resume is for kiq initialize. gfx_v8_0_kcq_resume is for kcq initialize. Reviewed-by:
-
Rex Zhu authored
Send all kcq unmap_queue packets and then wait for complete. Reviewed-by:
-
Rex Zhu authored
There are no any logical changes here. 1. if kcq can be enabled via kiq, we don't need to do kiq ring test. 2. amdgpu_ring_test_ring function can be used to sync the ring complete, remove the duplicate code. Reviewed-by:
-
Rex Zhu authored
Send all kcq unmap_queue packets and then wait for complete. Reviewed-by:
-
Rex Zhu authored
There are no any logical changes here. 1. if kcq can be enabled via kiq, we don't need to do kiq ring test. 2. amdgpu_ring_test_ring function can be used to sync the ring complete, remove the duplicate code. v2: alloc 6 (not 7) dws for unmap_queues Reviewed-by:
-
Rex Zhu authored
As we have unify powergate_uvd/vce/mmhub to set_powergating_by_smu, and set_powergating_by_smu was supported by both dpm and powerplay. so remove the else case. Reviewed-by:
-
Rex Zhu authored
when hw_fini/suspend, smu only need to power on uvd block if uvd pg is supported, don't need to call uvd to do hw_init. v2: fix typo in patch descriptions and comments. Reviewed-by:
-
Rex Zhu authored
For SI/Kv, the power state is managed by function amdgpu_pm_compute_clocks. when dpm enabled, we should call amdgpu_pm_compute_clocks to update current power state instand of set boot state. this change can fix the oops when kfd driver was enabled on Kv. Reviewed-by:
-
Rex Zhu authored
Forgot to add vce pg support via smu for Kaveri/Mullins. Fixes: 561a5c83eadd ("drm/amd/pp: Unify powergate_uvd/vce/mmhub to set_powergating_by_smu") v2: refine patch descriptions suggested by Michel Reviewed-by: -
Rex Zhu authored
when ac/dc switch, driver will be notified by acpi event. then the power source will be updated. so don't need to get power source when set power state. Reviewed-by:
-
