From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thulasimani, Sivakumar" Subject: Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting Date: Tue, 1 Mar 2016 06:17:33 +0530 Message-ID: <56D4E6A5.8040607@intel.com> References: <1456265512-15670-1-git-send-email-cpaul@redhat.com> <56CD1660.2030203@intel.com> <20160229161249.GK32705@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: 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: Rob Clark , Daniel Vetter Cc: Daniel Vetter , Intel Graphics Development , "open list:INTEL DRM DRIVERS excluding Poulsbo, Moorestow..., linux-kernel@vger.kernel.org open list" , stable List-Id: dri-devel@lists.freedesktop.org CgpPbiAzLzEvMjAxNiA1OjAzIEFNLCBSb2IgQ2xhcmsgd3JvdGU6Cj4gT24gTW9uLCBGZWIgMjks IDIwMTYgYXQgMTE6MTIgQU0sIERhbmllbCBWZXR0ZXIgPGRhbmllbEBmZndsbC5jaD4gd3JvdGU6 Cj4+IE9uIFdlZCwgRmViIDI0LCAyMDE2IGF0IDA4OjAzOjA0QU0gKzA1MzAsIFRodWxhc2ltYW5p LCBTaXZha3VtYXIgd3JvdGU6Cj4+Pgo+Pj4gT24gMi8yNC8yMDE2IDM6NDEgQU0sIEx5dWRlIHdy b3RlOgo+Pj4+IEFzIGl0IHR1cm5zIG91dCwgcmVzdW1pbmcgRFAgTVNUIGlzIHJhY2V5IHNpbmNl IHdlIGRvbid0IG1ha2Ugc3VyZSBNU1QKPj4+PiBpcyByZWFkeSBiZWZvcmUgd2Ugc3RhcnQgbW9k ZXNldHRpbmcsIGl0IGp1c3QgdXN1YWxseSBoYXBwZW5zIHRvIGJlCj4+Pj4gcmVhZHkgaW4gdGlt ZS4gVGhpcyBpc24ndCB0aGUgY2FzZSBvbiBhbGwgc3lzdGVtcywgcGFydGljdWxhcmx5IGEKPj4+ PiBUaGlua1BhZCBUNTYwIHdpdGggZGlzcGxheXMgY29ubmVjdGVkIHRocm91Z2ggdGhlIGRvY2su IE9uIHRoZXNlCj4+Pj4gc3lzdGVtcywgcmVzdW1pbmcgdGhlIGxhcHRvcCB3aGlsZSBjb25uZWN0 ZWQgdG8gdGhlIGRvY2sgdXN1YWxseSByZXN1bHRzCj4+Pj4gaW4gYmxhbmsgbW9uaXRvcnMuIE1h a2luZyBzdXJlIE1TVCBpcyByZWFkeSBiZWZvcmUgZG9pbmcgYW55IGtpbmQgb2YKPj4+PiBtb2Rl c2V0dGluZyBmaXhlcyB0aGlzIGlzc3VlLgo+Pj4gYmFzaWMgcXVlc3Rpb24gc2luY2UgaSBoYXZl bid0IHdvcmtlZCBvbiBNU1QgbXVjaC4gTVNUIHNob3VsZCB3b3JrIGxpa2UgYW55Cj4+PiBvdGhl ciBkaWdpdGFsIHBhbmVsIG9uIHJlc3VtZS4gaS5lIGRldGVjdCBmb2xsb3dlZCBieSBtb2Rlc2V0 LiBpbiB0aGUKPj4+IG1vZGlmaWVkCj4+PiBjb21taXQgbWVudGlvbmVkIGJlbG93IGlzIGl0IGZh aWxpbmcgdG8gZGV0ZWN0IHRoZSBwYW5lbCBvciBmYWlsaW5nIGF0IHRoZQo+Pj4gbW9kZXNldCA/ Cj4+PiBpZiB3ZSBhcmUgZGVwZW5kaW5nIG9uIHRoZSBpbnRlbF9kaXNwbGF5X3Jlc3VtZSwgaG93 IGFib3V0IG1vdmluZyB0aGUKPj4+IGludGVsX2RwX21zdF9yZXN1bWUganVzdCBhYm92ZSBpbnRl bF9kaXNwbGF5X3Jlc3VtZT8KPj4+Cj4+Pgo+Pj4gR2VuZXJpYyBxdWVzdGlvbiB0byBvdGhlcnMg aW4gbWFpbCBsaXN0IG9uIGk5MTVfZHJtX3Jlc3VtZQo+Pj4gd2UgYXJlIGRvaW5nIGEgbW9kZXNl dCBhbmQgdGhlbiBkb2luZyB0aGUgZGV0ZWN0L2hwZCBpbml0Lgo+Pj4gc2hvdWxkbid0IHRoaXMg YmUgdGhlIG90aGVyIHdheSByb3VuZCA/IGFsbW9zdCBhbGwgZGlzcGxheXMKPj4+IHdpbGwgcGFz cyBhIG1vZGVzZXQgZXZlbiBpZiBkaXNwbGF5IGlzIG5vdCBjb25uZWN0ZWQgc28gd2UKPj4+IGFy ZSBzcGVuZGluZyB0aW1lIG9uIG1vZGVzZXQgZXZlbiBmb3IgZGlzcGxheXMgdGhhdCB3ZXJlCj4+ PiByZW1vdmVkIGR1cmluZyB0aGUgc3VzcGVuZCBzdGF0ZS4gaWYgdGhpcyBpcyB0byBzaW1wbHkK Pj4+IGRybV9zdGF0ZSBiZWluZyBzYXZlZCBhbmQgcmVzdG9yZWQsCj4+IFdlIG11c3QgcmVzdG9y ZSBhbnl3YXksIHdlJ3JlIG5vdCByZWFsbHkgYWxsb3dlZCB0byBzaHV0IGRvd24gYSBkaXNwbGF5 Cj4+IHdpdGhvdXQgdXNlcnNwYWNlJ3MgY29uc2VudC4gRFAgbXN0IGJyZWFrcyB0aGlzLCBhbmQg aXQncyBub3QgZnVuIHJlYWxseS4KPiB3ZWxsLCB0aGF0IGlzbid0IGNvbXBsZXRlbHkgdHJ1ZS4u IEkgbWVhbiwgaWYgdGhlIHVzZXIgdW5wbHVncyAoZm9yCj4gZXhhbXBsZSkgYW4gaGRtaSBtb25p dG9yLCBpdCBpc24ndCB3aXRoIHVzZXJzcGFjZSdzIGNvbnNlbnQuLgo+Cj4gSSB3b25kZXIgaWYg d2UgY291bGQganVzdCBoYXZlIGZsYWcgcGVyIGNvbm5lY3RvciwgaWUuCj4gY29ubmVjdG9yLT5u b19hdXRvX3Jlc3VtZSBhbmQganVzdCBhdXRvbWF0aWNhbGx5IHNlbmQgdW5wbHVnIGV2ZW50cwo+ IGZvciB0aG9zZSB0byB1c2Vyc3BhY2UgKGZvbGxvd2VkIHNob3J0bHkgYnkgYSBwbHVnIGV2ZW50 IGlmIGl0IGlzCj4gc3RpbGwgY29ubmVjdGVkIGFuZCB0aGUgbm9ybWFsIGhwZCBtZWNoYW5pc20g a2lja3MgaW4/ICBJIG1lYW4sIGZvcgo+IGFsbCB3ZSBrbm93LCB0aGUgdXNlciB1bnBsdWdnZWQg dGhlIERQIG1vbml0b3IvaHViL2V0YyBhbmQgcGx1Z2dlZCBpbgo+IGEgZGlmZmVyZW50IG9uZSB3 aGlsZSB3ZSB3ZXJlIHN1c3BlbmRlZC4uCj4KPiBCUiwKPiAtUgppIGFncmVlLiBwZXJmb3JtaW5n IGEgbW9kZXNldCBvbiBhIGRpc3BsYXkgd2l0aG91dCBldmVuIGNvbmZpcm1pbmcKaWYgaXQgaXMg dGhlIHNhbWUgb25lIHdoZW4gd2UgaGFkIHN1c3BlbmRlZCB0aGUgc3lzdGVtIHdpbGwgcmVzdWx0 IGluCmlzc3VlcyBzdWNoIGFzIGFwcGx5aW5nIGEgbW9kZSB0aGF0IG1heSBub3QgYmUgc3VwcG9y dGVkIG9uIHRoZQpuZXcgZGlzcGxheSBvciBjb3JydXB0aW9uIG9yIGJsYW5rb3V0IG9yIHNpbXBs eSBmYWlsaW5nIHRoZSBtb2Rlc2V0CnJlc3RvcmUgb3Igd29yc3QgY2FzZSBvZiBkb2luZyBtb2Rl c2V0IHdpdGhvdXQgYSBkaXNwbGF5IGNvbm5lY3RlZC4KaWYgd2Ugd2lsbCBub3QgYWxsb3cgc3Vj aCBhIHNjZW5hcmlvIGR1cmluZyBub3JtYWwgb3BlcmF0aW9uLCBpLmUgcHJldmVudAppbmNvcnJl Y3QgbW9kZXNldCByZXF1ZXN0cyBkdXJpbmcgbm9ybWFsIGZ1bmN0aW9uaW5nLCB3aHkgYWxsb3cg c3VjaAphIG1vZGVzZXQgZHVyaW5nIHN1c3BlbmQtcmVzdW1lIGFsb25lID8Kd2UgY2FuIHN0b3Jl IHRoZSBlZGlkIGhhc2ggYW5kIGlmIHRoZSBkaXNwbGF5IGhhcyB0aGUgc2FtZSBoYXNoCnBvc3Qg cmVzdW1lIHRoZW4gd2UgY2FuIGFsbG93IG1vZGUgdG8gYmUgcmVzdG9yZWQuCgpyZWdhcmRzLApT aXZha3VtYXIKPj4gU28gZm9yIGhvdHVucGx1ZyB0aGUgZmxvdyBzaG91bGQgYWx3YXlzIGJlOgo+ PiAxLiBrZXJuZWwgbm90aWNlcyBzb21ldGhpbmcgaGFzIGNoYW5nZWQgaW4gdGhlIG91dHB1dCBj b25maWcuCj4+IDIuIGtlcm5lbCBzZW5kcyBvdXQgdWV2ZW50Cj4+IDMuIHVzZXJzcGFjZSBmaWd1 cmVzIG91dCB3aGF0IGNoYW5nZWQsIGFuZCB3aGF0IG5lZWRzIHRvIGJlIGRvbmUKPj4gNC4gdXNl cnNwYWNlIGFza3MgdGhlIGtlcm5lbCB0byBjaGFuZ2UgZGlzcGxheSBjb25maWd1cmF0aW9uIHRo cm91Z2gKPj4gc2V0Q3J0YyBhbmQgQXRvbWljIGlvY3RsIGNhbGxzLgo+Pgo+PiBJcnJlc3BlY3Rp dmUgb2YgaG90dW5wbHVnIGhhbmRsaW5nLCB0aGUga2VybmVsIGFsc28gX211c3RfIHJlc3RvcmUg dGhlCj4+IGVudGlyZSBkaXNwbGF5IGNvbmZpZ3VyYXRpb24gYmVmb3JlIHVzZXJzcGFjZSByZXN1 bWVzLiBXZSBjYW4gZG8gdGhhdAo+PiBhc3luY2hyb25vdXNseSAoYW5kIHRoZXJlJ3MgcGxhbnMg Zm9yIHRoYXQpLCBidXQgZXZlbiB0aGVuIHdlIG11c3Qgc3RhbGwKPj4gdXNlcnNwYWNlIG9uIHRo ZSBmaXJzdCBLTVMgaW9jbHQgdG8ga2VlcCB1cCB0aGUgaWxsdXNpb24gdGhhdCBhIHN5c3RlbSBz L3IKPj4gaXMgdHJhbnNwYXJlbnQuCj4+Cj4+IEluIHNob3J0LCBldmVuIGlmIHdlIGRvIGhwZCBw cm9jZXNzaW5nIGJlZm9yZSByZXN1bWluZyB0aGUgZGlzcGxheSwKPj4gbm90aGluZyB3aWxsIGJl IGZhc3RlciAtIHdlIG11c3Qgd2FpdCBmb3IgdXNlcnNwYWNlIHRvIG1ha2UgdXAgaXRzIG1pbmQs Cj4+IGFuZCB0aGF0IGNhbiBvbmx5IGhhcHBlbiBvbmNlIHdlJ3ZlIHJlc3RvcmVkIHRoZSBkaXNw bGF5IGNvbmZpZy4KPj4KPj4gQW5kIGFnYWluLCBtc3QgaXMga2luZGEgYnJlYWtpbmcgdGhpcywg c2luY2UgYW5kIG1zdCB1bnBsdWcgcmVzdWx0cyBpbiBhCj4+IGZvcmNlLWRpc2FibGUuIFdoaWNo IGNhbiB1cHNldCB1c2Vyc3BhY2UgYW5kIGluIGdlbmVyYWwgcmVzdWx0cyBpbiB0aGUKPj4gbmVl ZCBmb3IgbG90cyBvZiBmcmFnaWxlIGVycm9yIGhhbmRsaW5nIGFsbCBvdmVyLgo+Pgo+Pj4+IFdl IG9yaWdpbmFsbHkgY2hhbmdlZCB0aGUgcmVzdW1lIG9yZGVyIGluCj4+Pj4KPj4+PiAgICAgIGNv bW1pdCBlN2Q2ZjdkNzA4MjkgKCJkcm0vaTkxNTogcmVzdW1lIE1TVCBhZnRlciByZWFkaW5nIGJh Y2sgaHcgc3RhdGUiKQo+Pj4+Cj4+Pj4gdG8gZml4IGEgdG9uIG9mIFdBUk5fT04ncyBhZnRlciBy ZXN1bWUsIGJ1dCB0aGlzIGRvZXNuJ3Qgc2VlbSB0byBiZSBhbgo+Pj4+IGlzc3VlIG5vdyBhbnlo b3cuCj4+Pj4KPj4+PiBDQzogc3RhYmxlQHZnZXIua2VybmVsLm9yZwo+Pj4+IFNpZ25lZC1vZmYt Ynk6IEx5dWRlIDxjcGF1bEByZWRoYXQuY29tPgo+PiBXcnQgdGhlIHBhdGNoIGl0c2VsZjogSSB0 aGluayBvbmx5IGluIDQuNiB3ZSd2ZSBhY3R1YWxseSBmaXhlZCB1cCBhbGwKPj4gdGhlc2UgbXN0 IFdBUk5fT04uIENjOiBzdGFibGUgc2VlbXMgZXh0cmVtZWx5IHJpc2t5IG9uIHRoaXMgb25lLiBB bHNvLCB0aGUKPj4gbW9kZXNldCBzdGF0ZSByZWFkb3V0IGZvciBtc3QgaXMgc3RpbGwgbm90IGVu dGlyZWx5IGNvcnJlY3QgKGl0IHN0aWxsCj4+IHJlbGllcyBvbiBzb2Z0d2FyZSBzdGF0ZSksIHNv IEknbSBub3Qgc3VyZSB3ZSd2ZSBhY3R1YWxseSBtYW5hZ2VkIHRvIHNodXQKPj4gdXAgYWxsIHRo ZSBXQVJOSU5Hcy4gSWlyYyB0aGUgd2F5IHRvIHJlcHJvIHRoZW0gaXMgdG8gaG90LXVucGx1ZyBz b21ldGhpbmcKPj4gd2hpbGUgc3VzcGVuZGVkLiBJbiBzaG9ydCB0aGUgZ2V0X2h3X3N0YXRlIGZ1 bmN0aW9ucyBmb3IgbXN0IHNob3VsZCBub3QKPj4gcmVseSBvbiBhbnkgbXN0IHNvZnR3YXJlIHN0 YXRlLCBidXQgaW5zdGVhZCBqdXN0IGxvb2sgYXQgaHcgcmVnaXN0ZXJzIGFuZAo+PiBkcCBhdXgg cmVnaXN0ZXJzIHRvIGZpZ3VyZSBvdXQgd2hhdCdzIGdvaW5nIG9uLiBCdXQgbm90IHN1cmUgd2hl dGhlciB0aGlzCj4+IHdpbGwgcmVzdWx0IG9uIFdBUk5JTkdzIG9uIHJlc3VtZSwgc2luY2UgZ2Vu ZXJhbGx5IHRoZSBiaW9zIGRvZXNuJ3QgZW5hYmxlCj4+IGFueXRoaW5nIGluIHRoYXQgY2FzZS4K Pj4KPj4gRnVydGhlcm1vcmUgTVNUIHN0aWxsIGRvZXMgYSBmb3JjZS1tb2Rlc2V0IHdoZW4gcHJv Y2Vzc2luZyBhIGhvdHVucGx1Zy4KPj4gRG9pbmcgdGhhdCBiZWZvcmUgd2UndmUgcmVzdW1lZCB0 aGUgZGlzcGxheSBpcyBsaWtlbHkgYSB2ZXJ5IGJhZCBpZGVhLgo+PiBXaGF0IHdlIG5lZWQgdG8g Zml4IHRoYXQgcGFydCBpcyB0byBzZXBhcmF0ZSB0aGUgZHAgbXN0IGNvbm5lY3Rvcgo+PiBob3Rw bHVnL3VucGx1Z2dpbmcgZnJvbSBhY3R1YWxseSB1cGRhdGluZyB0aGUgbW9kZXNldCBjaGFuZ2Uu IFRoaXMgbmVlZHMKPj4gcmVmZXJlbmNlLWNvdW50aW5nIG9uIGRybV9jb25uZWN0b3IgKHNvIHRo YXQgd2UgY2FuIGxhemlseSBmcmVlCj4+IGRybV9jb25uZWN0b3Igc3RydWN0cyBhZnRlciBob3Qt dW5wbHVnKSwgYW5kIGlzIGEgbWFqb3IgY2hhbmdlLgo+Pgo+PiBJbiBzaG9ydDogSSdtIHNjYXJl ZCBhYm91dCB0aGlzIHBhdGNoIDstKQo+Pgo+PiBUaGFua3MsIERhbmllbAo+Pgo+Pgo+Pj4+IC0t LQo+Pj4+ICAgZHJpdmVycy9ncHUvZHJtL2k5MTUvaTkxNV9kcnYuYyB8IDEwICsrKysrKysrLS0K Pj4+PiAgIDEgZmlsZSBjaGFuZ2VkLCA4IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCj4+ Pj4KPj4+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9ncHUvZHJtL2k5MTUvaTkxNV9kcnYuYyBiL2Ry aXZlcnMvZ3B1L2RybS9pOTE1L2k5MTVfZHJ2LmMKPj4+PiBpbmRleCBmMzU3MDU4Li40ZGNmM2Rk IDEwMDY0NAo+Pj4+IC0tLSBhL2RyaXZlcnMvZ3B1L2RybS9pOTE1L2k5MTVfZHJ2LmMKPj4+PiAr KysgYi9kcml2ZXJzL2dwdS9kcm0vaTkxNS9pOTE1X2Rydi5jCj4+Pj4gQEAgLTczMyw2ICs3MzMs MTQgQEAgc3RhdGljIGludCBpOTE1X2RybV9yZXN1bWUoc3RydWN0IGRybV9kZXZpY2UgKmRldikK Pj4+PiAgICAgIGludGVsX29wcmVnaW9uX3NldHVwKGRldik7Cj4+Pj4gICAgICBpbnRlbF9pbml0 X3BjaF9yZWZjbGsoZGV2KTsKPj4+PiArCj4+Pj4gKyAgICAvKgo+Pj4+ICsgICAgICogV2UgbmVl ZCB0byBtYWtlIHN1cmUgdGhhdCB3ZSByZXN1bWUgTVNUIGJlZm9yZSBkb2luZyBhbnl0aGluZwo+ Pj4+ICsgICAgICogZGlzcGxheSByZWxhdGVkLCBvdGhlcndpc2Ugd2UgcmlzayB0cnlpbmcgdG8g YnJpbmcgdXAgYSBkaXNwbGF5IG9uCj4+Pj4gKyAgICAgKiBNU1QgYmVmb3JlIHRoZSBodWIgaXMg YWN0dWFsbHkgcmVhZHkKPj4+PiArICAgICAqLwo+Pj4+ICsgICAgaW50ZWxfZHBfbXN0X3Jlc3Vt ZShkZXYpOwo+Pj4+ICsKPj4+IFRoaXMgZG9lcyBub3QgbG9vayBwcm9wZXIuIGlmIHRoZSBDRCBj bG9jayBpcyB0dXJuZWQgb2ZmIGR1cmluZyBzdXNwZW5kCj4+PiBvdXIgZHBjZCByZWFkIGl0c2Vs ZiBtaWdodCBmYWlsIHRpbGwgd2UgZW5hYmxlIENEIENsb2NrLgo+Pj4KPj4+IHJlZ2FyZHMsCj4+ PiBTaXZha3VtYXIKPj4+PiAgICAgIGRybV9tb2RlX2NvbmZpZ19yZXNldChkZXYpOwo+Pj4+ICAg ICAgLyoKPj4+PiBAQCAtNzY1LDggKzc3Myw2IEBAIHN0YXRpYyBpbnQgaTkxNV9kcm1fcmVzdW1l KHN0cnVjdCBkcm1fZGV2aWNlICpkZXYpCj4+Pj4gICAgICBpbnRlbF9kaXNwbGF5X3Jlc3VtZShk ZXYpOwo+Pj4+ICAgICAgZHJtX21vZGVzZXRfdW5sb2NrX2FsbChkZXYpOwo+Pj4+IC0gICAgaW50 ZWxfZHBfbXN0X3Jlc3VtZShkZXYpOwo+Pj4+IC0KPj4+PiAgICAgIC8qCj4+Pj4gICAgICAgKiAu Li4gYnV0IGFsc28gbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBob3RwbHVnIHByb2Nlc3NpbmcKPj4+ PiAgICAgICAqIGRvZXNuJ3QgY2F1c2UgaGF2b2MuIExpa2UgaW4gdGhlIGRyaXZlciBsb2FkIGNv ZGUgd2UgZG9uJ3QKPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCj4+PiBJbnRlbC1nZnggbWFpbGluZyBsaXN0Cj4+PiBJbnRlbC1nZnhAbGlzdHMuZnJl ZWRlc2t0b3Aub3JnCj4+PiBodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ludGVsLWdmeAo+PiAtLQo+PiBEYW5pZWwgVmV0dGVyCj4+IFNvZnR3YXJlIEVuZ2lu ZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbgo+PiBodHRwOi8vYmxvZy5mZndsbC5jaAo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBJbnRlbC1nZnggbWFp bGluZyBsaXN0Cj4+IEludGVsLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKPj4gaHR0cHM6Ly9s aXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5n IGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVk ZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com ([134.134.136.20]:34978 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751292AbcCAArj (ORCPT ); Mon, 29 Feb 2016 19:47:39 -0500 Subject: Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting To: Rob Clark , Daniel Vetter References: <1456265512-15670-1-git-send-email-cpaul@redhat.com> <56CD1660.2030203@intel.com> <20160229161249.GK32705@phenom.ffwll.local> Cc: David Airlie , Intel Graphics Development , stable , open "list:INTEL" DRM DRIVERS excluding "Poulsbo," "Moorestow...," "linux-kernel@vger.kernel.org" open list , Daniel Vetter From: "Thulasimani, Sivakumar" Message-ID: <56D4E6A5.8040607@intel.com> Date: Tue, 1 Mar 2016 06:17:33 +0530 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 3/1/2016 5:03 AM, Rob Clark wrote: > On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote: >> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote: >>> >>> On 2/24/2016 3:41 AM, Lyude wrote: >>>> As it turns out, resuming DP MST is racey since we don't make sure MST >>>> is ready before we start modesetting, it just usually happens to be >>>> ready in time. This isn't the case on all systems, particularly a >>>> ThinkPad T560 with displays connected through the dock. On these >>>> systems, resuming the laptop while connected to the dock usually results >>>> in blank monitors. Making sure MST is ready before doing any kind of >>>> modesetting fixes this issue. >>> basic question since i haven't worked on MST much. MST should work like any >>> other digital panel on resume. i.e detect followed by modeset. in the >>> modified >>> commit mentioned below is it failing to detect the panel or failing at the >>> modeset ? >>> if we are depending on the intel_display_resume, how about moving the >>> intel_dp_mst_resume just above intel_display_resume? >>> >>> >>> Generic question to others in mail list on i915_drm_resume >>> we are doing a modeset and then doing the detect/hpd init. >>> shouldn't this be the other way round ? almost all displays >>> will pass a modeset even if display is not connected so we >>> are spending time on modeset even for displays that were >>> removed during the suspend state. if this is to simply >>> drm_state being saved and restored, >> We must restore anyway, we're not really allowed to shut down a display >> without userspace's consent. DP mst breaks this, and it's not fun really. > well, that isn't completely true.. I mean, if the user unplugs (for > example) an hdmi monitor, it isn't with userspace's consent.. > > I wonder if we could just have flag per connector, ie. > connector->no_auto_resume and just automatically send unplug events > for those to userspace (followed shortly by a plug event if it is > still connected and the normal hpd mechanism kicks in? I mean, for > all we know, the user unplugged the DP monitor/hub/etc and plugged in > a different one while we were suspended.. > > BR, > -R i agree. performing a modeset on a display without even confirming if it is the same one when we had suspended the system will result in issues such as applying a mode that may not be supported on the new display or corruption or blankout or simply failing the modeset restore or worst case of doing modeset without a display connected. if we will not allow such a scenario during normal operation, i.e prevent incorrect modeset requests during normal functioning, why allow such a modeset during suspend-resume alone ? we can store the edid hash and if the display has the same hash post resume then we can allow mode to be restored. regards, Sivakumar >> So for hotunplug the flow should always be: >> 1. kernel notices something has changed in the output config. >> 2. kernel sends out uevent >> 3. userspace figures out what changed, and what needs to be done >> 4. userspace asks the kernel to change display configuration through >> setCrtc and Atomic ioctl calls. >> >> Irrespective of hotunplug handling, the kernel also _must_ restore the >> entire display configuration before userspace resumes. We can do that >> asynchronously (and there's plans for that), but even then we must stall >> userspace on the first KMS ioclt to keep up the illusion that a system s/r >> is transparent. >> >> In short, even if we do hpd processing before resuming the display, >> nothing will be faster - we must wait for userspace to make up its mind, >> and that can only happen once we've restored the display config. >> >> And again, mst is kinda breaking this, since and mst unplug results in a >> force-disable. Which can upset userspace and in general results in the >> need for lots of fragile error handling all over. >> >>>> We originally changed the resume order in >>>> >>>> commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state") >>>> >>>> to fix a ton of WARN_ON's after resume, but this doesn't seem to be an >>>> issue now anyhow. >>>> >>>> CC: stable@vger.kernel.org >>>> Signed-off-by: Lyude >> Wrt the patch itself: I think only in 4.6 we've actually fixed up all >> these mst WARN_ON. Cc: stable seems extremely risky on this one. Also, the >> modeset state readout for mst is still not entirely correct (it still >> relies on software state), so I'm not sure we've actually managed to shut >> up all the WARNINGs. Iirc the way to repro them is to hot-unplug something >> while suspended. In short the get_hw_state functions for mst should not >> rely on any mst software state, but instead just look at hw registers and >> dp aux registers to figure out what's going on. But not sure whether this >> will result on WARNINGs on resume, since generally the bios doesn't enable >> anything in that case. >> >> Furthermore MST still does a force-modeset when processing a hotunplug. >> Doing that before we've resumed the display is likely a very bad idea. >> What we need to fix that part is to separate the dp mst connector >> hotplug/unplugging from actually updating the modeset change. This needs >> reference-counting on drm_connector (so that we can lazily free >> drm_connector structs after hot-unplug), and is a major change. >> >> In short: I'm scared about this patch ;-) >> >> Thanks, Daniel >> >> >>>> --- >>>> drivers/gpu/drm/i915/i915_drv.c | 10 ++++++++-- >>>> 1 file changed, 8 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c >>>> index f357058..4dcf3dd 100644 >>>> --- a/drivers/gpu/drm/i915/i915_drv.c >>>> +++ b/drivers/gpu/drm/i915/i915_drv.c >>>> @@ -733,6 +733,14 @@ static int i915_drm_resume(struct drm_device *dev) >>>> intel_opregion_setup(dev); >>>> intel_init_pch_refclk(dev); >>>> + >>>> + /* >>>> + * We need to make sure that we resume MST before doing anything >>>> + * display related, otherwise we risk trying to bring up a display on >>>> + * MST before the hub is actually ready >>>> + */ >>>> + intel_dp_mst_resume(dev); >>>> + >>> This does not look proper. if the CD clock is turned off during suspend >>> our dpcd read itself might fail till we enable CD Clock. >>> >>> regards, >>> Sivakumar >>>> drm_mode_config_reset(dev); >>>> /* >>>> @@ -765,8 +773,6 @@ static int i915_drm_resume(struct drm_device *dev) >>>> intel_display_resume(dev); >>>> drm_modeset_unlock_all(dev); >>>> - intel_dp_mst_resume(dev); >>>> - >>>> /* >>>> * ... but also need to make sure that hotplug processing >>>> * doesn't cause havoc. Like in the driver load code we don't >>> _______________________________________________ >>> Intel-gfx mailing list >>> Intel-gfx@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx