From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukas Wunner Subject: Re: [PATCH 1/2] drm/fb_helper: Add drm_fb_helper_output_poll_changed_with_rpm() Date: Sat, 21 Jul 2018 11:39:55 +0200 Message-ID: <20180721093955.GA32572@wunner.de> References: <20180718205645.25924-1-lyude@redhat.com> <20180718205645.25924-2-lyude@redhat.com> <20180719074926.GA14303@wunner.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Lyude Paul Cc: David Airlie , nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter , Ben Skeggs List-Id: nouveau.vger.kernel.org T24gVGh1LCBKdWwgMTksIDIwMTggYXQgMDg6MDg6MTVQTSAtMDQwMCwgTHl1ZGUgUGF1bCB3cm90 ZToKPiBPbiBUaHUsIDIwMTgtMDctMTkgYXQgMDk6NDkgKzAyMDAsIEx1a2FzIFd1bm5lciB3cm90 ZToKPiA+IE9uIFdlZCwgSnVsIDE4LCAyMDE4IGF0IDA0OjU2OjM5UE0gLTA0MDAsIEx5dWRlIFBh dWwgd3JvdGU6Cj4gPiA+IFdoZW4gRFAgTVNUIGh1YnMgZ2V0IGNvbmZ1c2VkLCB0aGV5IGNhbiBv Y2Nhc2lvbmFsbHkgc3RvcCByZXNwb25kaW5nIGZvcgo+ID4gPiBhIGdvb2QgYml0IG9mIHRpbWUg dXAgdW50aWwgdGhlIHBvaW50IHdoZXJlIHRoZSBEUk0gZHJpdmVyIG1hbmFnZXMgdG8KPiA+ID4g ZG8gdGhlIHJpZ2h0IERQQ0QgYWNjZXNzZXMgdG8gZ2V0IGl0IHRvIHN0YXJ0IHJlc3BvbmRpbmcg YWdhaW4uIEluIGEKPiA+ID4gd29yc3QgY2FzZSBzY2VuYXJpbyBob3dldmVyLCB0aGlzIHByb2Nl c3MgY2FuIHRha2UgdXB3YXJkcyBvZiAxMCsKPiA+ID4gc2Vjb25kcy4KPiA+ID4gCj4gPiA+IEN1 cnJlbnRseSB3ZSB1c2UgdGhlIGRlZmF1bHQgb3V0cHV0X3BvbGxfY2hhbmdlZCBoYW5kbGVyCj4g PiA+IGRybV9mYl9oZWxwZXJfb3V0cHV0X3BvbGxfY2hhbmdlZCgpIHRvIGhhbmRsZSBvdXRwdXQg cG9sbGluZywgd2hpY2gKPiA+ID4gZG9lc24ndCBoYXBwZW4gdG8gZ3JhYiBhbnkgcG93ZXIgcmVm ZXJlbmNlcyBvbiB0aGUgZGV2aWNlIHdoZW4gcG9sbGluZy4KPiA+ID4gSWYgd2UncmUgdW5sdWNr eSBlbm91Z2ggdG8gaGF2ZSBhIGh1YiAoc3VjaCBhcyBMZW5vdm8ncyBpbmZhbW91cyBsYXB0b3AK PiA+ID4gZG9ja3MgZm9yIHRoZSBQNXgvUDd4IHNlcmllcykgdGhhdCdzIGVhc2lseSBzdGFydGxl ZCBhbmQgY29uZnVzZWQsIHRoaXMKPiA+ID4gY2FuIGxlYWQgdG8gYSBwcmV0dHkgbmFzdHkgZGVh ZGxvY2sgc2l0dWF0aW9uIHRoYXQgbG9va3MgbGlrZSB0aGlzOgo+ID4gPiAKPiA+ID4gLSBIb3Rw bHVnIGV2ZW50IGZyb20gaHViIGhhcHBlbnMsIHdlIGVudGVyCj4gPiA+ICAgZHJtX2ZiX2hlbHBl cl9vdXRwdXRfcG9sbF9jaGFuZ2VkKCkgYW5kIHN0YXJ0IGNvbW11bmljYXRpbmcgd2l0aCB0aGUK PiA+ID4gICBodWIKPiA+ID4gLSBXaGlsZSB3ZSdyZSBpbiBkcm1fZmJfaGVscGVyX291dHB1dF9w b2xsX2NoYW5nZWQoKSBhbmQgYXR0ZW1wdGluZyB0bwo+ID4gPiAgIGNvbW11bmljYXRlIHdpdGgg dGhlIGh1Yiwgd2UgZW5kIHVwIGNvbmZ1c2luZyBpdCBhbmQgY2F1c2UgaXQgdG8gc3RvcAo+ID4g PiAgIHJlc3BvbmRpbmcgZm9yIGF0IGxlYXN0IDEwIHNlY29uZHMKPiA+ID4gLSBBZnRlciA1IHNl Y29uZHMgb2YgYmVpbmcgaW4gZHJtX2ZiX2hlbHBlcl9vdXRwdXRfcG9sbF9jaGFuZ2VkKCksIHRo ZQo+ID4gPiAgIHBtIGNvcmUgYXR0ZW1wdHMgdG8gcHV0IHRoZSBHUFUgaW50byBhdXRvc3VzcGVu ZCwgd2hpY2ggZW5kcyB1cAo+ID4gPiAgIGNhbGxpbmcgZHJtX2ttc19oZWxwZXJfcG9sbF9kaXNh YmxlKCkKPiA+ID4gLSBXaGlsZSB0aGUgcnVudGltZSBQTSBjb3JlIGlzIHdhaXRpbmcgaW4gZHJt X2ttc19oZWxwZXJfcG9sbF9kaXNhYmxlKCkKPiA+ID4gICBmb3IgdGhlIG91dHB1dCBwb2xsIHRv IGZpbmlzaCwgd2UgZW5kIHVwIGZpbmFsbHkgZGV0ZWN0aW5nIGFuIE1TVAo+ID4gPiAgIGRpc3Bs YXkKPiA+ID4gLSBXZSBub3RpY2UgdGhlIG5ldyBkaXNwbGF5IGFuZCB0cmllcyB0byBlbmFibGUg aXQsIHdoaWNoIHRyaWdnZXJzCj4gPiA+ICAgYW4gYXRvbWljIGNvbW1pdCB3aGljaCB0cmlnZ2Vy cyBhIGNhbGwgdG8gcG1fcnVudGltZV9nZXRfc3luYygpCj4gPiA+IC0gdGhlIG91dHB1dCBwb2xs IHRocmVhZCBkZWFkbG9ja3MgdGhlIHBtIGNvcmUgd2FpdGluZyBmb3IgdGhlIHBtIGNvcmUKPiA+ ID4gICB0byBmaW5pc2ggdGhlIGF1dG9zdXNwZW5kIHJlcXVlc3Qgd2hpbGUgdGhlIHBtIGNvcmUg d2FpdHMgZm9yIHRoZQo+ID4gPiAgIG91dHB1dCBwb2xsIHRocmVhZCB0byBmaW5pc2gKPiA+IAo+ ID4gVGhlIGNvcnJlY3QgZml4IGlzIHRvIGNhbGwgcG1fcnVudGltZV9nZXRfc3luYygpICpjb25k aXRpb25hbGx5KiBpbgo+ID4gdGhlIGF0b21pYyBjb21taXQgd2hpY2ggZW5hYmxlcyB0aGUgZGlz cGxheSwgdXNpbmcgdGhlIHNhbWUgY29uZGl0aW9uYWwKPiA+IGFzIGQ2MWE1YzEwNjM1MSwgaS5l LiBpZiAoIWRybV9rbXNfaGVscGVyX2lzX3BvbGxfd29ya2VyKCkpLgoKRmlyc3Qgb2YgYWxsLCBJ IHdhcyBtaXN0YWtlbiB3aGVuIEkgd3JvdGUgYWJvdmUgdGhhdCBhIGNoZWNrIGZvcgohZHJtX2tt c19oZWxwZXJfaXNfcG9sbF93b3JrZXIoKSB3b3VsZCBzb2x2ZSB0aGUgcHJvYmxlbS4gIFNvcnJ5 IQpJdCBkb2Vzbid0IGJlY2F1c2UgdGhlIGNhbGwgdG8gcG1fcnVudGltZV9nZXRfc3luYygpIGlz IG5vdCBoYXBwZW5pbmcKaW4gb3V0cHV0X3BvbGxfZXhlY3V0ZSgpIGJ1dCBpbiBkcm1fZHBfbXN0 X2xpbmtfcHJvYmVfd29yaygpLgoKTG9va2luZyBvbmNlIG1vcmUgYXQgdGhlIHRocmVlIHN0YWNr IHRyYWNlcyB5b3UndmUgcHJvdmlkZWQsIHdlJ3ZlIGdvdDoKLSBvdXRwdXRfcG9sbF9leGVjdXRl KCkgc3R1Y2sgd2FpdGluZyBmb3IgZmJfaGVscGVyLT5sb2NrCiAgd2hpY2ggaXMgaGVsZCBieSBk cm1fZHBfbXN0X2xpbmtfcHJvYmVfd29yaygpCi0gcnBtX3N1c3BlbmQoKSBzdHVjayB3YWl0aW5n IGZvciBvdXRwdXRfcG9sbF9leGVjdXRlKCkgdG8gZmluaXNoCi0gZHJtX2RwX21zdF9saW5rX3By b2JlX3dvcmsoKSBzdHVjayB3YWl0aW5nIGluIHJwbV9yZXN1bWUoKQoKRm9yIHRoZSBtb21lbnQg d2UgY2FuIGlnbm9yZSB0aGUgZmlyc3QgdGFzaywgaS5lLiBvdXRwdXRfcG9sbF9leGVjdXRlKCks CmFuZCBmb2N1cyBvbiB0aGUgbGF0dGVyIHR3by4KCkFzIHNhaWQgSSdtIHVuZmFtaWxpYXIgd2l0 aCBNU1QgYnV0IGJyb3dzaW5nIHRocm91Z2ggZHJtX2RwX21zdF90b3BvbG9neS5jCkkgbm90aWNl IHRoYXQgZHJtX2RwX21zdF9saW5rX3Byb2JlX3dvcmsoKSBpcyB0aGUgLT53b3JrIGVsZW1lbnQg aW4KZHJtX2RwX21zdF90b3BvbG9neV9tZ3IoKSBhbmQgaXMgcXVldWVkIG9uIEhQRC4gIEkgZnVy dGhlciBub3RpY2UgdGhhdAp0aGUgd29yayBpdGVtIGlzIGZsdXNoZWQgb24gLT5ydW50aW1lX3N1 c3BlbmQ6Cgpub3V2ZWF1X3Btb3BzX3J1bnRpbWVfc3VzcGVuZCgpCiAgbm91dmVhdV9kb19zdXNw ZW5kKCkKICAgIG5vdXZlYXVfZGlzcGxheV9zdXNwZW5kKCkKICAgICAgbm91dmVhdV9kaXNwbGF5 X2ZpbmkoKQogICAgICAgIGRpc3AtPmZpbmkoKSA9PSBudjUwX2Rpc3BsYXlfZmluaSgpCgkgIG52 NTBfbXN0bV9maW5pKCkKCSAgICBkcm1fZHBfbXN0X3RvcG9sb2d5X21ncl9zdXNwZW5kKCkKCSAg ICAgIGZsdXNoX3dvcmsoJm1nci0+d29yayk7CgpBbmQgYmVmb3JlIHRoZSB3b3JrIGl0ZW0gaXMg Zmx1c2hlZCwgdGhlIEhQRCBzb3VyY2UgaXMgcXVpZXNjZWQuCgpTbyBpdCBsb29rcyBsaWtlIGRy bV9kcF9tc3RfbGlua19wcm9iZV93b3JrKCkgY2FuIG9ubHkgZXZlciBydW4Kd2hpbGUgdGhlIEdQ VSBpcyBydW50aW1lIHJlc3VtZWQsIGl0IG5ldmVyIHJ1bnMgd2hpbGUgdGhlIEdQVSBpcwpydW50 aW1lIHN1c3BlbmRlZC4gIFRoaXMgbWVhbnMgdGhhdCB5b3UgZG9uJ3QgaGF2ZSB0byBhY3F1aXJl IGFueQpydW50aW1lIFBNIHJlZmVyZW5jZXMgaW4gb3IgYmVsb3cgZHJtX2RwX21zdF9saW5rX3By b2JlX3dvcmsoKS4KQXUgY29udHJhaXJlLCB5b3UgbXVzdCBub3QgYWNxdWlyZSBhbnkgYmVjYXVz ZSBpdCB3aWxsIGRlYWRsb2NrIHdoaWxlCnRoZSBHUFUgaXMgcnVudGltZSBzdXNwZW5kaW5nLiAg SWYgdGhlcmUgYXJlIGZ1bmN0aW9ucyB3aGljaCBhcmUKY2FsbGVkIGZyb20gZHJtX2RwX21zdF9s aW5rX3Byb2JlX3dvcmsoKSBhcyB3ZWxsIGFzIGZyb20gb3RoZXIgY29udGV4dHMsCmFuZCB0aG9z ZSBvdGhlciBjb250ZXh0cyBuZWVkIGEgcnVudGltZSBQTSByZWYgdG8gYmUgYWNxdWlyZWQsCnlv dSBuZWVkIHRvIGFjcXVpcmUgdGhlIHJ1bnRpbWUgUE0gcmVmIGNvbmRpdGlvbmFsbHkgb24gbm90 IGJlaW5nCmRybV9kcF9tc3RfbGlua19wcm9iZV93b3JrKCkgKHVzaW5nIHRoZSBjdXJyZW50X3dv cmsoKSB0ZWNobmlxdWUpLgoKQWx0ZXJuYXRpdmVseSwgbW92ZSBhY3F1aXNpdGlvbiBvZiB0aGUg cnVudGltZSBQTSByZWYgZnVydGhlciB1cCBpbgp0aGUgY2FsbCBjaGFpbiB0byB0aG9zZSBvdGhl ciBjb250ZXh0cy4KCgo+IEFueXdheS10aGF0J3Mgd2h5IHlvdXIgZXhwbGFuYXRpb24gZG9lc24n dCBtYWtlIHNlbnNlOiB0aGUgZGVhZGxvY2sgaXMKPiBoYXBwZW5pbmcgYmVjYXVzZSB3ZSdyZSBj YWxsaW5nIHBtX3J1bnRpbWVfZ2V0X3N5bmMoKS4gSWYgd2Ugd2VyZSB0bwo+IG1ha2UgdGhhdCBj YWxsIGNvbmRpdGlvbmFsIChlLmcuIGRybV9rbXNfaGVscGVyX2lzX3BvbGxfd29ya2VyKCkpLAo+ IGFsbCB0aGF0IHdvdWxkIG1lYW4gaXMgdGhhdCB3ZSB3b3VsZG4ndCBncmFiIGFueSBydW50aW1l IHBvd2VyIHJlZmVyZW5jZQo+IGFuZCB0aGUgR1BVIHdvdWxkIGltbWVkaWF0ZWx5IHN1c3BlbmQg b25jZSB0aGUgYXRvbWljIGNvbW1pdCBmaW5pc2hlZCwKPiBhcyB0aGUgc3VzcGVuZCByZXF1ZXN0 IGluIFRocmVhZCA1IHdvdWxkIGZpbmFsbHkgZ2V0IHVuYmxvY2tlZCBhbmQgdGh1cwo+IC0tLS1z dXNwZW5kLgoKUmlnaHQsIHRoYXQgc2VlbXMgdG8gYmUgYSBidWcgbm91dmVhdV9wbW9wc19ydW50 aW1lX3N1c3BlbmQoKToKCklmIGEgZGlzcGxheSBpcyBwbHVnZ2VkIGluIHdoaWxlIHRoZSBHUFUg aXMgYWJvdXQgdG8gcnVudGltZSBzdXNwZW5kLAp0aGUgZGlzcGxheSBtYXkgYmUgbGl0IHVwIGJ5 IG91dHB1dF9wb2xsX2V4ZWN1dGUoKSBidXQgdGhlIEdQVSB3aWxsCnRoZW4gbmV2ZXJ0aGVsZXNz IGJlIHBvd2VyZWQgb2ZmLgoKSSBndWVzcyBhZnRlciBjYWxsaW5nIGRybV9rbXNfaGVscGVyX3Bv bGxfZGlzYWJsZSgpIHdlIHNob3VsZCByZS1jaGVjawppZiBhIGNydGMgaGFzIGJlZW4gYWN0aXZh dGVkLiAgVGhpcyBzaG91bGQgaGF2ZSBidW1wZWQgdGhlIHJ1bnRpbWUgUE0KcmVmY291bnQgYW5k IGhhdmVfZGlzcF9wb3dlcl9yZWYgc2hvdWxkIGJlIHRydWUuICBJbiB0aGF0IGNhc2UsIHRoZQpu b3V2ZWF1X3Btb3BzX3J1bnRpbWVfc3VzcGVuZCgpIHNob3VsZCByZXR1cm4gLUVCVVNZIHRvIGFi b3J0IHRoZQpydW50aW1lX3N1c3BlbmQuCgpUaGUgc2FtZSBjaGVjayBzZWVtcyBuZWNlc3Nhcnkg YWZ0ZXIgZmx1c2hpbmcgZHJtX2RwX21zdF9saW5rX3Byb2JlX3dvcmsoKToKSWYgdGhlIHdvcmsg aXRlbSBsaXQgdXAgYSBuZXcgZGlzcGxheSwgYWxsIHByZXZpb3VzIHN1c3BlbmQgc3RlcHMgbmVl ZAp0byBiZSB1bndvdW5kIGFuZCAtRUJVU1kgbmVlZHMgdG8gYmUgcmV0dXJuZWQgdG8gdGhlIFBN IGNvcmUuCgpDb21tdW5pY2F0aW9uIHdpdGggYW4gTVNUIGh1YiBleGNlZWRpbmcgdGhlIGF1dG9z dXNwZW5kIHRpbWVvdXQgaXMKanVzdCBvbmUgc2NlbmFyaW8gd2hlcmUgdGhpcyBidWcgbWFuaWZl c3RzIGl0c2VsZi4KCkJUVywgZHJtX2ttc19oZWxwZXJfcG9sbF9kaXNhYmxlKCkgc2VlbXMgdG8g YmUgY2FsbGVkIHR3aWNlIGluIHRoZQpydW50aW1lX3N1c3BlbmQgY29kZSBwYXRoLCBvbmNlIGlu IG5vdXZlYXVfcG1vcHNfcnVudGltZV9zdXNwZW5kKCkKYW5kIGEgc2Vjb25kIHRpbWUgaW4gbm91 dmVhdV9kaXNwbGF5X2ZpbmkoKS4KCkEgc3R1cGlkIHF1ZXN0aW9uLCBJIG5vdGljZSB0aGF0IG52 NTBfZGlzcGxheV9maW5pKCkgY2FsbHMgbnY1MF9tc3RtX2ZpbmkoKQpvbmx5IGlmIGVuY29kZXJf dHlwZSAhPSBEUk1fTU9ERV9FTkNPREVSX0RQTVNULiAgV2h5IGlzbid0IHRoYXQgPT0gPwoKVGhh bmtzLAoKTHVrYXMKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3Jn Cmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs Cg== 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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 66D40ECDE5F for ; Sat, 21 Jul 2018 09:40:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0A7A120856 for ; Sat, 21 Jul 2018 09:40:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A7A120856 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727549AbeGUKcG (ORCPT ); Sat, 21 Jul 2018 06:32:06 -0400 Received: from bmailout3.hostsharing.net ([176.9.242.62]:40683 "EHLO bmailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727140AbeGUKcG (ORCPT ); Sat, 21 Jul 2018 06:32:06 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id 7B6F6102C4C3D; Sat, 21 Jul 2018 11:39:56 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 0D9D46F3AA; Sat, 21 Jul 2018 11:39:55 +0200 (CEST) Date: Sat, 21 Jul 2018 11:39:55 +0200 From: Lukas Wunner To: Lyude Paul Cc: nouveau@lists.freedesktop.org, Gustavo Padovan , Maarten Lankhorst , Sean Paul , David Airlie , Ben Skeggs , Daniel Vetter , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] drm/fb_helper: Add drm_fb_helper_output_poll_changed_with_rpm() Message-ID: <20180721093955.GA32572@wunner.de> References: <20180718205645.25924-1-lyude@redhat.com> <20180718205645.25924-2-lyude@redhat.com> <20180719074926.GA14303@wunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 19, 2018 at 08:08:15PM -0400, Lyude Paul wrote: > On Thu, 2018-07-19 at 09:49 +0200, Lukas Wunner wrote: > > On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote: > > > When DP MST hubs get confused, they can occasionally stop responding for > > > a good bit of time up until the point where the DRM driver manages to > > > do the right DPCD accesses to get it to start responding again. In a > > > worst case scenario however, this process can take upwards of 10+ > > > seconds. > > > > > > Currently we use the default output_poll_changed handler > > > drm_fb_helper_output_poll_changed() to handle output polling, which > > > doesn't happen to grab any power references on the device when polling. > > > If we're unlucky enough to have a hub (such as Lenovo's infamous laptop > > > docks for the P5x/P7x series) that's easily startled and confused, this > > > can lead to a pretty nasty deadlock situation that looks like this: > > > > > > - Hotplug event from hub happens, we enter > > > drm_fb_helper_output_poll_changed() and start communicating with the > > > hub > > > - While we're in drm_fb_helper_output_poll_changed() and attempting to > > > communicate with the hub, we end up confusing it and cause it to stop > > > responding for at least 10 seconds > > > - After 5 seconds of being in drm_fb_helper_output_poll_changed(), the > > > pm core attempts to put the GPU into autosuspend, which ends up > > > calling drm_kms_helper_poll_disable() > > > - While the runtime PM core is waiting in drm_kms_helper_poll_disable() > > > for the output poll to finish, we end up finally detecting an MST > > > display > > > - We notice the new display and tries to enable it, which triggers > > > an atomic commit which triggers a call to pm_runtime_get_sync() > > > - the output poll thread deadlocks the pm core waiting for the pm core > > > to finish the autosuspend request while the pm core waits for the > > > output poll thread to finish > > > > The correct fix is to call pm_runtime_get_sync() *conditionally* in > > the atomic commit which enables the display, using the same conditional > > as d61a5c106351, i.e. if (!drm_kms_helper_is_poll_worker()). First of all, I was mistaken when I wrote above that a check for !drm_kms_helper_is_poll_worker() would solve the problem. Sorry! It doesn't because the call to pm_runtime_get_sync() is not happening in output_poll_execute() but in drm_dp_mst_link_probe_work(). Looking once more at the three stack traces you've provided, we've got: - output_poll_execute() stuck waiting for fb_helper->lock which is held by drm_dp_mst_link_probe_work() - rpm_suspend() stuck waiting for output_poll_execute() to finish - drm_dp_mst_link_probe_work() stuck waiting in rpm_resume() For the moment we can ignore the first task, i.e. output_poll_execute(), and focus on the latter two. As said I'm unfamiliar with MST but browsing through drm_dp_mst_topology.c I notice that drm_dp_mst_link_probe_work() is the ->work element in drm_dp_mst_topology_mgr() and is queued on HPD. I further notice that the work item is flushed on ->runtime_suspend: nouveau_pmops_runtime_suspend() nouveau_do_suspend() nouveau_display_suspend() nouveau_display_fini() disp->fini() == nv50_display_fini() nv50_mstm_fini() drm_dp_mst_topology_mgr_suspend() flush_work(&mgr->work); And before the work item is flushed, the HPD source is quiesced. So it looks like drm_dp_mst_link_probe_work() can only ever run while the GPU is runtime resumed, it never runs while the GPU is runtime suspended. This means that you don't have to acquire any runtime PM references in or below drm_dp_mst_link_probe_work(). Au contraire, you must not acquire any because it will deadlock while the GPU is runtime suspending. If there are functions which are called from drm_dp_mst_link_probe_work() as well as from other contexts, and those other contexts need a runtime PM ref to be acquired, you need to acquire the runtime PM ref conditionally on not being drm_dp_mst_link_probe_work() (using the current_work() technique). Alternatively, move acquisition of the runtime PM ref further up in the call chain to those other contexts. > Anyway-that's why your explanation doesn't make sense: the deadlock is > happening because we're calling pm_runtime_get_sync(). If we were to > make that call conditional (e.g. drm_kms_helper_is_poll_worker()), > all that would mean is that we wouldn't grab any runtime power reference > and the GPU would immediately suspend once the atomic commit finished, > as the suspend request in Thread 5 would finally get unblocked and thus > ----suspend. Right, that seems to be a bug nouveau_pmops_runtime_suspend(): If a display is plugged in while the GPU is about to runtime suspend, the display may be lit up by output_poll_execute() but the GPU will then nevertheless be powered off. I guess after calling drm_kms_helper_poll_disable() we should re-check if a crtc has been activated. This should have bumped the runtime PM refcount and have_disp_power_ref should be true. In that case, the nouveau_pmops_runtime_suspend() should return -EBUSY to abort the runtime_suspend. The same check seems necessary after flushing drm_dp_mst_link_probe_work(): If the work item lit up a new display, all previous suspend steps need to be unwound and -EBUSY needs to be returned to the PM core. Communication with an MST hub exceeding the autosuspend timeout is just one scenario where this bug manifests itself. BTW, drm_kms_helper_poll_disable() seems to be called twice in the runtime_suspend code path, once in nouveau_pmops_runtime_suspend() and a second time in nouveau_display_fini(). A stupid question, I notice that nv50_display_fini() calls nv50_mstm_fini() only if encoder_type != DRM_MODE_ENCODER_DPMST. Why isn't that == ? Thanks, Lukas