- 29 Aug, 2018 13 commits
-
-
Alex Deucher authored
This caused a confusing error message, but there is functionally no problem since the default method is DIRECT. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Amber Lin authored
Move some KFD-related (but used in amdgpu_drv.c) definitions from kfd_priv.h to kgd_kfd_interface.h so we don't need to include kfd_priv.h in amdgpu_drv.c. This fixes a build failure when AMDGPU is enabled but MMU_NOTIFIER is not. This patch also disables KFD-related module options when HSA_AMD is not enabled. v2: rebase (Alex) Signed-off-by:
Amber Lin <Amber.Lin@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Philip Yang authored
kvmalloc_array uses __GFP_ZERO flag ensures that the returned address is zeroed already, memset it to zero again afterwards is unnecessary, and in this case buggy because we only clear the first entry. Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Michel Dänzer authored
The first parameter of list_cut_position() must point to an initialized list. Noticed thanks to KASAN pointing out something's fishy here. Fixes: "drm/ttm: add bulk move function on LRU" Reviewed-by:
-
Christian König authored
Instead of the larger one use the smaller hole in the MC address space for the GART mappings. Signed-off-by:
Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by:
-
Michel Dänzer authored
This reverts commit 31625ccae4464b61ec8cdb9740df848bbc857a5b. It triggered various badness on my development machine when running the piglit gpu profile with radeonsi on Bonaire, looks like memory corruption due to insufficiently protected list manipulations. Signed-off-by:
-
Christian König authored
Most of the time we only need to know if the BO has a valid GMC addr. Signed-off-by:
-
Christian König authored
Further separate GART and GTT domain. Signed-off-by:
-
Christian König authored
Improve the VCE limitation handling. Signed-off-by:
-
Christian König authored
Move that into amdgpu_gmc.c since we are really deadling with GMC address space here. Signed-off-by:
-
Christian König authored
Not used any more. Signed-off-by:
-
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:
-
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 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 20 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:
-
