From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on Date: Fri, 25 Nov 2016 02:23:47 +0200 Message-ID: <1659700.XqUPVvtxXc@avalon> References: <1479775052-28194-1-git-send-email-john.stultz@linaro.org> <3450618.hbnl5lRf5h@avalon> <20161123075537.2wsk6hwdjntyrjl4@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from galahad.ideasonboard.com (galahad.ideasonboard.com [185.26.127.97]) by gabe.freedesktop.org (Postfix) with ESMTPS id 09BEE6E9F7 for ; Fri, 25 Nov 2016 00:23:26 +0000 (UTC) In-Reply-To: <20161123075537.2wsk6hwdjntyrjl4@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: Daniel Vetter , lkml , "dri-devel@lists.freedesktop.org" , Wolfram Sang List-Id: dri-devel@lists.freedesktop.org SGkgRGFuaWVsLAoKT24gV2VkbmVzZGF5IDIzIE5vdiAyMDE2IDA4OjU1OjM3IERhbmllbCBWZXR0 ZXIgd3JvdGU6Cj4gT24gVHVlLCBOb3YgMjIsIDIwMTYgYXQgMDg6MjM6MzhQTSArMDIwMCwgTGF1 cmVudCBQaW5jaGFydCB3cm90ZToKPiA+IE9uIFR1ZXNkYXkgMjIgTm92IDIwMTYgMTA6MDc6NTMg Sm9obiBTdHVsdHogd3JvdGU6Cj4gPj4gT24gVHVlLCBOb3YgMjIsIDIwMTYgYXQgOTozOCBBTSwg Sm9obiBTdHVsdHogd3JvdGU6Cj4gPj4+IEludGVyZXN0aW5nbHksIHdpdGhvdXQgdGhlIG1zbGVl cCBhZGRlZCBpbiB0aGlzIHBhdGNoLCByZW1vdmluZyB0aGUKPiA+Pj4gd2FpdF9ldmVudF9pbnRl cnJ1cHRpYmxlX3RpbWVvdXQoKSBtZXRob2QgaW4gYWR2NzUxMV93YWl0X2Zvcl9lZGlkKCkKPiA+ Pj4gYW5kIHVzaW5nIHRoZSBwb2xsaW5nIGxvb3Agc2VlbXMgdG8gbWFrZSB0aGluZ3MganVzdCBh cyByZWxpYWJsZS4gU28KPiA+Pj4gbWF5YmUgc29tZXRoaW5nIGlzIG9mZiB3aXRoIHRoZSBpcnEg aGFuZGxpbmcgaGVyZSBpbnN0ZWFkPwo+ID4+IAo+ID4+IEFoaGhoLi4gU28gSSB0aGluayB0aGUg dHJvdWJsZSBoZXJlIGlzIHRoZSB0aGF0IHdoZW4gd2UgZmFpbCB3YWl0aW5nCj4gPj4gZm9yIHRo ZSBpcnEsIHRoZSBiYWNrdHJhY2UgaXMgYXMgZm9sbG93czoKPiA+PiAKPiA+PiBbICAgIDguMzE4 NjU0XSBbPGZmZmZmZjgwMDgwODdjMjg+XSBkdW1wX2JhY2t0cmFjZSsweDAvMHgxYTAKPiA+PiBb ICAgIDguMzE4NjYxXSBbPGZmZmZmZjgwMDgwODdkZGM+XSBzaG93X3N0YWNrKzB4MTQvMHgyMAo+ ID4+IFsgICAgOC4zMTg2NzFdIFs8ZmZmZmZmODAwODQzNDRmMD5dIGR1bXBfc3RhY2srMHg5MC8w eGIwCj4gPj4gWyAgICA4LjMxODY4MF0gWzxmZmZmZmY4MDA4NTM0NjUwPl0gYWR2NzUxMV9nZXRf ZWRpZF9ibG9jaysweDJjOC8weDMyMAo+ID4+IFsgICAgOC4zMTg2ODddIFs8ZmZmZmZmODAwODUy MTRhOD5dIGRybV9kb19nZXRfZWRpZCsweDc4LzB4MjgwCj4gPj4gWyAgICA4LjMxODY5M10gWzxm ZmZmZmY4MDA4NTM0NzI4Pl0gYWR2NzUxMV9nZXRfbW9kZXMrMHg4MC8weGQ4Cj4gPj4gWyAgICA4 LjMxODcwMF0gWzxmZmZmZmY4MDA4NTM0Nzk0Pl0KPiA+PiBhZHY3NTExX2Nvbm5lY3Rvcl9nZXRf bW9kZXMrMHgxNC8weDIwCj4gPj4gWyAgICA4LjMxODcxMF0gWzxmZmZmZmY4MDA4NTAwYTU0Pl0K PiA+PiBkcm1faGVscGVyX3Byb2JlX3NpbmdsZV9jb25uZWN0b3JfbW9kZXMrMHgyYmMvMHg1MDAK PiA+PiBbICAgIDguMzE4NzE4XSBbPGZmZmZmZjgwMDg1MGU0MDA+XQo+ID4+IGRybV9mYl9oZWxw ZXJfaG90cGx1Z19ldmVudCsweDEzMC8weDE4OAo+ID4+IFsgICAgOC4zMTg3MjZdIFs8ZmZmZmZm ODAwODUwZWU2OD5dCj4gPj4gZHJtX2ZiZGV2X2NtYV9ob3RwbHVnX2V2ZW50KzB4MTAvMHgyMAo+ ID4+IFsgICAgOC4zMTg3MzNdIFs8ZmZmZmZmODAwODUzNTcxOD5dCj4gPj4ga2lyaW5fZmJkZXZf b3V0cHV0X3BvbGxfY2hhbmdlZCsweDIwLzB4NTgKPiA+PiBbICAgIDguMzE4NzQwXSBbPGZmZmZm ZjgwMDg1MDBjYzA+XQo+ID4+IGRybV9rbXNfaGVscGVyX2hvdHBsdWdfZXZlbnQrMHgyOC8weDM4 Cj4gPj4gWyAgICA4LjMxODc0OF0gWzxmZmZmZmY4MDA4NTAxMGQ4Pl0gZHJtX2hlbHBlcl9ocGRf aXJxX2V2ZW50KzB4MTM4LzB4MTgwCj4gPj4gWyAgICA4LjMxODc1NF0gWzxmZmZmZmY4MDA4NTMz ODUwPl0gYWR2NzUxMV9pcnFfcHJvY2VzcysweDc4LzB4ZDgKPiA+PiBbICAgIDguMzE4NzYxXSBb PGZmZmZmZjgwMDg1MzM4YzQ+XSBhZHY3NTExX2lycV9oYW5kbGVyKzB4MTQvMHgyOAo+ID4+IFsg ICAgOC4zMTg3NjldIFs8ZmZmZmZmODAwODEwMDA2MD5dIGlycV90aHJlYWRfZm4rMHgyOC8weDY4 Cj4gPj4gWyAgICA4LjMxODc3NV0gWzxmZmZmZmY4MDA4MTAwMzUwPl0gaXJxX3RocmVhZCsweDEy OC8weDFlOAo+ID4+IFsgICAgOC4zMTg3ODJdIFs8ZmZmZmZmODAwODBkMmU2OD5dIGt0aHJlYWQr MHhkMC8weGU4Cj4gPj4gWyAgICA4LjMxODc4OF0gWzxmZmZmZmY4MDA4MDgyZTgwPl0gcmV0X2Zy b21fZm9yaysweDEwLzB4NTAKPiA+PiAKPiA+PiBTbyB3ZSdyZSBhY3R1YWxseSBpbiBpcnEgaGFu ZGxpbmcgdGhlIGhvdHBsdWcgaW50ZXJydXB0LCB3aGljaCBpcyB3aHkKPiA+PiB3ZSBuZXZlciBn ZXQgdGhlIGlycSBub3RpZmljYXRpb24gd2hlbiB0aGUgZWRpZCBpcyByZWFkLgo+ID4+IAo+ID4+ IEkgc3VzcGVjdCB3ZSBuZWVkIHRvIHVzZSBhIHdvcmtxdWV1ZSB0byBkbyB0aGUgaG90cGx1ZyBo YW5kbGluZyBvdXQgb2YKPiA+PiBpcnEuCj4gPiAKPiA+IExvdmVseSA6LSkKPiA+IAo+ID4gUXVv dGluZyB0aGUgRFJNIGRvY3VtZW50YXRpb246Cj4gPiAKPiA+IC8qKgo+ID4gICogZHJtX2hlbHBl cl9ocGRfaXJxX2V2ZW50IC0gaG90cGx1ZyBwcm9jZXNzaW5nCj4gPiAgKiBAZGV2OiBkcm1fZGV2 aWNlCj4gPiAgKgo+ID4gICogRHJpdmVycyBjYW4gdXNlIHRoaXMgaGVscGVyIGZ1bmN0aW9uIHRv IHJ1biBhIGRldGVjdCBjeWNsZSBvbiBhbGwKPiA+IGNvbm5lY3RvcnMKPiA+ICAqIHdoaWNoIGhh dmUgdGhlIERSTV9DT05ORUNUT1JfUE9MTF9IUEQgZmxhZyBzZXQgaW4gdGhlaXIgJnBvbGxlZCBt ZW1iZXIuCj4gPiBBbGwKPiA+ICAqIG90aGVyIGNvbm5lY3RvcnMgYXJlIGlnbm9yZWQsIHdoaWNo IGlzIHVzZWZ1bCB0byBhdm9pZCByZXByb2JpbmcgZml4ZWQKPiA+ICAqIHBhbmVscy4KPiA+ICAq Cj4gPiAgKiBUaGlzIGhlbHBlciBmdW5jdGlvbiBpcyB1c2VmdWwgZm9yIGRyaXZlcnMgd2hpY2gg Y2FuJ3Qgb3IgZG9uJ3QgdHJhY2sKPiA+IGhvdHBsdWcKPiA+ICAqIGludGVycnVwdHMgZm9yIGVh Y2ggY29ubmVjdG9yLgo+ID4gICoKPiA+ICAqIERyaXZlcnMgd2hpY2ggc3VwcG9ydCBob3RwbHVn IGludGVycnVwdHMgZm9yIGVhY2ggY29ubmVjdG9yCj4gPiBpbmRpdmlkdWFsbHkgYW5kCj4gPiAg KiB3aGljaCBoYXZlIGEgbW9yZSBmaW5lLWdyYWluZWQgZGV0ZWN0IGxvZ2ljIHNob3VsZCBieXBh c3MgdGhpcyBjb2RlIGFuZAo+ID4gICogZGlyZWN0bHkgY2FsbCBkcm1fa21zX2hlbHBlcl9ob3Rw bHVnX2V2ZW50KCkgaW4gY2FzZSB0aGUgY29ubmVjdG9yCj4gPiBzdGF0ZQo+ID4gICogY2hhbmdl ZC4KPiA+ICAqCj4gPiAgKiBUaGlzIGZ1bmN0aW9uIG11c3QgYmUgY2FsbGVkIGZyb20gcHJvY2Vz cyBjb250ZXh0IHdpdGggbm8gbW9kZQo+ID4gICogc2V0dGluZyBsb2NrcyBoZWxkLgo+ID4gICoK PiA+ICAqIE5vdGUgdGhhdCBhIGNvbm5lY3RvciBjYW4gYmUgYm90aCBwb2xsZWQgYW5kIHByb2Jl ZCBmcm9tIHRoZSBob3RwbHVnCj4gPiBoYW5kbGVyLAo+ID4gICogaW4gY2FzZSB0aGUgaG90cGx1 ZyBpbnRlcnJ1cHQgaXMga25vd24gdG8gYmUgdW5yZWxpYWJsZS4KPiA+ICAqLwo+ID4gCj4gPiBT byBpdCBsb29rcyBsaWtlIHdlIHNob3VsZCB1c2UgZHJtX2ttc19oZWxwZXJfaG90cGx1Z19ldmVu dCgpIGluc3RlYWQuCj4gPiAKPiA+IC8qKgo+ID4gICogZHJtX2ttc19oZWxwZXJfaG90cGx1Z19l dmVudCAtIGZpcmUgb2ZmIEtNUyBob3RwbHVnIGV2ZW50cwo+ID4gICogQGRldjogZHJtX2Rldmlj ZSB3aG9zZSBjb25uZWN0b3Igc3RhdGUgY2hhbmdlZAo+ID4gICoKPiA+ICAqIFRoaXMgZnVuY3Rp b24gZmlyZXMgb2ZmIHRoZSB1ZXZlbnQgZm9yIHVzZXJzcGFjZSBhbmQgYWxzbyBjYWxscyB0aGUK PiA+ICAqIG91dHB1dF9wb2xsX2NoYW5nZWQgZnVuY3Rpb24sIHdoaWNoIGlzIG1vc3QgY29tbW9u bHkgdXNlZCB0byBpbmZvcm0gdGhlCj4gPiBmYmRldgo+ID4gICogZW11bGF0aW9uIGNvZGUgYW5k IGFsbG93IGl0IHRvIHVwZGF0ZSB0aGUgZmJjb24gb3V0cHV0IGNvbmZpZ3VyYXRpb24uCj4gPiAg Kgo+ID4gICogRHJpdmVycyBzaG91bGQgY2FsbCB0aGlzIGZyb20gdGhlaXIgaG90cGx1ZyBoYW5k bGluZyBjb2RlIHdoZW4gYSBjaGFuZ2UKPiA+IGlzCj4gPiAgKiBkZXRlY3RlZC4gTm90ZSB0aGF0 IHRoaXMgZnVuY3Rpb24gZG9lcyBub3QgZG8gYW55IG91dHB1dCBkZXRlY3Rpb24gb2YKPiA+IGl0 cwo+ID4gICogb3duLCBsaWtlIGRybV9oZWxwZXJfaHBkX2lycV9ldmVudCgpIGRvZXMgLSB0aGlz IGlzIGFzc3VtZWQgdG8gYmUgZG9uZQo+ID4gYnkgdGhlCj4gPiAgKiBkcml2ZXIgYWxyZWFkeS4K PiA+ICAqCj4gPiAgKiBUaGlzIGZ1bmN0aW9uIG11c3QgYmUgY2FsbGVkIGZyb20gcHJvY2VzcyBj b250ZXh0IHdpdGggbm8gbW9kZQo+ID4gICogc2V0dGluZyBsb2NrcyBoZWxkLgo+ID4gICovCj4g PiAKPiA+IFRoZSBmdW5jdGlvbiBzdWZmZXJzIGZyb20gdGhlIHNhbWUgcHJvYmxlbSB0aG91Z2gs IHRoYXQgaXQgbXVzdCBiZSBjYWxsZWQKPiA+IGZyb20gcHJvY2VzcyBjb250ZXh0Lgo+ID4gCj4g PiBEYW5pZWwsIHdoeSBkbyB3ZSBoYXZlIGFuIEFQSSB0aGUgaXMgY2xlYXJseSByZWxhdGVkIHRv IGludGVycnVwdCBoYW5kbGluZwo+ID4gYnV0IHJlcXVpcmVzIHRoZSBjYWxsZXIgdG8gaW1wbGVt ZW50IGEgd29ya3F1ZXVlID8KPiAKPiBCZWNhdXNlIGluIGdlbmVyYWwgeW91IG5lZWQgdGhhdCB3 b3JrcXVldWUgYW55d2F5LCBhbmQgdXAgdG8gbm93IHRoZXJlIHdhcwo+IG5vIGRyaXZlciBldmVy IHdobyBkaWRuJ3QgaGF2ZSBhIHdvcmstcXVldWUgYWxyZWFkeS4KCk5vbmUgb2YgdGhlIGJyaWRn ZSBkcml2ZXJzIGluIGRyaXZlcnMvZ3B1L2RybS9icmlkZ2UvIGhhdmUgd29ya3F1ZXVlcy4gVGhl eSAKY2FsbCB0aGUgSFBEIGhlbHBlcnMgZnJvbSBhIHRocmVhZGVkIGludGVycnVwdCBoYW5kbGVy IHRob3VnaC4gU2xlZXBpbmcgaW4gCnRoYXQgY29udGV4dCBpcyBmaW5lLCBjYWxsaW5nIGZ1bmN0 aW9ucyB0aGF0IG1pZ2h0IHJlbHkgb24gaW50ZXJydXB0cyBmcm9tIHRoZSAKc2FtZSBkZXZpY2Ug dG8gc2lnbmFsIGNvbXBsZXRpb24gKHN1Y2ggYXMgcmVhZGluZyBFRElEIHRocm91Z2ggLmdldF9t b2RlcygpKSAKaXNuJ3QuCgo+IE5lc3Rpbmcgd29ya3F1ZXVlcwo+IHdpdGhpbiB3b3JrcXVldWVz IHNlZW1lZCBiZXlvbmQgc2lsbHksIGhlbmNlIHdoeSBJIHJlbW92ZWQgdGhlbSBpbjoKPiAKPiBj b21taXQgNjk3ODdmN2RhNmIyYWRjNDA1NDM1N2E2NjFhYWExNzAxYTljYTc2Zgo+IEF1dGhvcjog RGFuaWVsIFZldHRlciA8ZGFuaWVsLnZldHRlckBmZndsbC5jaD4KPiBEYXRlOiAgIFR1ZSBPY3Qg MjMgMTg6MjM6MzQgMjAxMiArMDAwMAo+IAo+ICAgICBkcm06IHJ1biB0aGUgaHBkIGlycSBldmVu dCBjb2RlIGRpcmVjdGx5Cj4gCj4gSSBndWVzcyB3ZSBjb3VsZCB0YWxrIGFib3V0IHJlLWludHJv ZHVjaW5nIGEgd29yay1pdGVtIGJhc2VkIHZlcnNpb24gb2YKPiBkcm1faGVscGVyX2hwZF9pcnFf ZXZlbnQuIEJ1dCBmb3IgZHJtX2ttc19oZWxwZXJfaG90cGx1Z19ldmVudCBJIHRoaW5rIGl0Cj4g ZG9lc24ndCBtYWtlIHNlbnNlIC0gaWYgeW91IGNhbGwgdGhhdCB5b3UndmUgcHJvYmFibHkganVz dCBkb25lIGEgcGlsZSBvZgo+IGkyYyB0cmFuc2FjdGlvbnMsIGFuZCB0aG9zZSBjYW4gc2xlZXAu IElmIHlvdSBoYXZlbid0IGRvbmUgaTJjCj4gdHJhbnNhY3Rpb25zLCB0aGVuIGl0J3Mgbm90IGFu IGV4dGVybmFsIHBhbmVsLCBhbmQgd2h5IGV4YWN0bHkgYXJlIHlvdQo+IGhhbmRsaW5nIGhwZCBm b3IgdGhlbT8KCi0tIApSZWdhcmRzLAoKTGF1cmVudCBQaW5jaGFydAoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApk cmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Au b3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751506AbcKYAXe (ORCPT ); Thu, 24 Nov 2016 19:23:34 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:38087 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750696AbcKYAX0 (ORCPT ); Thu, 24 Nov 2016 19:23:26 -0500 From: Laurent Pinchart To: Daniel Vetter Cc: John Stultz , lkml , David Airlie , Archit Taneja , Wolfram Sang , Lars-Peter Clausen , "dri-devel@lists.freedesktop.org" , Daniel Vetter Subject: Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on Date: Fri, 25 Nov 2016 02:23:47 +0200 Message-ID: <1659700.XqUPVvtxXc@avalon> User-Agent: KMail/4.14.10 (Linux/4.8.6-gentoo; KDE/4.14.24; x86_64; ; ) In-Reply-To: <20161123075537.2wsk6hwdjntyrjl4@phenom.ffwll.local> References: <1479775052-28194-1-git-send-email-john.stultz@linaro.org> <3450618.hbnl5lRf5h@avalon> <20161123075537.2wsk6hwdjntyrjl4@phenom.ffwll.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, On Wednesday 23 Nov 2016 08:55:37 Daniel Vetter wrote: > On Tue, Nov 22, 2016 at 08:23:38PM +0200, Laurent Pinchart wrote: > > On Tuesday 22 Nov 2016 10:07:53 John Stultz wrote: > >> On Tue, Nov 22, 2016 at 9:38 AM, John Stultz wrote: > >>> Interestingly, without the msleep added in this patch, removing the > >>> wait_event_interruptible_timeout() method in adv7511_wait_for_edid() > >>> and using the polling loop seems to make things just as reliable. So > >>> maybe something is off with the irq handling here instead? > >> > >> Ahhhh.. So I think the trouble here is the that when we fail waiting > >> for the irq, the backtrace is as follows: > >> > >> [ 8.318654] [] dump_backtrace+0x0/0x1a0 > >> [ 8.318661] [] show_stack+0x14/0x20 > >> [ 8.318671] [] dump_stack+0x90/0xb0 > >> [ 8.318680] [] adv7511_get_edid_block+0x2c8/0x320 > >> [ 8.318687] [] drm_do_get_edid+0x78/0x280 > >> [ 8.318693] [] adv7511_get_modes+0x80/0xd8 > >> [ 8.318700] [] > >> adv7511_connector_get_modes+0x14/0x20 > >> [ 8.318710] [] > >> drm_helper_probe_single_connector_modes+0x2bc/0x500 > >> [ 8.318718] [] > >> drm_fb_helper_hotplug_event+0x130/0x188 > >> [ 8.318726] [] > >> drm_fbdev_cma_hotplug_event+0x10/0x20 > >> [ 8.318733] [] > >> kirin_fbdev_output_poll_changed+0x20/0x58 > >> [ 8.318740] [] > >> drm_kms_helper_hotplug_event+0x28/0x38 > >> [ 8.318748] [] drm_helper_hpd_irq_event+0x138/0x180 > >> [ 8.318754] [] adv7511_irq_process+0x78/0xd8 > >> [ 8.318761] [] adv7511_irq_handler+0x14/0x28 > >> [ 8.318769] [] irq_thread_fn+0x28/0x68 > >> [ 8.318775] [] irq_thread+0x128/0x1e8 > >> [ 8.318782] [] kthread+0xd0/0xe8 > >> [ 8.318788] [] ret_from_fork+0x10/0x50 > >> > >> So we're actually in irq handling the hotplug interrupt, which is why > >> we never get the irq notification when the edid is read. > >> > >> I suspect we need to use a workqueue to do the hotplug handling out of > >> irq. > > > > Lovely :-) > > > > Quoting the DRM documentation: > > > > /** > > * drm_helper_hpd_irq_event - hotplug processing > > * @dev: drm_device > > * > > * Drivers can use this helper function to run a detect cycle on all > > connectors > > * which have the DRM_CONNECTOR_POLL_HPD flag set in their &polled member. > > All > > * other connectors are ignored, which is useful to avoid reprobing fixed > > * panels. > > * > > * This helper function is useful for drivers which can't or don't track > > hotplug > > * interrupts for each connector. > > * > > * Drivers which support hotplug interrupts for each connector > > individually and > > * which have a more fine-grained detect logic should bypass this code and > > * directly call drm_kms_helper_hotplug_event() in case the connector > > state > > * changed. > > * > > * This function must be called from process context with no mode > > * setting locks held. > > * > > * Note that a connector can be both polled and probed from the hotplug > > handler, > > * in case the hotplug interrupt is known to be unreliable. > > */ > > > > So it looks like we should use drm_kms_helper_hotplug_event() instead. > > > > /** > > * drm_kms_helper_hotplug_event - fire off KMS hotplug events > > * @dev: drm_device whose connector state changed > > * > > * This function fires off the uevent for userspace and also calls the > > * output_poll_changed function, which is most commonly used to inform the > > fbdev > > * emulation code and allow it to update the fbcon output configuration. > > * > > * Drivers should call this from their hotplug handling code when a change > > is > > * detected. Note that this function does not do any output detection of > > its > > * own, like drm_helper_hpd_irq_event() does - this is assumed to be done > > by the > > * driver already. > > * > > * This function must be called from process context with no mode > > * setting locks held. > > */ > > > > The function suffers from the same problem though, that it must be called > > from process context. > > > > Daniel, why do we have an API the is clearly related to interrupt handling > > but requires the caller to implement a workqueue ? > > Because in general you need that workqueue anyway, and up to now there was > no driver ever who didn't have a work-queue already. None of the bridge drivers in drivers/gpu/drm/bridge/ have workqueues. They call the HPD helpers from a threaded interrupt handler though. Sleeping in that context is fine, calling functions that might rely on interrupts from the same device to signal completion (such as reading EDID through .get_modes()) isn't. > Nesting workqueues > within workqueues seemed beyond silly, hence why I removed them in: > > commit 69787f7da6b2adc4054357a661aaa1701a9ca76f > Author: Daniel Vetter > Date: Tue Oct 23 18:23:34 2012 +0000 > > drm: run the hpd irq event code directly > > I guess we could talk about re-introducing a work-item based version of > drm_helper_hpd_irq_event. But for drm_kms_helper_hotplug_event I think it > doesn't make sense - if you call that you've probably just done a pile of > i2c transactions, and those can sleep. If you haven't done i2c > transactions, then it's not an external panel, and why exactly are you > handling hpd for them? -- Regards, Laurent Pinchart