On Mon, 08 Dec 2014, Aaron Lu <aaron.lu@xxxxxxxxx> wrote: > 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. There was a bug report that I can't find right now that had a similar problem. I wrote a few patches, even somewhat polished ones (that I now pushed to [1] for reference) to handle extended DIDL. Unfortunately this didn't help the bug reporter because the right one was beyond the extended DIDL too, so I don't think I even sent these to the list. Anyway, just one more data point. This might help your reporter, so worth a try. But it doesn't solve everything. BR, Jani. > > 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 >> > -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
