From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST Date: Wed, 4 Apr 2018 22:31:26 +0300 Message-ID: <20180404193126.GH5453@intel.com> References: <20180402212142.19841-1-lyude@redhat.com> <20180402212617.21247-1-lyude@redhat.com> <20180404153429.GE5453@intel.com> <1522867061.12403.6.camel@redhat.com> <20180404185313.GG5453@intel.com> <1522868349.12403.12.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <1522868349.12403.12.camel@redhat.com> 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: dri-devel@lists.freedesktop.org, David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, Dhinakaran Pandiyan , Rodrigo Vivi , stable@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBBcHIgMDQsIDIwMTggYXQgMDI6NTk6MDlQTSAtMDQwMCwgTHl1ZGUgUGF1bCB3cm90 ZToKPiBPbiBXZWQsIDIwMTgtMDQtMDQgYXQgMjE6NTMgKzAzMDAsIFZpbGxlIFN5cmrDpGzDpCB3 cm90ZToKPiA+IE9uIFdlZCwgQXByIDA0LCAyMDE4IGF0IDAyOjM3OjQxUE0gLTA0MDAsIEx5dWRl IFBhdWwgd3JvdGU6Cj4gPiA+IE9uIFdlZCwgMjAxOC0wNC0wNCBhdCAxODozNCArMDMwMCwgVmls bGUgU3lyasOkbMOkIHdyb3RlOgo+ID4gPiA+IE9uIE1vbiwgQXByIDAyLCAyMDE4IGF0IDA1OjI2 OjE2UE0gLTA0MDAsIEx5dWRlIFBhdWwgd3JvdGU6Cj4gPiA+ID4gPiBXaGlsZSBlbmFibGluZy9k aXNhYmxpbmcgRFBNUyBiZWZvcmUgbGluayB0cmFpbmluZyB3aXRoIE1TVCBodWJzIGlzCj4gPiA+ ID4gPiBwZXJmZWN0bHkgdmFsaWQ7IHVuZm9ydHVuYXRlbHkgZGlzYWJsaW5nIERQTVMgcmVzdWx0 cyBpbiBzb21lIGRldmljZXMKPiA+ID4gPiA+IGRpc2FibGluZyB0aGVpciBBVVggQ0ggYmxvY2sg YXMgd2VsbC4gRm9yIFNTVCB0aGlzIGlzbid0IGFzIG11Y2ggb2YgYQo+ID4gPiA+ID4gcHJvYmxl bSwgYnV0IGZvciBNU1Qgd2UgbmVlZCB0byBiZSBhYmxlIHRvIGNvbnRpbnVlIGhhbmRsaW5nIGF1 eAo+ID4gPiA+ID4gdHJhbnNhY3Rpb25zIGV2ZW4gd2hlbiBub25lIG9mIHRoZSBzaW5rcyBhcmUg dHVybmVkIG9uIHNpbmNlIGl0J3MKPiA+ID4gPiA+IHBvc3NpYmxlIGZvciB1cyB0byBoYXZlIGEg c2luZ2xlIGF0b21pYyBjb21taXQgd2hpY2ggcmVzdWx0cyBpbgo+ID4gPiA+ID4gZGlzYWJsaW5n IGVhY2ggZG93bnN0cmVhbSBzaW5rLCBmb2xsb3dlZCBieSBzdWJzZXF1ZW50bHkgcmUtZW5hYmxp bmcKPiA+ID4gPiA+IGVhY2ggc2luay4KPiA+ID4gPiA+IAo+ID4gPiA+ID4gSWYgd2UgZG9uJ3Qg ZG8gdGhpcywgd2UnbGwgZW5kIHVwIHN0YWxsaW5nIGFueSBwZW5kaW5nIEVTSSBpbnRlcnJ1cHRz Cj4gPiA+ID4gPiBmcm9tIHRoZSBzaW5rIGZvciB1cCB0byAxbXMuIFVuZm9ydHVuYXRlbHksIGRy b3BwaW5nIEVTSXMgZHVyaW5nIHRoaXMKPiA+ID4gPiA+IHRpbWVzcGFuIG1ha2VzIGl0IHNvIHRo YXQgbGluayBmYWxsYmFjayByZXRyYWluaW5nIGZvciBNU1QgKHdoaWNoIEkKPiA+ID4gPiA+IHdp bGwKPiA+ID4gPiA+IGJlIHN1Ym1pdHRpbmcgdG8gdGhlIE1MIHNob3J0bHkpIGZhaWxzIGR1ZSB0 byB0aGUgY2hhbm5lbCBFUSBmYWlsdXJlCj4gPiA+ID4gPiBpbnRlcnJ1cHRzIHBvdGVudGlhbGx5 IGdldHRpbmcgZHJvcHBlZC4gQWRkaXRpb25hbGx5LCB3aGVuIHBlcmZvcm1pbmcKPiA+ID4gPiA+ IGEKPiA+ID4gPiA+IG1vZGVzZXQgdGhhdCBicmluZ3MgdGhlIGh1YiBzdGF0dXMncyBsaW5rIHN0 YXR1cyBmcm9tIGJhZCAtPiBnb29kCj4gPiA+ID4gPiBoYXZpbmcKPiA+ID4gPiA+IEVTSXMgZGlz YWJsZWQgZm9yIHRoYXQgbG9uZyBjYXVzZXMgdXMgdG8gbWlzcyB0aGUgaHViJ3MgcmVzcG9uc2Ug dG8gdXMKPiA+ID4gPiA+IHRyeWluZyB0byBzdGFydCBsaW5rIHRyYWluaW5nIGFzIHdlbGwuCj4g PiA+ID4gPiAKPiA+ID4gPiA+IFNpbmNlIGFueSBzaW5rIHdpdGggTVNUIGlzIGdvaW5nIHRvIHN1 cHBvcnQgRGlzcGxheVBvcnQgMS4yIGFueXdheSwKPiA+ID4gPiA+IHNhdmUKPiA+ID4gPiA+IHVz IHRoZSBoYXNzbGUgb2YgdHJ5aW5nIHRvIHdhaXQgdW50aWwgdGhlIHNpbmsgY29tZXMgYmFjayB1 cCBhbmQganVzdAo+ID4gPiA+ID4gbmV2ZXIgc2h1dCB0aGUgYXV4IGJsb2NrIGRvd24uCj4gPiA+ ID4gPiAKPiA+ID4gPiA+IENoYW5nZXMgc2luY2UgdjI6Cj4gPiA+ID4gPiAgLSBGaXggcGF0Y2gg bmFtZSwgbm8gZnVuY3Rpb25hbCBjaGFuZ2VzCj4gPiA+ID4gPiAKPiA+ID4gPiA+IFNpZ25lZC1v ZmYtYnk6IEx5dWRlIFBhdWwgPGx5dWRlQHJlZGhhdC5jb20+Cj4gPiA+ID4gPiBDYzogTGF1cmEg QWJib3R0IDxsYWJib3R0QHJlZGhhdC5jb20+Cj4gPiA+ID4gPiBDYzogRGhpbmFrYXJhbiBQYW5k aXlhbiA8ZGhpbmFrYXJhbi5wYW5kaXlhbkBpbnRlbC5jb20+Cj4gPiA+ID4gPiBDYzogVmlsbGUg U3lyasOkbMOkIDx2aWxsZS5zeXJqYWxhQGxpbnV4LmludGVsLmNvbT4KPiA+ID4gPiA+IENjOiBz dGFibGVAdmdlci5rZXJuZWwub3JnCj4gPiA+ID4gPiBGaXhlczogYWQyNjBhYjMyYTRkOSAoImRy bS9pOTE1L2RwOiBXcml0ZSB0byBTRVRfUE9XRVIgZHBjZCB0byBlbmFibGUKPiA+ID4gPiA+IE1T VAo+ID4gPiA+ID4gaHViLiIpCj4gPiA+ID4gPiAtLS0KPiA+ID4gPiA+ICBkcml2ZXJzL2dwdS9k cm0vaTkxNS9pbnRlbF9kcC5jIHwgNiArKysrLS0KPiA+ID4gPiA+ICAxIGZpbGUgY2hhbmdlZCwg NCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQo+ID4gPiA+ID4gCj4gPiA+ID4gPiBkaWZm IC0tZ2l0IGEvZHJpdmVycy9ncHUvZHJtL2k5MTUvaW50ZWxfZHAuYwo+ID4gPiA+ID4gYi9kcml2 ZXJzL2dwdS9kcm0vaTkxNS9pbnRlbF9kcC5jCj4gPiA+ID4gPiBpbmRleCA2MmY4MmM0Mjk4YWMu LjA0NzljMzc3OTgxYiAxMDA2NDQKPiA+ID4gPiA+IC0tLSBhL2RyaXZlcnMvZ3B1L2RybS9pOTE1 L2ludGVsX2RwLmMKPiA+ID4gPiA+ICsrKyBiL2RyaXZlcnMvZ3B1L2RybS9pOTE1L2ludGVsX2Rw LmMKPiA+ID4gPiA+IEBAIC0yNTg5LDExICsyNTg5LDEzIEBAIHZvaWQgaW50ZWxfZHBfc2lua19k cG1zKHN0cnVjdCBpbnRlbF9kcAo+ID4gPiA+ID4gKmludGVsX2RwLAo+ID4gPiA+ID4gaW50IG1v ZGUpCj4gPiA+ID4gPiAgCQlyZXR1cm47Cj4gPiA+ID4gPiAgCj4gPiA+ID4gPiAgCWlmIChtb2Rl ICE9IERSTV9NT0RFX0RQTVNfT04pIHsKPiA+ID4gPiA+ICsJCXVuc2lnbmVkIGNoYXIgZGF0YSA9 IGludGVsX2RwLT5pc19tc3QgPwo+ID4gPiA+ID4gKwkJCURQX1NFVF9QT1dFUl9EM19BVVhfT04g OiBEUF9TRVRfUE9XRVJfRDM7Cj4gPiA+ID4gCj4gPiA+ID4gVGhpcyBzbWVsbHMgbGlrZSBhIHdv cmthcm91bmQgZm9yIGFuIGFjdHVhbCBidWcgc29tZXdoZXJlLiBXaHkgZXhhY3RseQo+ID4gPiA+ IGlzIHRoZSBzbG93ZXIgd2FrZXVwIG9yIHRoZSBBVVggYmxvY2sgYSBwcm9ibGVtIGZvciBNU1Qg YnV0IG5vdCBmb3IgU1NUCj4gPiA+ID4gd2hlbiB0aGUgbGluayB0cmFpbmluZyBpcyBleGFjdGx5 IHRoZSBzYW1lIGZvciBTU1QgYW5kIE1TVD8KPiA+ID4gCj4gPiA+IEkgYWN0dWFsbHkgdGhvdWdo dCBhYm91dCB0aGlzIGJ1dCBJIHN0aWxsIHRoaW5rIHRoaXMgaXMgdGhlIGFwcHJvcHJpYXRlCj4g PiA+IGZpeC4KPiA+ID4gU287IHRoZSByZWFsIHJlYXNvbiBmb3IgdGhlIHdha2V1cCBub3QgYmVp bmcgYSBwcm9ibGVtIHdpdGggU1NUIGlzIHRoYXQKPiA+ID4gZm9yCj4gPiA+IERQTVMgb24gd2l0 aCBTU1QsIHdlIGFjdHVhbGx5IGRvIGEgd2FpdCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgaHViIGlz IHJlYWR5Cj4gPiA+IGJlZm9yZSBjb250aW51aW5nLiBBbmQgeWVzOiBJJ20gZmFpcmx5IHN1cmUg U1NUIGRvZXMgYWN0dWFsbHkgaGF2ZSBhcm91bmQKPiA+ID4gdGhlCj4gPiA+IHNhbWUgd2FrZXVw IHRpbWUgdGhhdCBNU1QgZG9lcywgYnV0IHdpdGggdGhlIHdhaXQgd2UgZG8gaXQgZG9lc24ndCBy ZWFsbGh5Cj4gPiA+IG1ha2UgYSBkaWZmZXJlbmNlLiBXaXRoIE1TVCwgd2UgY291bGQgZG8gdGhp cyBidXQgdGhlcmUncyBhIGZldyByZWFzb25zIEkKPiA+ID4gZG9uJ3QgdGhpbmsgd2Ugc2hvdWxk Ogo+ID4gPiAgKiBXZSBkb24ndCBuZWVkIHRvLiBEM19BVVhfT04gaXMgYSBwYXJ0IG9mIHRoZSAx LjIgc3BlYywgc28gYW55IGh1YiB0aGF0Cj4gPiA+IGhhcwo+ID4gPiAgICBNU1QgaXMgZ29pbmcg dG8gYmUgZ3VhcmFudGVlZCB0byBoYXZlIHRoaXMuCj4gPiA+ICAqIFR1cm5pbmcgb2ZmIHRoZSBh dXggYmxvY2sgbWVhbnMgdGhhdCB0aGVyZSdzIGEgaGlnaCBjaGFuY2Ugd2UncmUgZ29pbmcKPiA+ ID4gdG8KPiA+ID4gICAgbWlzcyBFU0lzIGZyb20gc2lua3MKPiA+IAo+ID4gQW5kIGhvdyBleGFj dGx5IGRvIHdlIGxvc2UgaXJxcz8gVGhlIGh1Yi93aGF0ZXZlciB0aHJvd3MgdGhlIHVwIHJlcSBt c2dzCj4gPiBhd2F5IGlmIHdlIGRvbid0IHJlYWQgdGhlbSB3aXRoaW4gc29tZSByZWFsbHkgc2hv cnQgdGltZT8KPiBUaGF0J3MgbXkgaHlwb3RoZXNpcyBhdCBsZWFzdC4gSSdtIGJldHRpbmcgdGhh dCBvbiB0aGUgZmFjdCB0aGF0IHdoZW4gSSB3YXMKPiBpbXBsZW1lbnRpbmcgTVNUIHJldHJhaW5p bmcgYmVmb3JlIHdlIHB1dCB0aGUgaW50ZWxfZHBfY2hlY2tfbXN0X3N0YXR1cygpIChvcgo+IHdo YXRldmVyIGl0J3MgY2FsbGVkKSBpbnRvIHRoZSBkaWcgd29ya3F1ZXVlLCBnZXR0aW5nIHRoZSBz aW5rIHRvIGdvIGRvd24gYW5kCj4gY29tZSBiYWNrIHVwIHdhcyBhIGxvdCBtb3JlIHVucmVsaWFi bGUgd2hlbmV2ZXIgSSBpbnRyb2R1Y2VkIGFueXRoaW5nIHRoYXQKPiB3b3VsZCBibG9jayB0aGUg ZXNpIGhhbmRsZXIgZm9yIGxvbmdlciB0aGVuIGEgdmVyeSBicmllZiBwZXJpb2Qgb2YgdGltZSAo c2F5LAo+IDUwLTEwMG1zPykuIEkndmUgc2VlbiBzb21lIG5vdGVzIGVsc2V3aGVyZSB0b28gdGhh dCBzZWVtZWQgdG8gaW1wbHkgZm9yIFNTVCwKPiB0aGluZ3Mgd2VyZSBwcmV0dHkgc2Vuc2l0aXZl IHRvIGlycSBsYXRlbmN5IChsaW5lIDEwNTAsIGludGVsX2RwLmMpIHNvIGl0Cj4gd291bGRuJ3Qg YmUgdGVycmlibHkgc3VycHJpc2luZyBpZiBpdCdzIHRoZSBzYW1lIGZvciBNU1QuIEF0IHRoZSB2 ZXJ5IGxlYXN0LAo+IG5vdyB0aGF0IHdlJ3ZlIGdvdCB0aGUgRVNJIGhhbmRsZXIgcnVubmluZyBp biB0aGUgZGlnIHdvcmtlciB0aGluZ3Mgc2VlbSB0bwo+IGhhdmUgZ290dGVuIGEgL2xvdC8gbW9y ZSByZWxpYWJsZSBub3cgdGhhdCB3ZSBjYW4gYmFzaWNhbGx5IGdvIHRoZSB3aG9sZQo+IG1vZGVz ZXQgd2l0aG91dCBibG9ja2luZyB0aGUgRVNJIGhhbmRsZXIgZm9yIHZlcnkgbG9uZy4KCkhtbS4g T0ssIHNvIHRoZSBzcGVjIHNlZW1zIHRvIGJlIHNheWluZyB0aGF0IHdlIGhhdmUgMTAwbXMgdG8g cmVhZAp0aGUgVVBfUkVRL0RPV05fUkVQTFkgbXNnIGFmdGVyIHRoZSBJUlFfSFBELiBUaGF0J3Mg c3RpbGwgYSBsb3QgbW9yZQp0aGFuIHRoZSAxbXMgbWF4IGFsbG93ZWQgd2FrZXVwIHRpbWUuIExv b2tzIGxpa2UgdGhlcmUncyBhIGV4dGVuZGVkCndha2V1cCB0aW1lIHJlcXVlc3QvZ3JhbnQgbWVj aGFuaXNtIG5vdywgYnV0IHdpdGhvdXQgdGhlIGV4cGxpY2l0CmdyYW50ICh3aGljaCB3ZSBkb24n dCBkbykgdGhlIDFtcyBzdGlsbCBob2xkcy4KCj4gPiAKPiA+ID4gICogSXQncyBmYXN0ZXIgdG8g a2VlcCB0aGUgYXV4IGJsb2NrIG9uIGFueXdheQo+ID4gPiAKPiA+ID4gCj4gPiA+ID4gCj4gPiA+ ID4gPiArCj4gPiA+ID4gPiAgCQlpZiAoZG93bnN0cmVhbV9ocGRfbmVlZHNfZDAoaW50ZWxfZHAp KQo+ID4gPiA+ID4gIAkJCXJldHVybjsKPiA+ID4gPiA+ICAKPiA+ID4gPiA+IC0JCXJldCA9IGRy bV9kcF9kcGNkX3dyaXRlYigmaW50ZWxfZHAtPmF1eCwKPiA+ID4gPiA+IERQX1NFVF9QT1dFUiwK PiA+ID4gPiA+IC0JCQkJCSBEUF9TRVRfUE9XRVJfRDMpOwo+ID4gPiA+ID4gKwkJcmV0ID0gZHJt X2RwX2RwY2Rfd3JpdGViKCZpbnRlbF9kcC0+YXV4LAo+ID4gPiA+ID4gRFBfU0VUX1BPV0VSLAo+ ID4gPiA+ID4gZGF0YSk7Cj4gPiA+ID4gPiAgCX0gZWxzZSB7Cj4gPiA+ID4gPiAgCQlzdHJ1Y3Qg aW50ZWxfbHNwY29uICpsc3Bjb24gPSBkcF90b19sc3Bjb24oaW50ZWxfZHApOwo+ID4gPiA+ID4g IAo+ID4gPiA+ID4gLS0gCj4gPiA+ID4gPiAyLjE0LjMKPiA+ID4gPiAKPiA+ID4gPiAKPiA+ID4g Cj4gPiA+IC0tIAo+ID4gPiBDaGVlcnMsCj4gPiA+IAlMeXVkZSBQYXVsCj4gPiAKPiA+IAo+IC0t IAo+IENoZWVycywKPiAJTHl1ZGUgUGF1bAoKLS0gClZpbGxlIFN5cmrDpGzDpApJbnRlbCBPVEMK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-831531-1522870330-2-15617948709960984444 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.249, ME_NOAUTH 0.01, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='com', MailFrom='org' X-Spam-charsets: from='iso-8859-1', plain='iso-8859-1' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: stable-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=fm2; t= 1522870329; b=PO3I0rEaw5ksm1GvxEMMT9cu4QioDwXPUir48gzd9vOGNxpax8 ZbOWLof5kIEaKr+VdJEiiOewpXcM4UEzYSK0QwVHtYdvXVYP1CgP+loINq60YCb0 zlAQG+r4PHAS00c3UKomGh/oLkfmaDN04Y5AEb1qkjw2v8agI00S/1QLAF0RtPDE Q+9pujq/FYd1g9098zysJEnfn4loIFQtkBwMUb6Cxwp7ehvnjw8U5+UIEkB9R2OF zR80ipqTVSpL6K5z3hTgSChK5WNEMwnbp4r7fpD7DbhePgGSuWV62HV6K6+tO3VY WqPEpWAqrb/LtdDm3PoEKTIBxDJNSLUDktLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:content-transfer-encoding :in-reply-to:sender:list-id; s=fm2; t=1522870329; bh=hb0lr/eaXEf ojnHBmNt0eCvlUaD1VMQplTLQ5joekk4=; b=ESZaercM4ly1s0TDxdRFhvMR/6h 6QdTrVhk4KgGQJnjPoAQ+e3omkkDJ+S3ECqhpScR6tE34DF+a3WZncZZAmAi1Y/1 xq4PNTdqj12eOAMhSK/u6HLr8G90TRtZ5M3BHUbLj/wuabuJD+sMMfX2vwo/gDMa CSJe9Dmly3gGCwLYnavUFlRUuTtM4JFALzPN78t2EFeiS1jXx4QcvB0WPro2NkU9 ICZCuLjROAI0BvtIcYWx/YPUp0X1eZoxWnq6j9iQq3b7MqLdUv9XaFJ5chdz0WHZ fkJshZSoouLwRPvPwv89MPfTSc4yVtx4UXQGuPw0UXgIJLu8r1fsvj14zGA== ARC-Authentication-Results: i=1; mx4.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=linux.intel.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-cm=none score=0; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=linux.intel.com header.result=pass header_org.domain=intel.com header_org.result=pass header_is_org_domain=no; x-vs=clean score=-100 state=0 Authentication-Results: mx4.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=linux.intel.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-cm=none score=0; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=linux.intel.com header.result=pass header_org.domain=intel.com header_org.result=pass header_is_org_domain=no; x-vs=clean score=-100 state=0 X-ME-VSCategory: clean X-CM-Envelope: MS4wfBm1ErWWTu6iI/nA5shvcHey3gVwUX0ooZQCN7HjKqMb7FBelHd0WiqhkLgjPnH8zDEOpn0iuhWbZyMWex/ArDfSW4HabwPMbAejHccYgO9W6cjjLYLx MoSeYn6a7aIAnHHGGJaYcg33nIbm+cAPmVNfl1OWIyq4IsZyacwTunz2fn3VHpft1pL8IWTCq3uAWOhEuk0QlaBVwtW1CjLiWKBo9xhe/NvkMgp7QzdQ/joZ X-CM-Analysis: v=2.3 cv=JLoVTfCb c=1 sm=1 tr=0 a=UK1r566ZdBxH71SXbqIOeA==:117 a=UK1r566ZdBxH71SXbqIOeA==:17 a=8nJEP1OIZ-IA:10 a=Kd1tUaAdevIA:10 a=20KFwNOVAAAA:8 a=QyXUC8HyAAAA:8 a=VwQbUJbxAAAA:8 a=z3vVis7cH64Y3roKpigA:9 a=wPNLvfGTeEIA:10 a=AjGcO6oz07-iQ99wixmX:22 X-ME-CMScore: 0 X-ME-CMCategory: none Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752491AbeDDTbe (ORCPT ); Wed, 4 Apr 2018 15:31:34 -0400 Received: from mga12.intel.com ([192.55.52.136]:58379 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752469AbeDDTbc (ORCPT ); Wed, 4 Apr 2018 15:31:32 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,407,1517904000"; d="scan'208";a="31580458" Date: Wed, 4 Apr 2018 22:31:26 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Lyude Paul Cc: intel-gfx@lists.freedesktop.org, Laura Abbott , Dhinakaran Pandiyan , stable@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST Message-ID: <20180404193126.GH5453@intel.com> References: <20180402212142.19841-1-lyude@redhat.com> <20180402212617.21247-1-lyude@redhat.com> <20180404153429.GE5453@intel.com> <1522867061.12403.6.camel@redhat.com> <20180404185313.GG5453@intel.com> <1522868349.12403.12.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1522868349.12403.12.camel@redhat.com> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: stable-owner@vger.kernel.org X-Mailing-List: stable@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Wed, Apr 04, 2018 at 02:59:09PM -0400, Lyude Paul wrote: > On Wed, 2018-04-04 at 21:53 +0300, Ville Syrjälä wrote: > > On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote: > > > On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote: > > > > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote: > > > > > While enabling/disabling DPMS before link training with MST hubs is > > > > > perfectly valid; unfortunately disabling DPMS results in some devices > > > > > disabling their AUX CH block as well. For SST this isn't as much of a > > > > > problem, but for MST we need to be able to continue handling aux > > > > > transactions even when none of the sinks are turned on since it's > > > > > possible for us to have a single atomic commit which results in > > > > > disabling each downstream sink, followed by subsequently re-enabling > > > > > each sink. > > > > > > > > > > If we don't do this, we'll end up stalling any pending ESI interrupts > > > > > from the sink for up to 1ms. Unfortunately, dropping ESIs during this > > > > > timespan makes it so that link fallback retraining for MST (which I > > > > > will > > > > > be submitting to the ML shortly) fails due to the channel EQ failure > > > > > interrupts potentially getting dropped. Additionally, when performing > > > > > a > > > > > modeset that brings the hub status's link status from bad -> good > > > > > having > > > > > ESIs disabled for that long causes us to miss the hub's response to us > > > > > trying to start link training as well. > > > > > > > > > > Since any sink with MST is going to support DisplayPort 1.2 anyway, > > > > > save > > > > > us the hassle of trying to wait until the sink comes back up and just > > > > > never shut the aux block down. > > > > > > > > > > Changes since v2: > > > > > - Fix patch name, no functional changes > > > > > > > > > > Signed-off-by: Lyude Paul > > > > > Cc: Laura Abbott > > > > > Cc: Dhinakaran Pandiyan > > > > > Cc: Ville Syrjälä > > > > > Cc: stable@vger.kernel.org > > > > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable > > > > > MST > > > > > hub.") > > > > > --- > > > > > drivers/gpu/drm/i915/intel_dp.c | 6 ++++-- > > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > > > b/drivers/gpu/drm/i915/intel_dp.c > > > > > index 62f82c4298ac..0479c377981b 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp > > > > > *intel_dp, > > > > > int mode) > > > > > return; > > > > > > > > > > if (mode != DRM_MODE_DPMS_ON) { > > > > > + unsigned char data = intel_dp->is_mst ? > > > > > + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3; > > > > > > > > This smells like a workaround for an actual bug somewhere. Why exactly > > > > is the slower wakeup or the AUX block a problem for MST but not for SST > > > > when the link training is exactly the same for SST and MST? > > > > > > I actually thought about this but I still think this is the appropriate > > > fix. > > > So; the real reason for the wakeup not being a problem with SST is that > > > for > > > DPMS on with SST, we actually do a wait to make sure that the hub is ready > > > before continuing. And yes: I'm fairly sure SST does actually have around > > > the > > > same wakeup time that MST does, but with the wait we do it doesn't reallhy > > > make a difference. With MST, we could do this but there's a few reasons I > > > don't think we should: > > > * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub that > > > has > > > MST is going to be guaranteed to have this. > > > * Turning off the aux block means that there's a high chance we're going > > > to > > > miss ESIs from sinks > > > > And how exactly do we lose irqs? The hub/whatever throws the up req msgs > > away if we don't read them within some really short time? > That's my hypothesis at least. I'm betting that on the fact that when I was > implementing MST retraining before we put the intel_dp_check_mst_status() (or > whatever it's called) into the dig workqueue, getting the sink to go down and > come back up was a lot more unreliable whenever I introduced anything that > would block the esi handler for longer then a very brief period of time (say, > 50-100ms?). I've seen some notes elsewhere too that seemed to imply for SST, > things were pretty sensitive to irq latency (line 1050, intel_dp.c) so it > wouldn't be terribly surprising if it's the same for MST. At the very least, > now that we've got the ESI handler running in the dig worker things seem to > have gotten a /lot/ more reliable now that we can basically go the whole > modeset without blocking the ESI handler for very long. Hmm. OK, so the spec seems to be saying that we have 100ms to read the UP_REQ/DOWN_REPLY msg after the IRQ_HPD. That's still a lot more than the 1ms max allowed wakeup time. Looks like there's a extended wakeup time request/grant mechanism now, but without the explicit grant (which we don't do) the 1ms still holds. > > > > > * It's faster to keep the aux block on anyway > > > > > > > > > > > > > > > + > > > > > if (downstream_hpd_needs_d0(intel_dp)) > > > > > return; > > > > > > > > > > - ret = drm_dp_dpcd_writeb(&intel_dp->aux, > > > > > DP_SET_POWER, > > > > > - DP_SET_POWER_D3); > > > > > + ret = drm_dp_dpcd_writeb(&intel_dp->aux, > > > > > DP_SET_POWER, > > > > > data); > > > > > } else { > > > > > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp); > > > > > > > > > > -- > > > > > 2.14.3 > > > > > > > > > > > > > > -- > > > Cheers, > > > Lyude Paul > > > > > -- > Cheers, > Lyude Paul -- Ville Syrjälä Intel OTC From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com ([192.55.52.136]:58379 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752469AbeDDTbc (ORCPT ); Wed, 4 Apr 2018 15:31:32 -0400 Date: Wed, 4 Apr 2018 22:31:26 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Lyude Paul Cc: intel-gfx@lists.freedesktop.org, Laura Abbott , Dhinakaran Pandiyan , stable@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST Message-ID: <20180404193126.GH5453@intel.com> References: <20180402212142.19841-1-lyude@redhat.com> <20180402212617.21247-1-lyude@redhat.com> <20180404153429.GE5453@intel.com> <1522867061.12403.6.camel@redhat.com> <20180404185313.GG5453@intel.com> <1522868349.12403.12.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1522868349.12403.12.camel@redhat.com> Sender: stable-owner@vger.kernel.org List-ID: On Wed, Apr 04, 2018 at 02:59:09PM -0400, Lyude Paul wrote: > On Wed, 2018-04-04 at 21:53 +0300, Ville Syrj�l� wrote: > > On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote: > > > On Wed, 2018-04-04 at 18:34 +0300, Ville Syrj�l� wrote: > > > > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote: > > > > > While enabling/disabling DPMS before link training with MST hubs is > > > > > perfectly valid; unfortunately disabling DPMS results in some devices > > > > > disabling their AUX CH block as well. For SST this isn't as much of a > > > > > problem, but for MST we need to be able to continue handling aux > > > > > transactions even when none of the sinks are turned on since it's > > > > > possible for us to have a single atomic commit which results in > > > > > disabling each downstream sink, followed by subsequently re-enabling > > > > > each sink. > > > > > > > > > > If we don't do this, we'll end up stalling any pending ESI interrupts > > > > > from the sink for up to 1ms. Unfortunately, dropping ESIs during this > > > > > timespan makes it so that link fallback retraining for MST (which I > > > > > will > > > > > be submitting to the ML shortly) fails due to the channel EQ failure > > > > > interrupts potentially getting dropped. Additionally, when performing > > > > > a > > > > > modeset that brings the hub status's link status from bad -> good > > > > > having > > > > > ESIs disabled for that long causes us to miss the hub's response to us > > > > > trying to start link training as well. > > > > > > > > > > Since any sink with MST is going to support DisplayPort 1.2 anyway, > > > > > save > > > > > us the hassle of trying to wait until the sink comes back up and just > > > > > never shut the aux block down. > > > > > > > > > > Changes since v2: > > > > > - Fix patch name, no functional changes > > > > > > > > > > Signed-off-by: Lyude Paul > > > > > Cc: Laura Abbott > > > > > Cc: Dhinakaran Pandiyan > > > > > Cc: Ville Syrj�l� > > > > > Cc: stable@vger.kernel.org > > > > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable > > > > > MST > > > > > hub.") > > > > > --- > > > > > drivers/gpu/drm/i915/intel_dp.c | 6 ++++-- > > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > > > b/drivers/gpu/drm/i915/intel_dp.c > > > > > index 62f82c4298ac..0479c377981b 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp > > > > > *intel_dp, > > > > > int mode) > > > > > return; > > > > > > > > > > if (mode != DRM_MODE_DPMS_ON) { > > > > > + unsigned char data = intel_dp->is_mst ? > > > > > + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3; > > > > > > > > This smells like a workaround for an actual bug somewhere. Why exactly > > > > is the slower wakeup or the AUX block a problem for MST but not for SST > > > > when the link training is exactly the same for SST and MST? > > > > > > I actually thought about this but I still think this is the appropriate > > > fix. > > > So; the real reason for the wakeup not being a problem with SST is that > > > for > > > DPMS on with SST, we actually do a wait to make sure that the hub is ready > > > before continuing. And yes: I'm fairly sure SST does actually have around > > > the > > > same wakeup time that MST does, but with the wait we do it doesn't reallhy > > > make a difference. With MST, we could do this but there's a few reasons I > > > don't think we should: > > > * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub that > > > has > > > MST is going to be guaranteed to have this. > > > * Turning off the aux block means that there's a high chance we're going > > > to > > > miss ESIs from sinks > > > > And how exactly do we lose irqs? The hub/whatever throws the up req msgs > > away if we don't read them within some really short time? > That's my hypothesis at least. I'm betting that on the fact that when I was > implementing MST retraining before we put the intel_dp_check_mst_status() (or > whatever it's called) into the dig workqueue, getting the sink to go down and > come back up was a lot more unreliable whenever I introduced anything that > would block the esi handler for longer then a very brief period of time (say, > 50-100ms?). I've seen some notes elsewhere too that seemed to imply for SST, > things were pretty sensitive to irq latency (line 1050, intel_dp.c) so it > wouldn't be terribly surprising if it's the same for MST. At the very least, > now that we've got the ESI handler running in the dig worker things seem to > have gotten a /lot/ more reliable now that we can basically go the whole > modeset without blocking the ESI handler for very long. Hmm. OK, so the spec seems to be saying that we have 100ms to read the UP_REQ/DOWN_REPLY msg after the IRQ_HPD. That's still a lot more than the 1ms max allowed wakeup time. Looks like there's a extended wakeup time request/grant mechanism now, but without the explicit grant (which we don't do) the 1ms still holds. > > > > > * It's faster to keep the aux block on anyway > > > > > > > > > > > > > > > + > > > > > if (downstream_hpd_needs_d0(intel_dp)) > > > > > return; > > > > > > > > > > - ret = drm_dp_dpcd_writeb(&intel_dp->aux, > > > > > DP_SET_POWER, > > > > > - DP_SET_POWER_D3); > > > > > + ret = drm_dp_dpcd_writeb(&intel_dp->aux, > > > > > DP_SET_POWER, > > > > > data); > > > > > } else { > > > > > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp); > > > > > > > > > > -- > > > > > 2.14.3 > > > > > > > > > > > > > > -- > > > Cheers, > > > Lyude Paul > > > > > -- > Cheers, > Lyude Paul -- Ville Syrj�l� Intel OTC