- 28 May, 2019 4 commits
-
-
Oak Zeng authored
Add amdgpu_amdkfd interface to alloc and free gws from amdgpu Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Oak Zeng authored
Add amdgpu_amdkfd interface to get num_gws and add num_gws to /sys/class/kfd/kfd/topology/nodes/x/properties. Only report num_gws if MEC FW support GWS barriers. Currently it is determined by a module parameter which will be replaced with MEC FW version check when firmware is ready. Signed-off-by:
-
Oak Zeng authored
TTM doesn't support CPU mapping of sg type bo (under which mmio bo is created). Switch mmaping of mmio page to kfd device file. Signed-off-by:
Christian Konig <christian.koenig@amd.com> Reviewed-by:
-
Emily Deng authored
dc_destroy should be called amdgpu_cgs_destroy_device, as it will use cgs context to read or write registers. Signed-off-by:
Emily Deng <Emily.Deng@amd.com> Acked-by:
-
- 24 May, 2019 36 commits
-
-
Tom St Denis authored
Acked-by:
Slava Abramov <slava.abramov@amd.com> Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
-
Tom St Denis authored
Acked-by:
-
Yogesh Mohan Marimuthu authored
[Why] There are monitors which can have more than one preferred mode set. There are chances in these monitors that if common modes are added in function amdgpu_dm_connector_add_common_modes(), these common modes can be calculated with different preferred mode than the one used in function decide_crtc_timing_for_drm_display_mode(). The preferred mode can be different because after common modes are added, the mode list is sorted and this changes the order of preferred modes in the list. The first mode in the list with preferred flag set is selected as preferred mode. Due to this the preferred mode selected varies. If same preferred mode is not selected in common mode calculation and crtc timing, then during mode set instead of setting preferred timing, common mode timing will be applied which can cause "out of range" message in the monitor with monitor blanking out. [How] Sort the modes before adding common modes. The same sorting function is called during common mode addition and deciding crtc timing. Signed-off-by:
Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] The current state on the connector is queried when getting the max bpc rather than the new state. This means that a new max bpc value can only currently take effect on the commit *after* it changes. The new state should be passed in instead. [How] Pass down the dm_state as drm state to where we do color depth lookup. The passed in state can still be NULL when called from amdgpu_dm_connector_mode_valid, so make sure that we have reasonable defaults in place. That should probably be addressed at some point. This change now (correctly) causes a modeset to occur when changing the max bpc for a connector. v2: Drop extra TODO. Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] The custom "max bpc" property was added to limit color depth while the DRM one was still being merged. It's been a few kernel versions since then and this TODO was still sticking around. [How] Attach the DRM max bpc property to the connector and drop all of our custom property management. Set the max bpc to 8 by default since DRM defaults to the max in the range which would be 16 in this case. No behavioral changes are intended with this patch, it should just be a refactor. v2: Don't force 8bpc when no state is given Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Chengming Gui authored
Fix code error to support value < 0 or > 1. Signed-off-by:
Chengming Gui <Jack.Gui@amd.com> Reviewed-by:
Hawking Zhang <hawking.zhang@amd.com> Signed-off-by:
-
Kent Russell authored
Add a file that provides a Unique ID for the GPU. This will persist across machines and is guaranteed to be unique. This is only available for GFX9 and newer, so older ASICs will not have this file in the sysfs pool v2: Store it in adev for ASICs that don't have a hwmgr Reviewed-by:
Kent Russell <kent.russell@amd.com> Signed-off-by:
-
Amber Lin authored
A multi-socket server can have multiple PCIe segments so BFD is not enough to distingush each GPU. Also add domain number into account when generating gpu_id. Signed-off-by:
Amber Lin <Amber.Lin@amd.com> Reviewed-by:
-
Kent Russell authored
Add the VegaM information to KFD Signed-off-by:
-
Felix Kuehling authored
Fix a circular lock dependency exposed under userptr memory pressure. The DQM lock is the only one taken inside the MMU notifier. We need to make sure that no reclaim is done under this lock, and that no other locks are taken under which reclaim is possible. Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Signed-off-by:
-
Oak Zeng authored
Alloc format was never really supported by MEC FW. FW always does one per pipe allocation. Signed-off-by:
-
Oak Zeng authored
Expose available numbers of both SDMA queue types in the topology. Signed-off-by:
-
Oak Zeng authored
Existing QUEUE_TYPE_SDMA means PCIe optimized SDMA queues. Introduce a new QUEUE_TYPE_SDMA_XGMI, which is optimized for non-PCIe transfer such as XGMI. Signed-off-by:
-
Oak Zeng authored
Previous codes assumes there are two sdma engines. This is not true e.g., Raven only has 1 SDMA engine. Fix the issue by using sdma engine number info in device_info. Signed-off-by:
-
Yong Zhao authored
This avoids duplicated code. Signed-off-by:
Yong Zhao <Yong.Zhao@amd.com> Reviewed-by:
-
Oak Zeng authored
Instead of allocat hiq and sdma mqd from sub-allocator, allocate them from a mqd trunk pool. This is done for all asics Signed-off-by:
Oak Zeng <ozeng@amd.com> Reviewed-by:
-
Oak Zeng authored
This is preparation work to introduce more mqd allocation scheme Signed-off-by:
-
Oak Zeng authored
Free mqd_mem_obj it GTT buffer allocation for MQD+control stack fails. Signed-off-by:
-
Oak Zeng authored
MEC FW for some new asic requires all SDMA MQDs to be in a continuous trunk of memory right after HIQ MQD. Add a field in device queue manager to hold the HIQ/SDMA MQD memory object and allocate MQD trunk on device queue manager initialization. Signed-off-by:
-
Oak Zeng authored
Also initialize mqd size on mqd manager initialization Signed-off-by:
-
Oak Zeng authored
Previously mqd managers was initialized on demand. As there are only a few type of mqd managers, the on demand initialization doesn't save too much memory. Initialize them on device queue initialization instead and delete the get_mqd_manager interface. This makes codes more organized for future changes. Signed-off-by:
-
Oak Zeng authored
With introduction of new mqd allocation scheme for HIQ, DIQ and HIQ use different mqd allocation scheme, DIQ can't reuse HIQ mqd manager Signed-off-by:
-
Oak Zeng authored
Global function mqd_manager_init just calls asic-specific functions and it is not necessary. Delete it and introduce a mqd_manager_init interface in dqm for asic-specific mqd manager init. Call mqd_manager_init interface directly to initialize mqd manager Signed-off-by:
-
Felix Kuehling authored
Use unsigned long for number of pages. Check that pfns are valid after hmm_vma_fault. If they are not, return an error instead of continuing with invalid page pointers and PTEs. Signed-off-by:
-
Philip Yang authored
If using old kernel config file, CONFIG_ZONE_DEVICE is not selected, so CONFIG_HMM and CONFIG_HMM_MIRROR is not enabled, the current driver error message "Failed to register MMU notifier" is not clear. Inform user with more descriptive message on how to fix the missing kernel config option. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109808Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Philip Yang authored
userptr may cross two VMAs if the forked child process (not call exec after fork) malloc buffer, then free it, and then malloc larger size buf, kerenl will create new VMA adjacent to old VMA which was cloned from parent process, some pages of userptr are in the first VMA, the rest pages are in the second VMA. HMM expects range only have one VMA, loop over all VMAs in the address range, create multiple ranges to handle this case. See is_mergeable_anon_vma in mm/mmap.c for details. Signed-off-by:
-
Philip Yang authored
Userptr restore may have concurrent userptr invalidation after hmm_vma_fault adds the range to the hmm->ranges list, needs call hmm_vma_range_done to remove the range from hmm->ranges list first, then reschedule the restore worker. Otherwise hmm_vma_fault will add same range to the list, this will cause loop in the list because range->next point to range itself. Add function untrack_invalid_user_pages to reduce code duplication. Signed-off-by:
-
Philip Yang authored
Only select HMM_MIRROR will get kernel config dependency warnings if CONFIG_HMM is missing in the config. Add depends on HMM will solve the issue. Add conditional compilation to fix compilation errors if HMM_MIRROR is not enabled as HMM config is not enabled. Remove unused function amdgpu_ttm_tt_mark_user_pages. Signed-off-by:
-
Philip Yang authored
Use HMM helper function hmm_vma_fault() to get physical pages backing userptr and start CPU page table update track of those pages. Then use hmm_vma_range_done() to check if those pages are updated before amdgpu_cs_submit for gfx or before user queues are resumed for kfd. If userptr pages are updated, for gfx, amdgpu_cs_ioctl will restart from scratch, for kfd, restore worker is rescheduled to retry. HMM simplify the CPU page table concurrent update check, so remove guptasklock, mmu_invalidations, last_set_pages fields from amdgpu_ttm_tt struct. HMM does not pin the page (increase page ref count), so remove related operations like release_pages(), put_page(), mark_page_dirty(). Signed-off-by:
-
Philip Yang authored
There is circular lock between gfx and kfd path with HMM change: lock(dqm) -> bo::reserve -> amdgpu_mn_lock To avoid this, move init/unint_mqd() out of lock(dqm), to remove nested locking between mmap_sem and bo::reserve. The locking order is: bo::reserve -> amdgpu_mn_lock(p->mn) Signed-off-by:
-
Philip Yang authored
Replace our MMU notifier with hmm_mirror_ops.sync_cpu_device_pagetables callback. Enable CONFIG_HMM and CONFIG_HMM_MIRROR as a dependency in DRM_AMDGPU_USERPTR Kconfig. It supports both KFD userptr and gfx userptr paths. Signed-off-by:
-
shaoyunl authored
There is a bug found in vml2 xgmi logic: mtype is always sent as NC on the VMC to TC interface for a page walk, regardless of whether the request is being sent to local or remote GPU. NC means non-coherent and will cause the VMC return data to be cached in the TCC (versus UC – uncached will not cache the data). Since the page table updates are being done by SDMA/HDP, then TCC will never be updated and the GC VML2 will continue to hit on the TCC and never get the updated page tables and result in a fault. Heave weigh tlb invalidation does a WB/INVAL of the L1/L2 GL data caches so TCC will not be hit on next request Signed-off-by:
shaoyunl <Shaoyun.Liu@amd.com> Reviewed-by:
-
Jay Cornwall authored
ttmp[4:5] is initialized by the SPI with SPI_GDBG_TRAP_DATA* values. These values are more useful to the debugger than ttmp[14:15], which carries dispatch_scratch_base*. There are too few registers to preserve both. Signed-off-by:
Jay Cornwall <Jay.Cornwall@amd.com> Reviewed-by:
-
Jay Cornwall authored
SQ_WAVE_IB_STS.RCNT grew from 4 bits to 5 in gfx9. Do not truncate when saving in the high bits of TTMP1. Signed-off-by:
-
Jay Cornwall authored
If instruction fetch fails the wave cannot be halted and returned to the shader without raising MEM_VIOL again. Currently the wave is terminated if this occurs, but this loses information about the cause of the fault. The debugger would prefer the faulting wave state to be context-saved. Poll inside the trap handler until TRAPSTS.SAVECTX indicates context save is ready. Exit the poll loop and complete the remainder of the exception handler, then return to the shader. The next instruction fetch will be from the trap handler and not the faulting PC. Context save will then deschedule the wave and save its state. Signed-off-by:
-
Jay Cornwall authored
When MEM_VIOL is asserted the context save handler rewinds the program counter. This is incorrect for any source of the exception. MEM_VIOL may be raised in normal operation by out-of-bounds access to LDS or GDS and does not require special handling. Remove PC adjustment when MEM_VIOL has been raised. Signed-off-by:
-
