drm/amd/display: Fix two cursor duplication when using overlay
Our driver supports overlay planes, and as expected, some userspace
compositor takes advantage of these features. If the userspace is not
enabling the cursor, they can use multiple planes as they please.
Nevertheless, we start to have constraints when userspace tries to
enable hardware cursor with various planes. Basically, we cannot draw
the cursor at the same size and position on two separated pipes since it
uses extra bandwidth and DML only run with one cursor.
For those reasons, when we enable hardware cursor and multiple planes,
our driver should accept variations like the ones described below:
In this scenario, we can have the desktop UI in the overlay and some
other framebuffer attached to the primary plane (e.g., video). However,
userspace needs to obey some rules and avoid scenarios like the ones
described below (when enabling hw cursor):
If the userspace violates some of the above scenarios, our driver needs
to reject the commit; otherwise, we can have unexpected behavior. Since
we don't have a proper driver validation for the above case, we can see
some problems like a duplicate cursor in applications that use multiple
planes. This commit fixes the cursor issue and others by adding adequate
verification for multiple planes.
Change since V1 (Harry and Sean):
- Remove cursor verification from the equation.
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:
In function ‘dm_update_mst_vcpi_slots_for_dsc’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6242:46:
warning: variable ‘old_con_state’ set but not used
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:
In function ‘amdgpu_dm_commit_cursors’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7709:44:
warning: variable ‘new_plane_state’ set but not used
The variables were introduced to be used in iterators, but not used.
Use other iterators which don't require the unused variables.
Fixes: 8ad278062de4e ("drm/amd/display: Disable cursors before disabling planes") Fixes: 29b9ba74f6384 ("drm/amd/display: Recalculate VCPI slots for new DSC connectors") Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Alex Deucher [Fri, 23 Apr 2021 20:46:19 +0000 (16:46 -0400)]
drm/amdgpu/display: add documentation for dmcub_trace_event_en
Was missing when this structure was updated.
Fixes: 46a83eba276cd3 ("drm/amd/display: Add debugfs to control DMUB trace buffer events") Reviewed-by: Leo (Hanghong) Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Commit 4192f7b57689 ("drm/amdgpu: unmap register bar on device init
failure") makes amdgpu_driver_unload_kms() skips amdgpu_device_fini(),
so the VGA clients remain registered. So when
vga_arbiter_notify_clients() iterates over registered clients, it causes
NULL pointer dereference.
Since there's no reason to register VGA clients that early, so solve
the issue by putting them after all the goto cleanups.
v2:
- Remove redundant vga_switcheroo cleanup in failed: label.
Fixes: 4192f7b57689 ("drm/amdgpu: unmap register bar on device init failure") Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Dennis Li [Tue, 27 Apr 2021 14:21:03 +0000 (22:21 +0800)]
drm/amdgpu: fix no full coverage issue for gprs initialization
The wave's number per simd in aldebaran is changed to 8, so it is
impossible to use old algorithm to initiate all sgprs with one
threadgroup. The new algorithm firstly use three threadgroups to
initiate most sgprs simultaneously and then use another threadgroup with
4 waves to cover other uninitiated sgprs.
v2:
Add more description about the new algorithm to clear sgprs and add some
comment for shader binaries
Philip Yang [Tue, 20 Apr 2021 19:13:59 +0000 (15:13 -0400)]
drm/amdkfd: enable subsequent retry fault
After draining the stale retry fault, or failed to validate the range
to recover, have to remove the fault address from fault filter ring, to
be able to handle subsequent retry interrupt on same address. Otherwise
the retry fault will not be processed to recover until timeout passed.
Philip Yang [Tue, 20 Apr 2021 14:05:44 +0000 (10:05 -0400)]
drm/amdgpu: address remove from fault filter
Add interface to remove address from fault filter ring by resetting
fault ring entry key, then future vm fault on the address will be
processed to recover.
Define fault key as atomic64_t type to use atomic read/set/cmpxchg key
to protect fault ring access by interrupt handler and interrupt deferred
work for vg20. Change fault->timestamp to 48-bit to share same uint64_t
with 8-bit fault->next, it is enough for 48bit IH timestamp.
Philip Yang [Tue, 20 Apr 2021 01:19:57 +0000 (21:19 -0400)]
drm/amdkfd: handle stale retry fault
Retry fault interrupt maybe pending in IH ring after GPU page table
is updated to recover the vm fault, because each page of the range
generate retry fault interrupt. There is race if application unmap
range to remove and free the range first and then retry fault work
restore_pages handle the retry fault interrupt, because range can not be
found, this vm fault can not be recovered and report incorrect GPU vm
fault to application.
Before unmap to remove and free range, drain retry fault interrupt
from IH ring1 to ensure no retry fault comes after the range is removed.
Drain retry fault interrupt skip the range which is on deferred list
to remove, or the range is child range, which is split by unmap, does
not add to svms and have interval notifier.
Philip Yang [Sun, 18 Apr 2021 02:37:21 +0000 (22:37 -0400)]
drm/amdgpu: return IH ring drain finished if ring is empty
Sometimes IH do not setup ring wptr overflow flag after wptr exceed
rptr. As a workaround, if IH rptr equals to wptr, ring is empty,
return true to indicate IH ring checkpoint is processed, IH ring drain
is finished.
Christian König [Mon, 26 Apr 2021 08:06:13 +0000 (10:06 +0200)]
drm/amdgpu: restructure amdgpu_vram_mgr_new
Merge the two loops, loosen the restriction for big allocations.
This reduces the CPU overhead in the good case, but increases
it a bit under memory pressure.
Philip Yang [Mon, 26 Apr 2021 18:25:37 +0000 (14:25 -0400)]
drm/amdkfd: fix double free device pgmap resource
Use devm_memunmap_pages instead of memunmap_pages to release pgmap
and remove pgmap from device action, to avoid double free pgmap when
unloading driver module.
Release device memory region if failed to create device memory pages
structure.
Stylon Wang [Wed, 7 Apr 2021 10:14:55 +0000 (18:14 +0800)]
drm/amd/display: Expose internal display flag via debugfs
[Why & How]
Add a per-connector debugfs entry to expose internal display flag,
which is indication that the display is "internally connected"
and not hotpluggable.
Lewis Huang [Mon, 12 Apr 2021 23:02:28 +0000 (07:02 +0800)]
drm/amd/display: Revert wait vblank on update dpp clock
[Why]
This change only fix dpp clock switch to lower case.
New solution later can fix both case, which is "dc: skip
program clock when allow seamless boot"
[How]
This reverts commit "dc: wait vblank when stream enabled
and update dpp clock"
Darren Powell [Wed, 7 Apr 2021 22:40:34 +0000 (18:40 -0400)]
amdgpu/pm: set pp_dpm_dcefclk to readonly on NAVI10 and newer gpus
v2 : change condition to apply to all chips after NAVI10
Writing to dcefclk causes the gpu to become unresponsive, and requires a reboot.
Patch prevents user from successfully writing to file pp_dpm_dcefclk on parts
NAVI10 and newer, and gives better user feedback that this operation is not allowed.
Darren Powell [Wed, 7 Apr 2021 04:34:35 +0000 (00:34 -0400)]
amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID
Writing to dcefclk causes the gpu to become unresponsive, and requires a reboot.
Patch ignores a .force_clk_levels(SMU_DCEFCLK) call and issues an
info message.
Yingjie Wang [Fri, 9 Apr 2021 00:57:20 +0000 (17:57 -0700)]
drm/amd/dc: Fix a missing check bug in dm_dp_mst_detect()
In dm_dp_mst_detect(), We should check whether or not @connector
has been unregistered from userspace. If the connector is unregistered,
we should return disconnected status.
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Yingjie Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Harry Wentland [Thu, 22 Apr 2021 23:10:52 +0000 (19:10 -0400)]
drm/amd/display: Reject non-zero src_y and src_x for video planes
[Why]
This hasn't been well tested and leads to complete system hangs on DCN1
based systems, possibly others.
The system hang can be reproduced by gesturing the video on the YouTube
Android app on ChromeOS into full screen.
[How]
Reject atomic commits with non-zero drm_plane_state.src_x or src_y values.
v2:
- Add code comment describing the reason we're rejecting non-zero
src_x and src_y
- Drop gerrit Change-Id
- Add stable CC
- Based on amd-staging-drm-next
Nirmoy Das [Wed, 21 Apr 2021 16:09:46 +0000 (18:09 +0200)]
drm/amdgpu: cleanup amdgpu_bo_create()
Remove shadow bo related code as vm code is creating shadow bo
using proper API. Without shadow bo code, amdgpu_bo_create() is basically
a wrapper around amdgpu_bo_do_create(). So rename amdgpu_bo_do_create()
to amdgpu_bo_create().
Colin Ian King [Thu, 22 Apr 2021 12:44:52 +0000 (13:44 +0100)]
drm/amdkfd: remove redundant initialization to variable r
The variable r is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Colin Ian King [Thu, 22 Apr 2021 12:31:58 +0000 (13:31 +0100)]
drm/amdkfd: fix uint32 variable compared to less than zero
Currently the call to kfd_process_gpuidx_from_gpuid is returning an
int value and this is being assigned to a uint32_t variable gpuidx
and this is being checked for a negative error return which is always
going to be false. Fix this by making gpuidx an int32_t. This makes
gpuidx also type consistent with the use of gpuidx from the callers.
Addresses-Coverity: ("Unsigned compared against 0") Fixes: cda0f85bfa5e ("drm/amdkfd: refine migration policy with xnack on") Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Alex Sierra [Wed, 21 Apr 2021 18:54:09 +0000 (13:54 -0500)]
drm/amdkfd: set attribute access for default ranges
Attribute access value for default ranges is set, based on
process xnack on/off.
XNACK ON has GPU access attribute for unregistered ranges through page
fault. While XNACK OFF has no access attribute for unregistered ranges.
Alex Sierra [Mon, 12 Apr 2021 18:34:57 +0000 (13:34 -0500)]
drm/amdgpu: extend xnack limit page fault timeout
Extending this timeout will prevent IH from storm interrupts coming
from SDMA while a page fault is active. Currently, on Aldebaran,
handling that many interrupts can take a lot of CPU time
(up to 4 seconds).
This eventually causes timeouts in other tasks.
In order to support multi-process debugging, HWS PM4 packet
MAP_PROCESS requires an extension of 5 DWORDS to support targeting of
per-vmid SPI debug control registers as well as watch points per process.
Lee Jones [Fri, 16 Apr 2021 14:37:20 +0000 (15:37 +0100)]
drm/amd/amdgpu/amdgpu_cs: Repair some function naming disparity
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:685: warning: expecting prototype for cs_parser_fini(). Prototype was for amdgpu_cs_parser_fini() instead
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1502: warning: expecting prototype for amdgpu_cs_wait_all_fence(). Prototype was for amdgpu_cs_wait_all_fences() instead
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1656: warning: expecting prototype for amdgpu_cs_find_bo_va(). Prototype was for amdgpu_cs_find_mapping() instead
Lee Jones [Fri, 16 Apr 2021 14:37:17 +0000 (15:37 +0100)]
drm/amd/amdgpu/amdgpu_ttm: Fix incorrectly documented function 'amdgpu_ttm_copy_mem_to_mem()'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:311: warning: expecting prototype for amdgpu_copy_ttm_mem_to_mem(). Prototype was for amdgpu_ttm_copy_mem_to_mem() instead
Lee Jones [Fri, 16 Apr 2021 14:37:16 +0000 (15:37 +0100)]
drm/amd/amdgpu/amdgpu_gart: Correct a couple of function names in the docs
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:73: warning: expecting prototype for amdgpu_dummy_page_init(). Prototype was for amdgpu_gart_dummy_page_init() instead
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:96: warning: expecting prototype for amdgpu_dummy_page_fini(). Prototype was for amdgpu_gart_dummy_page_fini() instead
Lee Jones [Fri, 16 Apr 2021 14:37:10 +0000 (15:37 +0100)]
drm/radeon/radeon_device: Provide function name in kernel-doc header
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:1101: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function ‘amdgpu_device_suspend’:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3733:6: warning: variable ‘r’ set but not used [-Wunused-but-set-variable]
Felix Kuehling [Mon, 29 Mar 2021 22:49:12 +0000 (18:49 -0400)]
drm/amdkfd: Add CONFIG_HSA_AMD_SVM
Control whether to build SVM support into amdgpu with a Kconfig option.
This makes it easier to disable it in production kernels if this new
feature causes problems in production environments.
Use "depends on" instead of "select" for DEVICE_PRIVATE, as is
recommended for visible options.
Philip Yang [Thu, 10 Dec 2020 02:51:50 +0000 (21:51 -0500)]
drm/amdkfd: Add SVM API support capability bits
SVMAPISupported property added to HSA_CAPABILITY, the value match
HSA_CAPABILITY defined in Thunk spec:
SVMAPISupported: it will not be supported on older kernels that don't
have HMM or on systems with GFXv8 or older GPUs without support for
48-bit virtual addresses.
CoherentHostAccess property added to HSA_MEMORYPROPERTY, the value match
HSA_MEMORYPROPERTY defined in Thunk spec:
CoherentHostAccess: whether or not device memory can be coherently
accessed by the host CPU.
Felix Kuehling [Thu, 25 Feb 2021 04:57:33 +0000 (23:57 -0500)]
drm/amdkfd: multiple gpu migrate vram to vram
If prefetch range to gpu with acutal location is another gpu, or GPU
retry fault restore pages to migrate the range with acutal location is
gpu, then migrate from one gpu to another gpu.
Use system memory as bridge because sdma engine may not able to access
another gpu vram, use sdma of source gpu to migrate to system memory,
then use sdma of destination gpu to migrate from system memory to gpu.
Felix Kuehling [Thu, 25 Feb 2021 04:55:27 +0000 (23:55 -0500)]
drm/amdkfd: add svm range validate timestamp
With xnack on, add validate timestamp in order to handle GPU vm fault
from multiple GPUs.
If GPU retry fault need migrate the range to the best restore location,
use range validate timestamp to record system timestamp after range is
restored to update GPU page table.
Because multiple pages of same range have multiple retry fault, define
AMDGPU_SVM_RANGE_RETRY_FAULT_PENDING to the long time period that
pending retry fault may still comes after page table update, to skip
duplicate retry fault of same range.
If difference between system timestamp and range last validate timestamp
is bigger than AMDGPU_SVM_RANGE_RETRY_FAULT_PENDING, that means the
retry fault is from another GPU, then continue to handle retry fault
recover.
Felix Kuehling [Thu, 25 Feb 2021 04:46:28 +0000 (23:46 -0500)]
drm/amdkfd: refine migration policy with xnack on
With xnack on, GPU vm fault handler decide the best restore location,
then migrate range to the best restore location and update GPU mapping
to recover the GPU vm fault.
Alex Sierra [Tue, 28 Jul 2020 21:04:41 +0000 (16:04 -0500)]
drm/amdgpu: svm bo enable_signal call condition
[why]
To support svm bo eviction mechanism.
[how]
If the BO crated has AMDGPU_AMDKFD_CREATE_SVM_BO flag set,
enable_signal callback will be called inside amdgpu_evict_flags.
This also causes gutting of the BO by removing all placements,
so that TTM won't actually do an eviction. Instead it will discard
the memory held by the BO. This is needed for HMM migration to user
mode system memory pages.
Felix Kuehling [Thu, 25 Feb 2021 04:24:53 +0000 (23:24 -0500)]
drm/amdkfd: add svm_bo eviction mechanism support
svm_bo eviction mechanism is different from regular BOs.
Every SVM_BO created contains one eviction fence and one
worker item for eviction process.
SVM_BOs can be attached to one or more pranges.
For SVM_BO eviction mechanism, TTM will start to call
enable_signal callback for every SVM_BO until VRAM space
is available.
Here, all the ttm_evict calls are synchronous, this guarantees
that each eviction has completed and the fence has signaled before
it returns.
Alex Sierra [Tue, 28 Jul 2020 18:35:32 +0000 (13:35 -0500)]
drm/amdkfd: add svm_bo reference for eviction fence
[why]
As part of the SVM functionality, the eviction mechanism used for
SVM_BOs is different. This mechanism uses one eviction fence per prange,
instead of one fence per kfd_process.
[how]
A svm_bo reference to amdgpu_amdkfd_fence to allow differentiate between
SVM_BO or regular BO evictions. This also include modifications to set the
reference at the fence creation call.
projects / linux.git / log