linux-stable.git/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c, branch v4.19.321 Linux kernel stable tree drm/amdgpu: Release 'adev->pm.fw' before return in 'amdgpu_device_need_post()' 2024-02-23T07:12:51+00:00 Srinivasan Shanmugam srinivasan.shanmugam@amd.com 2023-12-21T12:43:11+00:00 616053201f939cb326836316d8afcd1e3d2df18b [ Upstream commit 8a44fdd3cf91debbd09b43bd2519ad2b2486ccf4 ] In function 'amdgpu_device_need_post(struct amdgpu_device *adev)' - 'adev->pm.fw' may not be released before return. Using the function release_firmware() to release adev->pm.fw. Thus fixing the below: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1571 amdgpu_device_need_post() warn: 'adev->pm.fw' from request_firmware() not released on lines: 1554. Cc: Monk Liu <Monk.Liu@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Suggested-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8a44fdd3cf91debbd09b43bd2519ad2b2486ccf4 ]

In function 'amdgpu_device_need_post(struct amdgpu_device *adev)' -
'adev->pm.fw' may not be released before return.

Using the function release_firmware() to release adev->pm.fw.

Thus fixing the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1571 amdgpu_device_need_post() warn: 'adev->pm.fw' from request_firmware() not released on lines: 1554.

Cc: Monk Liu <Monk.Liu@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar() 2023-09-23T08:48:02+00:00 Arnd Bergmann arnd@arndb.de 2023-07-07T11:11:51+00:00 014d15b8f3e57434993381f3e6235d0fc89bdd69 [ Upstream commit 822130b5e8834ab30ad410cf19a582e5014b9a85 ] On 32-bit architectures comparing a resource against a value larger than U32_MAX can cause a warning: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] res->start > 0x100000000ull) ~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ As gcc does not warn about this in dead code, add an IS_ENABLED() check at the start of the function. This will always return success but not actually resize the BAR on 32-bit architectures without high memory, which is exactly what we want here, as the driver can fall back to bank switching the VRAM access. Fixes: 31b8adab3247 ("drm/amdgpu: require a root bus window above 4GB for BAR resize") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 822130b5e8834ab30ad410cf19a582e5014b9a85 ]

On 32-bit architectures comparing a resource against a value larger than
U32_MAX can cause a warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
                    res->start > 0x100000000ull)
                    ~~~~~~~~~~ ^ ~~~~~~~~~~~~~~

As gcc does not warn about this in dead code, add an IS_ENABLED() check at
the start of the function. This will always return success but not actually resize
the BAR on 32-bit architectures without high memory, which is exactly what
we want here, as the driver can fall back to bank switching the VRAM
access.

Fixes: 31b8adab3247 ("drm/amdgpu: require a root bus window above 4GB for BAR resize")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdgpu: Put enable gfx off feature to a delay thread 2023-05-17T09:13:24+00:00 Rex Zhu Rex.Zhu@amd.com 2018-07-27T13:06:30+00:00 c9d825138667edec044c953687d7497aa15b2575 [ Upstream commit 1e317b99f0c244bd8830918fdae9715210baf4fe ] delay to enable gfx off feature to avoid gfx on/off frequently suggested by Alex and Evan. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: 2397e3d8d2e1 ("drm/amdgpu: add a missing lock for AMDGPU_SCHED") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 1e317b99f0c244bd8830918fdae9715210baf4fe ]

delay to enable gfx off feature to avoid gfx on/off frequently
suggested by Alex and Evan.

Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Stable-dep-of: 2397e3d8d2e1 ("drm/amdgpu: add a missing lock for AMDGPU_SCHED")
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdgpu: Add amdgpu_gfx_off_ctrl function 2023-05-17T09:13:24+00:00 Rex Zhu Rex.Zhu@amd.com 2018-07-30T08:59:09+00:00 0403be7864d9a386ddb72d58355e96319ca64d63 [ Upstream commit d23ee13fba23a3039971a976b2c4857cb5ba9c73 ] v2: 1. drop the special handling for the hw IP suggested by hawking and Christian. 2. refine the variable name suggested by Flora. This funciton as the entry of gfx off feature. we arbitrat gfx off feature enable/disable in this function. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: 2397e3d8d2e1 ("drm/amdgpu: add a missing lock for AMDGPU_SCHED") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d23ee13fba23a3039971a976b2c4857cb5ba9c73 ]

v2:
   1. drop the special handling for the hw IP
      suggested by hawking and Christian.
   2. refine the variable name suggested by Flora.

This funciton as the entry of gfx off feature.
we arbitrat gfx off feature enable/disable in this
function.

Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Stable-dep-of: 2397e3d8d2e1 ("drm/amdgpu: add a missing lock for AMDGPU_SCHED")
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amd/amdgpu/sriov disable all ip hw status by default 2021-07-20T14:15:58+00:00 Jack Zhang Jack.Zhang1@amd.com 2021-04-27T09:08:47+00:00 38fe84738c50b248414de3c9163a217f7270cf20 [ Upstream commit 95ea3dbc4e9548d35ab6fbf67675cef8c293e2f5 ] Disable all ip's hw status to false before any hw_init. Only set it to true until its hw_init is executed. The old 5.9 branch has this change but somehow the 5.11 kernrel does not have this fix. Without this change, sriov tdr have gfx IB test fail. Signed-off-by: Jack Zhang <Jack.Zhang1@amd.com> Review-by: Emily Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 95ea3dbc4e9548d35ab6fbf67675cef8c293e2f5 ]

Disable all ip's hw status to false before any hw_init.
Only set it to true until its hw_init is executed.

The old 5.9 branch has this change but somehow the 5.11 kernrel does
not have this fix.

Without this change, sriov tdr have gfx IB test fail.

Signed-off-by: Jack Zhang <Jack.Zhang1@amd.com>
Review-by: Emily Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdgpu/sriov:Correct pfvf exchange logic 2019-02-20T09:25:39+00:00 Emily Deng Emily.Deng@amd.com 2018-12-29T09:46:05+00:00 f749f9702c9885c9fb48b78e8e74b43ecb857845 [ Upstream commit b8cf66182eddb22e9c7539821ed6eecdb4f86d1a ] The pfvf exchange need be in exclusive mode. And add pfvf exchange in gpu reset. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-By: Xiangliang Yu <Xiangliang.Yu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit b8cf66182eddb22e9c7539821ed6eecdb4f86d1a ]

The pfvf exchange need be in exclusive mode. And add pfvf exchange in gpu
reset.

Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-By: Xiangliang Yu <Xiangliang.Yu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdgpu: move PSP init prior to IH in gpu reset 2018-09-11T03:58:21+00:00 Emily Deng Emily.Deng@amd.com 2018-09-10T09:51:31+00:00 3a74987b24279d242d17f522f8435f1942a3c948 since we use PSP to program IH regs now Signed-off-by: Monk Liu <Monk.Liu@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Emily Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
since we use PSP to program IH regs now

Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Revert "drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0 with CONFIG_X86" 2018-08-21T19:32:28+00:00 Leo (Sunpeng) Li sunpeng.li@amd.com 2018-08-16T19:44:38+00:00 dc37a9a08d5760e405ffdd94ec6bbb6efededba6 This reverts commit 8624c3c4dbfe24fc6740687236a2e196f5f4bfb0. We need CONFIG_DRM_AMD_DC_DCN1_0 to guard code that is using fp math. Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
This reverts commit 8624c3c4dbfe24fc6740687236a2e196f5f4bfb0.

We need CONFIG_DRM_AMD_DC_DCN1_0 to guard code that is using fp math.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Merge branch 'drm-next-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-next 2018-08-10T01:43:02+00:00 Dave Airlie airlied@redhat.com 2018-08-10T01:43:02+00:00 557ce95051c8eff67af48612ab350d8408aa0541 More fixes for 4.19: - Fixes for scheduler - Fix for SR-IOV - Fixes for display Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180809200052.2777-1-alexander.deucher@amd.com 
More fixes for 4.19:
- Fixes for scheduler
- Fix for SR-IOV
- Fixes for display

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180809200052.2777-1-alexander.deucher@amd.com
drm/amdgpu/sriov: give 8s for recover vram under RUNTIME 2018-08-09T16:59:17+00:00 Emily Deng Emily.Deng@amd.com 2018-08-09T02:03:04+00:00 b045d3af7d1f443dd5209a096568e0ce983127e9 Extend the timeout for recovering vram bos from shadows on sr-iov to cover the worst case scenario for timeslices and VFs Under runtime, the wait fence time could be quite long when other VFs are in exclusive mode. For example, for 4 VF, every VF's exclusive timeout time is set to 3s, then the worst case is 9s. If the VF number is more than 4,then the worst case time will be longer. The 8s is the test data, with setting to 8s, it will pass the TDR test for 1000 times. SWDEV-161490 Signed-off-by: Monk Liu <Monk.Liu@amd.com> Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Extend the timeout for recovering vram bos from shadows on sr-iov
to cover the worst case scenario for timeslices and VFs

Under runtime, the wait fence time could be quite long when
other VFs are in exclusive mode. For example, for 4 VF, every
VF's exclusive timeout time is set to 3s, then the worst case is
9s. If the VF number is more than 4,then the worst case time will
be longer.
The 8s is the test data, with setting to 8s, it will pass the TDR
test for 1000 times.

SWDEV-161490

Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>