Re: [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices

[Jani Nikula <jani.nikula@linux.intel.com>]

On Mon, 08 Dec 2014, Aaron Lu <aaron.lu@intel.com> 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