From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Lu Subject: Re: [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices Date: Mon, 08 Dec 2014 09:58:42 +0800 Message-ID: <548505D2.8030904@intel.com> References: <52FAE504.8020001@intel.com> <20140212103156.GC5298@nuc-i3427.alporthouse.com> <52FC8C01.1040002@intel.com> <20140213100814.GM14909@nuc-i3427.alporthouse.com> <53045DD1.5010406@intel.com> <20140219073339.GA30685@srcf.ucam.org> <5304725A.3020909@intel.com> <20140304144504.GE17001@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20140304144504.GE17001@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter , Matthew Garrett , Chris Wilson , Jani Nikula Cc: "intel-gfx@lists.freedesktop.org" , jaime.91@hotmail.es, "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Oleksij Rempel , ACPI Devel Mailing List List-Id: linux-acpi@vger.kernel.org V2UgaGF2ZSBhIG5ldyBidWcgcmVwb3J0IHRoYXQgaGFzIHRoZSBzYW1lIHByb2JsZW06Cmh0dHBz Oi8vYnVnemlsbGEua2VybmVsLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9ODg5NDEKClRoZSBwb3N0ZWQg cGF0Y2ggc29sdmVzIHRoZSBwcm9ibGVtLiBJIGtub3cgaXQncyBub3QgcGVyZmVjdCwgYnV0IGl0 CmRvZXNuJ3Qgc2VlbSBpdCB3b3VsZCBkbyBhbnkgaGFybSB0byBleGlzdGluZyBzeXN0ZW1zIHNv IHNob3VsZCBiZSBzYWZlLgoKQmV0dGVyLCBpZiBzb21lb25lIGNhbiBzaGVkIHNvbWUgbGlnaHQg b24gaG93IHRoaXMgc2hvdWxkIGJlIHByb3Blcmx5CmhhbmRsZWQsIHRoYXQgd291bGQgYmUgZ3Jl YXQuCgpUaGFua3MsCkFhcm9uCgpPbiAwMy8wNC8yMDE0IDEwOjQ1IFBNLCBEYW5pZWwgVmV0dGVy IHdyb3RlOgo+IE9uIFdlZCwgRmViIDE5LCAyMDE0IGF0IDA0OjU5OjA2UE0gKzA4MDAsIEFhcm9u IEx1IHdyb3RlOgo+PiBPbiAwMi8xOS8yMDE0IDAzOjMzIFBNLCBNYXR0aGV3IEdhcnJldHQgd3Jv dGU6Cj4+PiBPbiBXZWQsIEZlYiAxOSwgMjAxNCBhdCAwMzozMToyOVBNICswODAwLCBBYXJvbiBM dSB3cm90ZToKPj4+Cj4+Pj4gRElEMiBpcyBpbiBzeXN0ZW0gbWVtb3J5IHJlZ2lvbiBhbmQgaGFz IHNvbWUgYXNzaWduZWQgdmFsdWUgbGlrZSAweDQwMAo+Pj4+IHdoZW4gd2UgcmVhZCBpdC4gRm9y IHRoaXMgY2FzZSBpdCBpcyBlYXN5IHNpbmNlIHRoZXJlIGlzIG9ubHkgb25lIG91dHB1dAo+Pj4+ IGRldmljZSB0aGF0IGlzIG9mIHR5cGUgTFZEUyBzbyB3ZSBjYW4gbWF0Y2ggaXQgdG8gY29ubmVj dG9yIG9mIHR5cGUgZURQCj4+Pj4gb3IgTFZEUywgc3VwcG9zZSB0aGVyZSBpcyBvbmx5IG9uZSBz dWNoIGNvbm5lY3Rvci4gQnV0IGZvciBvdXRwdXQKPj4+PiBkZXZpY2VzJyB3aG9zZSBfQURSIGhh cyB0aGUgdmFsdWUgb2YgMHgzMDEsIDB4MzAyLCBldGMuIEkgaGF2ZSBubyBpZGVhCj4+Pj4gaG93 IHRvIG1hdGNoIHRoZW0gdXAgdG8gdGhlIGNvbm5lY3RvcnMgb2YgdGhhdCB0eXBlIGFzIHdlIGNh bid0IGJlIHN1cmUKPj4+PiB0aGUgcHJvYmUgb3JkZXIgd2UgaGF2ZSB1c2VkIGluIGk5MTUgZHJp dmVyIGlzIHRoZSBzYW1lIGFzIEJJT1MnLgo+Pj4KPj4+IE5vbi1zdGFuZGFyZCBfQURSIHZhbHVl cyBhcmUgYXNzaWdlbmQgYnkgdGhlIEdQVSB2ZW5kb3IsIHNvIEludGVsIHNob3VsZCAKPj4+IGJl IGFibGUgdG8gcHJvdmlkZSB5b3Ugd2l0aCB0aGUgY29ycmVjdCBpbnRlcnByZXRhdGlvbnMuCj4+ Cj4+IEl0IGRvZXNuJ3Qgc2VlbSB0aGUgX0FEUiB2YWx1ZSBoYXMgdG8gYmUgdGhlIGZvcm1hdCBk ZWZpbmVkIGJ5IF9ET0QsIGFzCj4+IHRoZSBleGFtcGxlIG9mIHRoZSBBQ1BJIHNwZWMgZ2l2ZXM6 Cj4+IE1ldGhvZCAoX0FEUiwgMCkgewo+PiAgICAgcmV0dXJuKDB4MDEwMCkKPj4gfQo+PiBTbyB0 aGF0IGlzIG5vdCB0aGUgcHJvYmxlbSBoZXJlLgo+Pgo+PiBUaGUgcHJvYmxlbSBpcywgd2UgZG9u J3QgaGF2ZSBhbnkgd2F5IG9mIG1hdGNoaW5nIGFuIEFDUEkgb3V0cHV0IGRldmljZQo+PiBub2Rl IHRvIGEgZHJtIGNvbm5lY3RvciBvZiB0aGUgc2FtZSB0eXBlIHdoZW4gdGhlcmUgYXJlIG1vcmUg dGhhbiAxIG9mCj4+IHRob3NlIHdpdGggdGhlIHNhbWUgdHlwZSwgaS5lLiB3ZSBkb24ndCBrbm93 IGhvdyB0aGUgaW5kZXggdmFsdWUgYXJlCj4+IGFzc2lnbmVkIGJ5IEJJT1MuCj4gCj4gSSd2ZSB0 aG91Z2h0IHRoZSBPcFJlZ2lvbiBzcGVjIGhhcyBzb21lIGFkZGl0aW9uYWwgZmllbGRzIGluIHRo ZXJlCj4gaW5kaWNhdGluZyB0aGUgcG9ydCBudW1iZXIsIHdoaWNoIHdlIGNvdWxkIG1hdGNoIHVw IGF0IGxlYXN0IG9uIG1vZGVybgo+IHBsYXRmb3JtcyAod2hlcmUgdGhlcmUncyBvbmx5IGV2ZXIg cG9ydCBBLUUpLiBCdXQgdGhhdCdzIHZlcnkgaGF6eQo+IHJlY29sbGVjdGlvbiBmcm9tIGEgcmVh bGx5IG9sZCBPcFJlZ2lvbiBzcGVjLCBpLmUuIEkgaGF2ZSBubyBibG9vZHkgY2x1ZQo+IGF0IGFs bCA7LSkKPiAKPiBJZiBJIG1pc3JlbWVtYmVyIHRoaXMgdGhlbiB3ZSBuZWVkIHRvIHN0YXJ0IG9u IGEgYmVnZ2luZyB0b3VyIGFnYWluIGFuZAo+IGFzayB0aGUgd2luZG93cyBndXlzIGhvdyB0aGlz IGlzIGFsbCBzdXBwb3NlZCB0byB3b3JrIC4uLgo+IC1EYW5pZWwKPiAKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkludGVsLWdmeCBtYWlsaW5nIGxpc3QK SW50ZWwtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Au b3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753875AbaLHB6r (ORCPT ); Sun, 7 Dec 2014 20:58:47 -0500 Received: from mga01.intel.com ([192.55.52.88]:20641 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752674AbaLHB6p (ORCPT ); Sun, 7 Dec 2014 20:58:45 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,535,1413270000"; d="scan'208";a="643972602" Message-ID: <548505D2.8030904@intel.com> Date: Mon, 08 Dec 2014 09:58:42 +0800 From: Aaron Lu MIME-Version: 1.0 To: Daniel Vetter , Matthew Garrett , Chris Wilson , Jani Nikula CC: "Rafael J. Wysocki" , Oleksij Rempel , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , ACPI Devel Mailing List , jaime.91@hotmail.es Subject: Re: [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices References: <52FAE504.8020001@intel.com> <20140212103156.GC5298@nuc-i3427.alporthouse.com> <52FC8C01.1040002@intel.com> <20140213100814.GM14909@nuc-i3427.alporthouse.com> <53045DD1.5010406@intel.com> <20140219073339.GA30685@srcf.ucam.org> <5304725A.3020909@intel.com> <20140304144504.GE17001@phenom.ffwll.local> In-Reply-To: <20140304144504.GE17001@phenom.ffwll.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We have a new bug report that has the same problem: https://bugzilla.kernel.org/show_bug.cgi?id=88941 The posted patch solves the problem. I know it's not perfect, but it doesn't seem it would do any harm to existing systems so should be safe. Better, if someone can shed some light on how this should be properly handled, that would be great. Thanks, Aaron On 03/04/2014 10:45 PM, Daniel Vetter wrote: > On Wed, Feb 19, 2014 at 04:59:06PM +0800, Aaron Lu wrote: >> On 02/19/2014 03:33 PM, Matthew Garrett wrote: >>> On Wed, Feb 19, 2014 at 03:31:29PM +0800, Aaron Lu wrote: >>> >>>> DID2 is in system memory region and has some assigned value like 0x400 >>>> when we read it. For this case it is easy since there is only one output >>>> device that is of type LVDS so we can match it to connector of type eDP >>>> or LVDS, suppose there is only one such connector. But for output >>>> devices' whose _ADR has the value of 0x301, 0x302, etc. I have no idea >>>> how to match them up to the connectors of that type as we can't be sure >>>> the probe order we have used in i915 driver is the same as BIOS'. >>> >>> Non-standard _ADR values are assigend by the GPU vendor, so Intel should >>> be able to provide you with the correct interpretations. >> >> It doesn't seem the _ADR value has to be the format defined by _DOD, as >> the example of the ACPI spec gives: >> Method (_ADR, 0) { >> return(0x0100) >> } >> So that is not the problem here. >> >> The problem is, we don't have any way of matching an ACPI output device >> node to a drm connector of the same type when there are more than 1 of >> those with the same type, i.e. we don't know how the index value are >> assigned by BIOS. > > I've thought the OpRegion spec has some additional fields in there > indicating the port number, which we could match up at least on modern > platforms (where there's only ever port A-E). But that's very hazy > recollection from a really old OpRegion spec, i.e. I have no bloody clue > at all ;-) > > If I misremember this then we need to start on a begging tour again and > ask the windows guys how this is all supposed to work ... > -Daniel >