diff options
Diffstat (limited to 'common/recipes-kernel/linux/linux-yocto-4.14.71/4674-drm-amdgpu-Grab-put-runtime-PM-references-in-atomic_.patch')
| -rw-r--r-- | common/recipes-kernel/linux/linux-yocto-4.14.71/4674-drm-amdgpu-Grab-put-runtime-PM-references-in-atomic_.patch | 70 |
1 files changed, 70 insertions, 0 deletions
diff --git a/common/recipes-kernel/linux/linux-yocto-4.14.71/4674-drm-amdgpu-Grab-put-runtime-PM-references-in-atomic_.patch b/common/recipes-kernel/linux/linux-yocto-4.14.71/4674-drm-amdgpu-Grab-put-runtime-PM-references-in-atomic_.patch new file mode 100644 index 00000000..0b5fc1d5 --- /dev/null +++ b/common/recipes-kernel/linux/linux-yocto-4.14.71/4674-drm-amdgpu-Grab-put-runtime-PM-references-in-atomic_.patch @@ -0,0 +1,70 @@ +From 1f84d22a2744def4a3fea7b227b566c00c004971 Mon Sep 17 00:00:00 2001 +From: Lyude Paul <lyude@redhat.com> +Date: Mon, 4 Jun 2018 15:35:03 -0400 +Subject: [PATCH 4674/5725] drm/amdgpu: Grab/put runtime PM references in + atomic_commit_tail() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +So, unfortunately I recently made the discovery that in the upstream +kernel, the only reason that amdgpu is not currently suffering from +issues with runtime PM putting the GPU into suspend while it's driving +displays is due to the fact that on most prime systems, we have sound +devices associated with the GPU that hold their own runtime PM ref for +the GPU. + +What this means however, is that in the event that there isn't any kind +of sound device active (which can easily be reproduced by building a +kernel with sound drivers disabled), the GPU will fall asleep even when +there's displays active. This appears to be in part due to the fact that +amdgpu has not actually ever relied on it's rpm_idle() function to be +the only thing keeping it running, and normally grabs it's own power +references whenever there are displays active (as can be seen with the +original pre-DC codepath in amdgpu_display_crtc_set_config() in +amdgpu_display.c). This means it's very likely that this bug was +introduced during the switch over the DC. + +So to fix this, we start grabbing runtime PM references every time we +enable a previously disabled CRTC in atomic_commit_tail(). This appears +to be the correct solution, as it matches up with what i915 does in +i915/intel_runtime_pm.c. + +The one sideaffect of this is that we ignore the variable that the +pre-DC code used to use for tracking when it needed runtime PM refs, +adev->have_disp_power_ref. This is mainly because there's no way for a +driver to tell whether or not all of it's CRTCs are enabled or disabled +when we've begun committing an atomic state, as there may be CRTC +commits happening in parallel that aren't contained within the atomic +state being committed. So, it's safer to just get/put a reference for +each CRTC being enabled or disabled in the new atomic state. + +Signed-off-by: Lyude Paul <lyude@redhat.com> +Acked-by: Christian König <christian.koenig@amd.com>. +Reviewed-by: Harry Wentland <harry.wentland@amd.com> + +Conflicts: + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + +Change-Id: I726d59525f00acfd1b13501271f0feb23c0d1af5 +Signed-off-by: Jim Qu <Jim.Qu@amd.com> +Signed-off-by: Kalyan Alle <kalyan.alle@amd.com> +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +index 1451026..95ab236 100644 +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -4605,6 +4605,7 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) + * displays anymore + */ + pm_runtime_mark_last_busy(dev->dev); ++ + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) { + if (old_crtc_state->active && !new_crtc_state->active) + pm_runtime_put_autosuspend(dev->dev); +-- +2.7.4 + |