From mboxrd@z Thu Jan 1 00:00:00 1970 From: Imre Deak Subject: Re: [Intel-gfx] [KERNEL] Regression bug in drm/i915, Wrong assumption in commit e11aa36 breaks suspend on at least lenovo x61 Date: Thu, 19 Feb 2015 18:39:35 +0200 Message-ID: <1424363975.19250.5.camel@intel.com> References: <20150211113919.GA5672@ikki.ethgen.ch> <20150216221142.GB14602@ikki.ethgen.ch> <20150217082937.GA27873@ikki.ethgen.ch> <87mw4bw7o7.fsf@intel.com> <1424276692.27236.1.camel@intel.com> <54E5BF59.4020208@intel.com> <1424344107.3496.10.camel@ideak-mobl> <54E60450.9010605@intel.com> Reply-To: imre.deak@intel.com Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <54E60450.9010605@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Dave Gordon Cc: dri-devel , Klaus Ethgen , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org T24gdG8sIDIwMTUtMDItMTkgYXQgMTU6NDIgKzAwMDAsIERhdmUgR29yZG9uIHdyb3RlOgo+IE9u IDE5LzAyLzE1IDExOjA4LCBEZWFrLCBJbXJlIHdyb3RlOgo+ID4gT24gVGh1LCAyMDE1LTAyLTE5 IGF0IDEwOjQ3ICswMDAwLCBEYXZlIEdvcmRvbiB3cm90ZToKPiA+PiBPbiAxOC8wMi8xNSAxNjoy NCwgSW1yZSBEZWFrIHdyb3RlOgo+ID4+PiBPbiBrZSwgMjAxNS0wMi0xOCBhdCAxNzozOSArMDIw MCwgSmFuaSBOaWt1bGEgd3JvdGU6Cj4gPj4+PiBPbiBUdWUsIDE3IEZlYiAyMDE1LCBLbGF1cyBF dGhnZW4gPEtsYXVzK2xrbWxAZXRoZ2VuLmRlPiB3cm90ZToKPiA+Pj4+PiBBZnRlciBzb2x2aW5n ICB0aGUgY29uZmxpY3RzLCBJIGFwcGxpZWQgdGhlIHJldmVydCAoc2VlIGF0dGFjaG1lbnQpIHRv Cj4gPj4+Pj4gdjMuMTguNy4gSSB0aGluayBpdCBzaG91bGQgYWxzbyBhcHBseSB0byB0aGUgY3Vy cmVudCBoZWFkLiBXaXRoIHRoYXQKPiA+Pj4+PiBwYXRjaCwgc3VzcGVuZCBpcyB3b3JraW5nIGFn YWluIG9uIHRoYXQgdmVyc2lvbi4KPiA+Pj4+Pgo+ID4+Pj4+IEhvd2V2ZXIsIEkgaGF2ZSBub3Qg dG8gZGVlcCBrbm93bGVkZ2Ugb2YgdGhhdCBzdWJzeXN0ZW0sIHNvIHBsZWFzZSwKPiA+Pj4+PiBz b21lb25lIHdobyBoYXZlLCBoYXZlIGEgZGVlcGVyIGxvb2sgaW50byBpdC4gSSBlc3BlY2lhbGx5 IGRvIG5vdCBrbm93Cj4gPj4+Pj4gaWYgdGhlIGxpbmVzIGluIC4uLi9pbnRlbF9wbS5jIGFyZSBj b3JyZWN0IG9yIGJldHRlciBsZWF2aW5nIHRoZW0gYXMKPiA+Pj4+PiB0aGV5IGFyZSBpbiB2My4x OC43Lgo+ID4+Pj4+Cj4gPj4+Pj4gSSB3YW50IHRvIGhhdmUgaXQgd29ya2luZyBvbiBhIHZlcnNp b24gdGhhdCBJIGtub3cgaXMgc3RhYmxlIGJlZm9yZQo+ID4+Pj4+IGFza2luZyB0byBwdWxsIGl0 IHRvIGhlYWQuCj4gPj4+Pgo+ID4+Pj4gSGkgS2xhdXMsIHdlIGZlYXIgdGhpcyBwYXRjaCBtYXkg aGlkZSB0aGUgYWN0dWFsIGNhdXNlLiBXb3VsZCBiZSB1c2VmdWwKPiA+Pj4+IHRvIGdldCBhIGJl dHRlciBkZXNjcmlwdGlvbiBvZiB3aGF0IGhhcHBlbnMsIGFsb25nIHdpdGggYSBkbWVzZyB3aXRo Cj4gPj4+PiBkcm0uZGVidWc9MTQgbW9kdWxlIHBhcmFtZXRlciBzZXQuIFRoaXMgbWlnaHQgY2x1 dHRlciB0aGUgbWFpbGluZyBsaXN0LAo+ID4+Pj4gd291bGQgeW91IG1pbmQgZmlsaW5nIGEgYnVn IGF0IFsxXSBhbmQgYXR0YWNoIHRoZSBpbmZvIHRoZXJlPwo+ID4+Pj4KPiA+Pj4+IFRoYW5rcywK PiA+Pj4+IEphbmkuCj4gPj4+Pgo+ID4+Pj4gWzFdIGh0dHBzOi8vYnVncy5mcmVlZGVza3RvcC5v cmcvZW50ZXJfYnVnLmNnaT9wcm9kdWN0PURSSSZjb21wb25lbnQ9RFJNL0ludGVsCj4gPj4+Cj4g Pj4+IEluIGFkZGl0aW9uIHRvIHRoZSBhYm92ZSBjb3VsZCB5b3UgYWxzbyB0cnkgdGhlIGZvbGxv d2luZyBwYXRjaCBhbmQKPiA+Pj4gcHJvdmlkZSBhIGRtZXNnIGxvZyBvbiB0aGUgYnVnemlsbGEg dGlja2V0IC0gYXQgdGhpcyBwb2ludCBvbmx5IHRvIHRyeQo+ID4+PiB0byBuYXJyb3cgZG93biB0 aGUgaXNzdWU/Ogo+ID4+Pgo+ID4+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9ncHUvZHJtL2k5MTUv aTkxNV9pcnEuYyBiL2RyaXZlcnMvZ3B1L2RybS9pOTE1L2k5MTVfaXJxLmMKPiA+Pj4gaW5kZXgg ZDM1OGNlOC4uMDJjNjVmNCAxMDA2NDQKPiA+Pj4gLS0tIGEvZHJpdmVycy9ncHUvZHJtL2k5MTUv aTkxNV9pcnEuYwo+ID4+PiArKysgYi9kcml2ZXJzL2dwdS9kcm0vaTkxNS9pOTE1X2lycS5jCj4g Pj4+IEBAIC00NDY2LDYgKzQ0NjYsMTQgQEAgc3RhdGljIGlycXJldHVybl90IGk5NjVfaXJxX2hh bmRsZXIoaW50IGlycSwgdm9pZCAqYXJnKQo+ID4+PiAgCQlJOTE1X0RJU1BMQVlfUExBTkVfQV9G TElQX1BFTkRJTkdfSU5URVJSVVBUIHwKPiA+Pj4gIAkJSTkxNV9ESVNQTEFZX1BMQU5FX0JfRkxJ UF9QRU5ESU5HX0lOVEVSUlVQVDsKPiA+Pj4gIAo+ID4+PiArCWlmICghaW50ZWxfaXJxc19lbmFi bGVkKGRldl9wcml2KSkgewo+ID4+PiArCQlpZiAocHJpbnRrX3JhdGVsaW1pdCgpKQo+ID4+PiAr CQkJRFJNX0VSUk9SKCJzcHVyaW91cy9zaGFyZWQgaW50ZXJydXB0IGlpciAlMDh4IGltciAlMDh4 IGllciAlMDh4XG4iLAo+ID4+PiArCQkJCSAgSTkxNV9SRUFEKElJUiksIEk5MTVfUkVBRChJTVIp LCBJOTE1X1JFQUQoSUVSKSk7Cj4gPj4+ICsKPiA+Pj4gKwkJcmV0dXJuIElSUV9OT05FOwo+ID4+ PiArCX0KPiA+Pj4gKwo+ID4+PiAgCWlpciA9IEk5MTVfUkVBRChJSVIpOwo+ID4+PiAgCj4gPj4+ ICAJZm9yICg7Oykgewo+ID4+PiBAQCAtNDc2Niw3ICs0Nzc0LDEwIEBAIHZvaWQgaW50ZWxfcnVu dGltZV9wbV9kaXNhYmxlX2ludGVycnVwdHMoc3RydWN0IGRybV9kZXZpY2UgKmRldikKPiA+Pj4g IAlzdHJ1Y3QgZHJtX2k5MTVfcHJpdmF0ZSAqZGV2X3ByaXYgPSBkZXYtPmRldl9wcml2YXRlOwo+ ID4+PiAgCj4gPj4+ICAJZGV2LT5kcml2ZXItPmlycV91bmluc3RhbGwoZGV2KTsKPiA+Pj4gKwo+ ID4+PiArCXNwaW5fbG9ja19pcnEoJmRldl9wcml2LT5pcnFfbG9jayk7Cj4gPj4+ICAJZGV2X3By aXYtPnBtLl9pcnFzX2Rpc2FibGVkID0gdHJ1ZTsKPiA+Pj4gKwlzcGluX3VubG9ja19pcnEoJmRl dl9wcml2LT5pcnFfbG9jayk7Cj4gPj4+ICB9Cj4gPj4+ICAKPiA+Pj4gIC8qIFJlc3RvcmUgaW50 ZXJydXB0cyBzbyB3ZSBjYW4gcmVjb3ZlciBmcm9tIHJ1bnRpbWUgUE0uICovCj4gPj4+IEBAIC00 Nzc0LDcgKzQ3ODUsMTAgQEAgdm9pZCBpbnRlbF9ydW50aW1lX3BtX3Jlc3RvcmVfaW50ZXJydXB0 cyhzdHJ1Y3QgZHJtX2RldmljZSAqZGV2KQo+ID4+PiAgewo+ID4+PiAgCXN0cnVjdCBkcm1faTkx NV9wcml2YXRlICpkZXZfcHJpdiA9IGRldi0+ZGV2X3ByaXZhdGU7Cj4gPj4+ICAKPiA+Pj4gKwlz cGluX2xvY2tfaXJxKCZkZXZfcHJpdi0+aXJxX2xvY2spOwo+ID4+PiAgCWRldl9wcml2LT5wbS5f aXJxc19kaXNhYmxlZCA9IGZhbHNlOwo+ID4+PiArCXNwaW5fdW5sb2NrX2lycSgmZGV2X3ByaXYt PmlycV9sb2NrKTsKPiA+Pj4gKwo+ID4+PiAgCWRldi0+ZHJpdmVyLT5pcnFfcHJlaW5zdGFsbChk ZXYpOwo+ID4+PiAgCWRldi0+ZHJpdmVyLT5pcnFfcG9zdGluc3RhbGwoZGV2KTsKPiA+Pj4gIH0K PiA+Pgo+ID4+IFN1cmVseSBzdXJyb3VuZGluZyAod2hhdCBvdWdodCB0byBiZSkgYW4gYXRvbWlj IGFzc2lnbm1lbnQgdG8gYSBzaW5nbGUKPiA+PiB2YXJpYWJsZSBjYW5ub3QgbWFrZSBhIGRpZmZl cmVuY2U/IFVubGVzcyBpdCdzIHRoZSBtZW1vcnkgYmFycmllcgo+ID4+IHNlbWFudGljcyB0aGF0 IGhhdmUgc29tZSBlZmZlY3Q/IEl0IHNlZW1zIHVubGlrZWx5IHRoYXQgdGhlIGNvbXBpbGVyIGhh cwo+ID4+IGRlZmVycmVkIHRoZSB3cml0ZSB0byB0aGUgdmFyaWFibGUgcGFzdCB0aGUgcHJlL3Bv c3RpbnN0YWxsIGNhbGxzIHRoYXQKPiA+PiBhY3R1YWxseSBlbmFibGUgdGhlIGgvdyBpbnRlcnJ1 cHRzLCBidXQgbWF5YmUgd2Ugc2hvdWxkIGFkZCAidm9sYXRpbGUiCj4gPj4ganVzdCBpbiBjYXNl Pwo+ID4gCj4gPiBzcGlubG9ja3MgYWxzbyBzZXJ2ZSBhcyBhIG1lbW9yeSBiYXJyaWVyLiB2b2xh dGlsZSB3b3VsZCBndWFyYW50ZWUgb25seQo+ID4gdGhhdCB0aGUgY29tcGlsZXIgZG9lc24ndCBy ZW9yZGVyIHRoZSB3cml0ZSwgc28gaXQgd291bGRuJ3QgYmUgZW5vdWdoCj4gPiBhbG9uZS4gT3Rv aCwgd2UgbWF5IGFsc28gbmVlZCB0byBhZGQgc3BpbmxvY2tpbmcgdG8gdGhlIGludGVycnVwdAo+ ID4gaGFuZGxlciBpZiB0aGUgaXNzdWUgdHVybnMgb3V0IHRvIGJlIHRoYXQgd2UgY2FuJ3QgYWNj ZXNzIHNvbWUgcmVnaXN0ZXIKPiA+IHBhc3QvYmVmb3JlIGludGVsX3J1bnRpbWVfcG1fe2Rpc2Fi bGUsZW5hYmxlfV9pbnRlcnJ1cHRzLgo+ID4gCj4gPiAtLUltcmUKPiAKPiBJZiB3ZSB3ZXJlIGdl dHRpbmcgaW50ZXJydXB0cyBkdXJpbmcgdGhlIGVuYWJsaW5nIHNlcXVlbmNlLCB0aGVyZSB3b3Vs ZAo+IGJlIHRocmVlIHBvc3NpYmlsaXRpZXM6Cj4gMS4JY29tcGlsZXIgaGFzIGRlbGF5ZWQgd3Jp dGViYWNrLiBUaGlzIHdvdWxkIGJlIGEgY29tcGlsZXIgYnVnCj4gCShJTUhPKSBidXQgJ3ZvbGF0 aWxlJyBtaWdodCBmaXggaXQuCj4gMi4JdGhlICdyZXN0b3JlJyB0aHJlYWQgaGFzIHdyaXR0ZW4g dGhlIHZhbHVlLCBidXQgaXQgaXNuJ3Qgc2Vlbgo+IAlieSB0aGUgdGhyZWFkIGhhbmRsaW5nIHRo ZSBpbnRlcnJ1cHQgKG9uIGEgZGlmZmVyZW50IGNwdT8pLgo+IAlUaGlzIHdvdWxkIGJlIGEgY29o ZXJlbmN5IGlzc3VlLCBhbmQgYSBtZW1vcnkgYmFycmllciBzaG91bGQKPiAJZml4IGl0LiBCdXQg SSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRoZSB2YXJpYWJsZSB0byBiZSBpbgo+IAljb2hlcmVudCBt ZW1vcnkgYW55d2F5Lgo+IDMuCXRoZSBHUFUgaC93IHNlbmRpbmcgaW50ZXJydXB0cyBiZWZvcmUg dGhleSdyZSBlbmFibGVkIDooCgpGb3IgZW5hYmxpbmcgSSB3YW50IHRvIG1ha2Ugc3VyZSBfaXJx c19kaXNhYmxlZD1mYWxzZSBpcyBzdG9yZWQgdG8KbWVtb3J5IGJlZm9yZSB0aGUgaW50ZXJydXB0 IGhhbmRsZXIgY2FuIHJ1bi4gVGhpcyBmbGFnIGlzIGluIG5vcm1hbAp3cml0ZS1iYWNrIG1lbW9y eSwgaGVuY2UgeW91IG5lZWQgYSBtZW1vcnkgYmFycmllciB3aGljaCBpcyBwcm92aWRlZCBieQp0 aGUgc3BpbiBsb2NrLiBJIGNvdWxkIGhhdmUgYWxzbyB1c2VkIGhlcmUgbWIoKSBvciByZWx5IG9u IHRoZSBpbXBsaWNpdAptZW1vcnkgYmFycmllciBvZiB0aGUgaW93cml0ZSBpbiBwcmVpbnN0YWxs L3Bvc3RpbnN0YWxsIGhvb2tzOyBJIGRpZG4ndApzaW5jZSBhcyBJIHNhaWQgd2UgbWF5IHdhbnQg dG8gYWRkIHNwaW4gbG9ja2luZyB0byB0aGUgaXJxIGhhbmRsZXIgdG9vCmFueXdheS4KCj4gQnV0 IEkgc3VzcGVjdCB0aGlzIG1pZ2h0IGJlIGR1cmluZyAqZGlzYWJsaW5nKiB0aGUgaW50ZXJydXB0 LiBQb3NzaWJseSBhCj4gcmFjZSBjb25kaXRpb24gaW4gd2hpY2ggdGhlIGgvdyBoYXMgYWxyZWFk eSBnZW5lcmF0ZWQgYW4gaW50ZXJydXB0Cj4gYmVmb3JlIGl0J3MgZGlzYWJsZWQsIGJ1dCB0aGF0 IGludGVycnVwdCBoYXMgbm90IHlldCBiZWVuIGZpZWxkZWQ7IHNvCj4gdGhhdCBieSB0aGUgdGlt ZSB0aGUgaW50ZXJydXB0IGhhbmRsZXIgcnVucyAob24gYSBkaWZmZXJlbnQgQ1BVIGZyb20gdGhl Cj4gJ3N1c3BlbmQnIHRocmVhZCksIHRoZSB3cml0ZSB0byB0aGUgdmFyaWFibGUgY2FuIGhhdmUg aGFwcGVuZWQgYW5kIHRoZW4KPiB0aGUgbmV3IHZhbHVlIGlzIHNlZW4gYnkgdGhlIGludGVycnVw dCBoYW5kbGVyLgo+IAo+IEluIHdoaWNoIGNhc2UgdGhlIHR3ZWFrIGFib3ZlIHdpbGwgcmVkdWNl IGJ1dCBub3QgbmVjZXNzYXJpbHkgZWxpbWluYXRlCj4gdGhlIHdpbmRvdzsgaXQgd2lsbCBlbnN1 cmUgdGhhdCBpZiB0aGUgaGFuZGxlciBoYXMgZ290IGF0IGxlYXN0IGFzIGZhcgo+IGFzIHRha2lu ZyB0aGUgc3BpbmxvY2sgYmVmb3JlIHRoZSBzdXNwZW5kIHRocmVhZCwgdGhlbiB0aGUgd3JpdGUg d2lsbCBiZQo+IGRlbGF5ZWQgdW50aWwgdGhlIGhhbmRsZXIgaGFzIGZpbmlzaGVkLiBPVE9IIGlm IHRoZSBpbnRlcnJ1cHQgd2VyZQo+IGRlbGF5ZWQgYSBsaXR0bGUgYml0IG1vcmUsIHRoaXMgY29k ZSBtaWdodCBzdGlsbCBnZXQgdG8gdGFrZSB0aGUKPiBzcGlubG9jayBiZWZvcmUgdGhlIGhhbmRs ZXIsIHNvIHRoZSB1bmV4cGVjdGVkIHZhbHVlIHdvdWxkIHN0aWxsIGJlIHNlZW4gOigKPiAKPiBN YXliZSB5b3UgbmVlZCBhIHR3by1waGFzZSB1bmluc3RhbGw/CgpJbiBjYXNlIHdlIGFkZCB0aGUg bG9ja2luZyB0byB0aGUgaW50ZXJydXB0IGhhbmRsZXIgdG9vLCBpdCBkb2Vzbid0Cm1hdHRlciBo b3cgbXVjaCB0aGUgaGFuZGxlciBpcyBkZWxheWVkLiBXZSBhcmUgZWl0aGVyIGJlZm9yZSB0YWtp bmcgdGhlCmxvY2sgaW4gaW50ZWxfcnVudGltZV9wbV9kaXNhYmxlX2ludGVycnVwdHMoKSBhbmQg c28gdGhlIGhhbmRsZXIgd2lsbApzZWUgX2lycXNfZGlzYWJsZWQ9ZmFsc2UsIG9yIHdlIGFyZSBh ZnRlciByZWxlYXNpbmcgdGhlIGxvY2sgaW4KaW50ZWxfcnVudGltZV9wbV9kaXNhYmxlX2ludGVy cnVwdHMoKSBhbmQgdGhlIGhhbmRsZXIgd2lsbCBzZWUKX2lycXNfZGlzYWJsZWQ9dHJ1ZSBhbmQg anVzdCByZXR1cm4gd2l0aG91dCBkb2luZyBhbnl0aGluZy4KCkJ1dCB0aGlzIHBhdGNoIG1ha2Vz IGFscmVhZHkgc3VyZSB0aGF0IHRoZSBoYW5kbGVyIHdpbGwgc2VlCl9pcnFzX2Rpc2FibGVkPXRy dWUgZXZlbnR1YWxseSBhbmQgSSB0aGluayB0aGF0J3MgZW5vdWdoIGZvciB0aGlzIHRlc3QuCgot LUltcmUKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpk cmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0 cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752006AbbBSQjk (ORCPT ); Thu, 19 Feb 2015 11:39:40 -0500 Received: from mga03.intel.com ([134.134.136.65]:35092 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751562AbbBSQjj (ORCPT ); Thu, 19 Feb 2015 11:39:39 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,609,1418112000"; d="scan'208";a="654423252" Message-ID: <1424363975.19250.5.camel@intel.com> Subject: Re: [Intel-gfx] [KERNEL] Regression bug in drm/i915, Wrong assumption in commit e11aa36 breaks suspend on at least lenovo x61 From: Imre Deak Reply-To: imre.deak@intel.com To: Dave Gordon Cc: Jani Nikula , Klaus Ethgen , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , dri-devel Date: Thu, 19 Feb 2015 18:39:35 +0200 In-Reply-To: <54E60450.9010605@intel.com> References: <20150211113919.GA5672@ikki.ethgen.ch> <20150216221142.GB14602@ikki.ethgen.ch> <20150217082937.GA27873@ikki.ethgen.ch> <87mw4bw7o7.fsf@intel.com> <1424276692.27236.1.camel@intel.com> <54E5BF59.4020208@intel.com> <1424344107.3496.10.camel@ideak-mobl> <54E60450.9010605@intel.com> Organization: Intel Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On to, 2015-02-19 at 15:42 +0000, Dave Gordon wrote: > On 19/02/15 11:08, Deak, Imre wrote: > > On Thu, 2015-02-19 at 10:47 +0000, Dave Gordon wrote: > >> On 18/02/15 16:24, Imre Deak wrote: > >>> On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote: > >>>> On Tue, 17 Feb 2015, Klaus Ethgen wrote: > >>>>> After solving the conflicts, I applied the revert (see attachment) to > >>>>> v3.18.7. I think it should also apply to the current head. With that > >>>>> patch, suspend is working again on that version. > >>>>> > >>>>> However, I have not to deep knowledge of that subsystem, so please, > >>>>> someone who have, have a deeper look into it. I especially do not know > >>>>> if the lines in .../intel_pm.c are correct or better leaving them as > >>>>> they are in v3.18.7. > >>>>> > >>>>> I want to have it working on a version that I know is stable before > >>>>> asking to pull it to head. > >>>> > >>>> Hi Klaus, we fear this patch may hide the actual cause. Would be useful > >>>> to get a better description of what happens, along with a dmesg with > >>>> drm.debug=14 module parameter set. This might clutter the mailing list, > >>>> would you mind filing a bug at [1] and attach the info there? > >>>> > >>>> Thanks, > >>>> Jani. > >>>> > >>>> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel > >>> > >>> In addition to the above could you also try the following patch and > >>> provide a dmesg log on the bugzilla ticket - at this point only to try > >>> to narrow down the issue?: > >>> > >>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > >>> index d358ce8..02c65f4 100644 > >>> --- a/drivers/gpu/drm/i915/i915_irq.c > >>> +++ b/drivers/gpu/drm/i915/i915_irq.c > >>> @@ -4466,6 +4466,14 @@ static irqreturn_t i965_irq_handler(int irq, void *arg) > >>> I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT | > >>> I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT; > >>> > >>> + if (!intel_irqs_enabled(dev_priv)) { > >>> + if (printk_ratelimit()) > >>> + DRM_ERROR("spurious/shared interrupt iir %08x imr %08x ier %08x\n", > >>> + I915_READ(IIR), I915_READ(IMR), I915_READ(IER)); > >>> + > >>> + return IRQ_NONE; > >>> + } > >>> + > >>> iir = I915_READ(IIR); > >>> > >>> for (;;) { > >>> @@ -4766,7 +4774,10 @@ void intel_runtime_pm_disable_interrupts(struct drm_device *dev) > >>> struct drm_i915_private *dev_priv = dev->dev_private; > >>> > >>> dev->driver->irq_uninstall(dev); > >>> + > >>> + spin_lock_irq(&dev_priv->irq_lock); > >>> dev_priv->pm._irqs_disabled = true; > >>> + spin_unlock_irq(&dev_priv->irq_lock); > >>> } > >>> > >>> /* Restore interrupts so we can recover from runtime PM. */ > >>> @@ -4774,7 +4785,10 @@ void intel_runtime_pm_restore_interrupts(struct drm_device *dev) > >>> { > >>> struct drm_i915_private *dev_priv = dev->dev_private; > >>> > >>> + spin_lock_irq(&dev_priv->irq_lock); > >>> dev_priv->pm._irqs_disabled = false; > >>> + spin_unlock_irq(&dev_priv->irq_lock); > >>> + > >>> dev->driver->irq_preinstall(dev); > >>> dev->driver->irq_postinstall(dev); > >>> } > >> > >> Surely surrounding (what ought to be) an atomic assignment to a single > >> variable cannot make a difference? Unless it's the memory barrier > >> semantics that have some effect? It seems unlikely that the compiler has > >> deferred the write to the variable past the pre/postinstall calls that > >> actually enable the h/w interrupts, but maybe we should add "volatile" > >> just in case? > > > > spinlocks also serve as a memory barrier. volatile would guarantee only > > that the compiler doesn't reorder the write, so it wouldn't be enough > > alone. Otoh, we may also need to add spinlocking to the interrupt > > handler if the issue turns out to be that we can't access some register > > past/before intel_runtime_pm_{disable,enable}_interrupts. > > > > --Imre > > If we were getting interrupts during the enabling sequence, there would > be three possibilities: > 1. compiler has delayed writeback. This would be a compiler bug > (IMHO) but 'volatile' might fix it. > 2. the 'restore' thread has written the value, but it isn't seen > by the thread handling the interrupt (on a different cpu?). > This would be a coherency issue, and a memory barrier should > fix it. But I would have expected the variable to be in > coherent memory anyway. > 3. the GPU h/w sending interrupts before they're enabled :( For enabling I want to make sure _irqs_disabled=false is stored to memory before the interrupt handler can run. This flag is in normal write-back memory, hence you need a memory barrier which is provided by the spin lock. I could have also used here mb() or rely on the implicit memory barrier of the iowrite in preinstall/postinstall hooks; I didn't since as I said we may want to add spin locking to the irq handler too anyway. > But I suspect this might be during *disabling* the interrupt. Possibly a > race condition in which the h/w has already generated an interrupt > before it's disabled, but that interrupt has not yet been fielded; so > that by the time the interrupt handler runs (on a different CPU from the > 'suspend' thread), the write to the variable can have happened and then > the new value is seen by the interrupt handler. > > In which case the tweak above will reduce but not necessarily eliminate > the window; it will ensure that if the handler has got at least as far > as taking the spinlock before the suspend thread, then the write will be > delayed until the handler has finished. OTOH if the interrupt were > delayed a little bit more, this code might still get to take the > spinlock before the handler, so the unexpected value would still be seen :( > > Maybe you need a two-phase uninstall? In case we add the locking to the interrupt handler too, it doesn't matter how much the handler is delayed. We are either before taking the lock in intel_runtime_pm_disable_interrupts() and so the handler will see _irqs_disabled=false, or we are after releasing the lock in intel_runtime_pm_disable_interrupts() and the handler will see _irqs_disabled=true and just return without doing anything. But this patch makes already sure that the handler will see _irqs_disabled=true eventually and I think that's enough for this test. --Imre