linux/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c, branch v5.12

drm/amd/amdgpu/amdgpu_fence: Fix some issues pertaining to function documentation

2020-11-13T05:14:56Z

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:139: warning: Function parameter or member 'flags' not described in 'amdgpu_fence_emit' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:197: warning: Function parameter or member 'timeout' not described in 'amdgpu_fence_emit_polling' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:302: warning: Function parameter or member 't' not described in 'amdgpu_fence_fallback' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:302: warning: Excess function parameter 'work' description in 'amdgpu_fence_fallback' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:320: warning: Excess function parameter 'adev' description in 'amdgpu_fence_wait_empty' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:649: warning: Function parameter or member 'f' not described in 'amdgpu_fence_enable_signaling' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:649: warning: Excess function parameter 'fence' description in 'amdgpu_fence_enable_signaling' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:684: warning: Function parameter or member 'f' not described in 'amdgpu_fence_release' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:684: warning: Excess function parameter 'fence' description in 'amdgpu_fence_release' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:749: warning: Function parameter or member 'm' not described in 'amdgpu_debugfs_gpu_recover' drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:749: warning: Function parameter or member 'data' not described in 'amdgpu_debugfs_gpu_recover' Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: Jerome Glisse Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher

drm/amdgpu: Get DRM dev from adev by inline-f

2020-08-24T17:06:06Z

Add a static inline adev_to_drm() to obtain the DRM device pointer from an amdgpu_device pointer. Signed-off-by: Luben Tuikov Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: drm_device to amdgpu_device by inline-f (v2)

2020-08-24T17:06:06Z

Get the amdgpu_device from the DRM device by use of an inline function, drm_to_adev(). The inline function resolves a pointer to struct drm_device to a pointer to struct amdgpu_device. v2: Use a typed visible static inline function instead of an invisible macro. Signed-off-by: Luben Tuikov Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: use ARRAY_SIZE() to add amdgpu debugfs files

2020-07-14T18:38:41Z

to easily add new debugfs file w/o changing the hardcoded list count. Signed-off-by: Xiaojie Yuan Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher

gpu/drm: Remove debug info about CPU address

2020-07-08T13:04:21Z

When I update the latest kernel, I see the following "____ptrval____" boot messages. [ 1.872600] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x0000000048000c00 and cpu addr 0x(____ptrval____) [ 1.879095] radeon 0000:01:05.0: fence driver on ring 5 use gpu addr 0x0000000040056038 and cpu addr 0x(____ptrval____) Both radeon_fence_driver_start_ring() and amdgpu_fence_driver_start_ring() have the similar issue, there exists the following two methods to solve it: (1) Use "%pK" instead of "%p" so that the CPU address can be printed when the kptr_restrict sysctl is set to 1. (2) Just completely drop the CPU address suggested by Christian, because the CPU address was useful in the past, but isn't any more. We now have a debugfs file to read the current fence values. Since the CPU address is not much useful, just remove the debug info about CPU address. Reviewed-by: Christian König Signed-off-by: Tiezhu Yang Signed-off-by: Alex Deucher

drm/amdgpu: restrict the hw sched jobs number to power of two

2020-07-01T05:59:23Z

the module parameter sched_hw_submission is probably from user mode, and the kernel need to check whether it is legal. 1. align hw sched jobs to power of 2 and set minimum number is 2. 2. use kernel api is_power_of_2() to simplify driver code. Signed-off-by: Kevin Wang Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu/fence: fix ref count leak when pm_runtime_get_sync fails

2020-07-01T05:59:22Z

The call to pm_runtime_get_sync increments the counter even in case of failure, leading to incorrect ref count. In case of failure, decrement the ref count before returning. Reviewed-by: Felix Kuehling Acked-by: Rajneesh Bhardwaj Signed-off-by: Alex Deucher

drm/amdgpu/fence: use the no_scheduler flag

2020-07-01T05:59:16Z

Rather than checking the ring type manually. We already set this for MES and KIQ (and a few other special cases). Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: skip GPU scheduler setup for KIQ and MES ring

2020-07-01T05:59:13Z

Fix the coding error to skip GPU scheduler setup for KIQ and MES ring. Signed-off-by: Likun Gao Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher

drm/amdgpu: no need to set up GPU scheduler for mes ring

2020-07-01T05:59:08Z

As mes ring directly submits to hardwared, it's no need to set up GPU scheduler for mes ring. Signed-off-by: Jack Xiao Acked-by: Alex Deucher Reviewed-by: Hawking Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher