From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lyude Paul Subject: [PATCH v2 2/3] drm/amdgpu: Don't fail resume process if resuming atomic state fails Date: Tue, 8 Jan 2019 16:11:28 -0500 Message-ID: <20190108211133.32564-3-lyude@redhat.com> References: <20190108211133.32564-1-lyude@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20190108211133.32564-1-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "amd-gfx" To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Cc: "David (ChunMing) Zhou" , Leo Li , Tony Cheng , David Francis , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Nicholas Kazlauskas , Bhawanpreet Lakha , David Airlie , Jerry Zuo , Daniel Vetter , Alex Deucher , Mikita Lipski , Harry Wentland , =?UTF-8?q?Christian=20K=C3=B6nig?= , Anthony Koo VGhpcyBpcyBhbiB1Z2x5IG9uZSB1bmZvcnR1bmF0ZWx5LiBDdXJyZW50bHksIGFsbCBEUk0gZHJp dmVycyBzdXBwb3J0aW5nCmF0b21pYyBtb2Rlc2V0dGluZyB3aWxsIHNhdmUgdGhlIHN0YXRlIHRo YXQgdXNlcnNwYWNlIGhhZCBzZXQgYmVmb3JlCnN1c3BlbmRpbmcsIHRoZW4gYXR0ZW1wdCB0byBy ZXN0b3JlIHRoYXQgc3RhdGUgb24gcmVzdW1lLiBUaGlzIHByb2JhYmx5CndvcmtlZCB2ZXJ5IHdl bGwgYXQgb25lIHBvaW50LCBsaWtlIG1hbnkgb3RoZXIgdGhpbmdzLCB1bnRpbCBEUCBNU1QgY2Ft ZQppbnRvIHRoZSBwaWN0dXJlLiBXaGlsZSBpdCdzIGVhc3kgdG8gcmVzdG9yZSBzdGF0ZSBvbiBu b3JtYWwgZGlzcGxheQpjb25uZWN0b3JzIHRoYXQgd2VyZSBkaXNjb25uZWN0ZWQgZHVyaW5nIHN1 c3BlbmQgcmVnYXJkbGVzcyBvZiB0aGVpcgpzdGF0ZSBwb3N0LXJlc3VtZSwgdGhpcyBjYW4ndCBy ZWFsbHkgYmUgZG9uZSB3aXRoIE1TVCBiZWNhdXNlIG9mIHRoZQpmYWN0IHRoYXQgc2V0dGluZyB1 cCBhIGRvd25zdHJlYW0gc2luayByZXF1aXJlcyBwZXJmb3JtaW5nIHNpZGViYW5kCnRyYW5zYWN0 aW9ucyBiZXR3ZWVuIHRoZSBzb3VyY2UgYW5kIHRoZSBNU1QgaHViLCBzZW5kaW5nIG91dCB0aGUg QUNUCnBhY2tldHMsIGV0Yy4KCkJlY2F1c2Ugb2YgdGhpcywgdGhlcmUgaXNuJ3QgcmVhbGx5IGEg Z3VhcmFudGVlIHRoYXQgd2UgY2FuIHJlc3RvcmUgdGhlCmF0b21pYyBzdGF0ZSB3ZSBoYWQgYmVm b3JlIHN1c3BlbmQgb25jZSB3ZSd2ZSByZXN1bWVkLiBUaGlzIHN1Y2tzIHByZXR0eQpiYWQsIGJ1 dCBzbyBmYXIgSSBoYXZlbid0IHJ1biBpbnRvIGFueSBjb21wb3NpdG9ycyB0aGF0IHRoaXMgYWN0 dWFsbHkKY2F1c2VzIHNlcmlvdXMgaXNzdWVzIHdpdGguIE1vc3QgY29tcG9zaXRvcnMgd2lsbCBu b3RpY2UgdGhlIGhvdHBsdWcgd2UKc2VuZCBhZnRlcndhcmRzLCBhbmQgdGhlbiByZXByb2JlIHN0 YXRlLgoKU2luY2Ugbm91dmVhdSBhbmQgaTkxNSBhbHNvIGRvbid0IGZhaWwgdGhlIHN1c3BlbmQv cmVzdW1lIHByb2Nlc3MgZHVlIHRvCmZhaWxpbmcgdG8gcmVzdG9yZSB0aGUgYXRvbWljIHN0YXRl LCBsZXQncyBtYWtlIGFtZGdwdSBtYXRjaCB0aGlzCmJlaGF2aW9yLiBCZXR0ZXIgdG8gcmVzdW1l IHRoZSBHUFUgcHJvcGVybHksIHRoZW4gdG8gc3RvcCB0aGUgcHJvY2VzcwpoYWxmIHdheSBiZWNh dXNlIG9mIGEgcG90ZW50aWFsbHkgdW5hdm9pZGFibGUgYXRvbWljIGNvbW1pdCBmYWlsdXJlLgoK RXZlbnR1YWxseSwgd2UnbGwgaGF2ZSBhIHJlYWwgZml4IGZvciB0aGlzIHByb2JsZW0gb24gdGhl IERSTSBsZXZlbC4gQnV0CndlJ3ZlIGdvdCBzb21lIG1vcmUgaW1wb3J0YW50IGxvdy1oYW5naW5n IGZydWl0IHRvIGRlYWwgd2l0aCBmaXJzdC4KClNpZ25lZC1vZmYtYnk6IEx5dWRlIFBhdWwgPGx5 dWRlQHJlZGhhdC5jb20+ClJldmlld2VkLWJ5OiBIYXJyeSBXZW50bGFuZCA8aGFycnkud2VudGxh bmRAYW1kLmNvbT4KQ2M6IEplcnJ5IFp1byA8SmVycnkuWnVvQGFtZC5jb20+CkNjOiA8c3RhYmxl QHZnZXIua2VybmVsLm9yZz4gIyB2NC4xNSsKLS0tCiBkcml2ZXJzL2dwdS9kcm0vYW1kL2Rpc3Bs YXkvYW1kZ3B1X2RtL2FtZGdwdV9kbS5jIHwgNSArKy0tLQogMSBmaWxlIGNoYW5nZWQsIDIgaW5z ZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0v YW1kL2Rpc3BsYXkvYW1kZ3B1X2RtL2FtZGdwdV9kbS5jIGIvZHJpdmVycy9ncHUvZHJtL2FtZC9k aXNwbGF5L2FtZGdwdV9kbS9hbWRncHVfZG0uYwppbmRleCAzZjMyNmEyYzUxM2IuLmEzZTY1ZTQ1 NzM0OCAxMDA2NDQKLS0tIGEvZHJpdmVycy9ncHUvZHJtL2FtZC9kaXNwbGF5L2FtZGdwdV9kbS9h bWRncHVfZG0uYworKysgYi9kcml2ZXJzL2dwdS9kcm0vYW1kL2Rpc3BsYXkvYW1kZ3B1X2RtL2Ft ZGdwdV9kbS5jCkBAIC05MTIsNyArOTEyLDYgQEAgc3RhdGljIGludCBkbV9yZXN1bWUodm9pZCAq aGFuZGxlKQogCXN0cnVjdCBkcm1fcGxhbmVfc3RhdGUgKm5ld19wbGFuZV9zdGF0ZTsKIAlzdHJ1 Y3QgZG1fcGxhbmVfc3RhdGUgKmRtX25ld19wbGFuZV9zdGF0ZTsKIAllbnVtIGRjX2Nvbm5lY3Rp b25fdHlwZSBuZXdfY29ubmVjdGlvbl90eXBlID0gZGNfY29ubmVjdGlvbl9ub25lOwotCWludCBy ZXQ7CiAJaW50IGk7CiAKIAkvKiBwb3dlciBvbiBoYXJkd2FyZSAqLwpAQCAtOTg1LDEzICs5ODQs MTMgQEAgc3RhdGljIGludCBkbV9yZXN1bWUodm9pZCAqaGFuZGxlKQogCQl9CiAJfQogCi0JcmV0 ID0gZHJtX2F0b21pY19oZWxwZXJfcmVzdW1lKGRkZXYsIGRtLT5jYWNoZWRfc3RhdGUpOworCWRy bV9hdG9taWNfaGVscGVyX3Jlc3VtZShkZGV2LCBkbS0+Y2FjaGVkX3N0YXRlKTsKIAogCWRtLT5j YWNoZWRfc3RhdGUgPSBOVUxMOwogCiAJYW1kZ3B1X2RtX2lycV9yZXN1bWVfbGF0ZShhZGV2KTsK IAotCXJldHVybiByZXQ7CisJcmV0dXJuIDA7CiB9CiAKIC8qKgotLSAKMi4yMC4xCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwphbWQtZ2Z4IG1haWxpbmcg bGlzdAphbWQtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNr dG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FtZC1nZngK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 881ADC43387 for ; Tue, 8 Jan 2019 21:12:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5EBD320675 for ; Tue, 8 Jan 2019 21:12:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729856AbfAHVMF (ORCPT ); Tue, 8 Jan 2019 16:12:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35622 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729768AbfAHVLz (ORCPT ); Tue, 8 Jan 2019 16:11:55 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B7143E3E1C; Tue, 8 Jan 2019 21:11:54 +0000 (UTC) Received: from malachite.bss.redhat.com (dhcp-10-20-1-11.bss.redhat.com [10.20.1.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id E3C2519492; Tue, 8 Jan 2019 21:11:52 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org Cc: Harry Wentland , Jerry Zuo , stable@vger.kernel.org, Leo Li , Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , "David (ChunMing) Zhou" , David Airlie , Daniel Vetter , Tony Cheng , David Francis , Nicholas Kazlauskas , Mikita Lipski , Bhawanpreet Lakha , Anthony Koo , linux-kernel@vger.kernel.org Subject: [PATCH v2 2/3] drm/amdgpu: Don't fail resume process if resuming atomic state fails Date: Tue, 8 Jan 2019 16:11:28 -0500 Message-Id: <20190108211133.32564-3-lyude@redhat.com> In-Reply-To: <20190108211133.32564-1-lyude@redhat.com> References: <20190108211133.32564-1-lyude@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 08 Jan 2019 21:11:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an ugly one unfortunately. Currently, all DRM drivers supporting atomic modesetting will save the state that userspace had set before suspending, then attempt to restore that state on resume. This probably worked very well at one point, like many other things, until DP MST came into the picture. While it's easy to restore state on normal display connectors that were disconnected during suspend regardless of their state post-resume, this can't really be done with MST because of the fact that setting up a downstream sink requires performing sideband transactions between the source and the MST hub, sending out the ACT packets, etc. Because of this, there isn't really a guarantee that we can restore the atomic state we had before suspend once we've resumed. This sucks pretty bad, but so far I haven't run into any compositors that this actually causes serious issues with. Most compositors will notice the hotplug we send afterwards, and then reprobe state. Since nouveau and i915 also don't fail the suspend/resume process due to failing to restore the atomic state, let's make amdgpu match this behavior. Better to resume the GPU properly, then to stop the process half way because of a potentially unavoidable atomic commit failure. Eventually, we'll have a real fix for this problem on the DRM level. But we've got some more important low-hanging fruit to deal with first. Signed-off-by: Lyude Paul Reviewed-by: Harry Wentland Cc: Jerry Zuo Cc: # v4.15+ --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) 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 3f326a2c513b..a3e65e457348 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -912,7 +912,6 @@ static int dm_resume(void *handle) struct drm_plane_state *new_plane_state; struct dm_plane_state *dm_new_plane_state; enum dc_connection_type new_connection_type = dc_connection_none; - int ret; int i; /* power on hardware */ @@ -985,13 +984,13 @@ static int dm_resume(void *handle) } } - ret = drm_atomic_helper_resume(ddev, dm->cached_state); + drm_atomic_helper_resume(ddev, dm->cached_state); dm->cached_state = NULL; amdgpu_dm_irq_resume_late(adev); - return ret; + return 0; } /** -- 2.20.1