linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lu@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Jani Nikula <jani.nikula@linux.intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Oleksij Rempel <linux@rempel-privat.de>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ACPI Devel Mailing List <linux-acpi@vger.kernel.org>,
	jaime.91@hotmail.es
Subject: Re: [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices
Date: Mon, 08 Dec 2014 09:58:42 +0800	[thread overview]
Message-ID: <548505D2.8030904@intel.com> (raw)
In-Reply-To: <20140304144504.GE17001@phenom.ffwll.local>

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
> 


  reply	other threads:[~2014-12-08  1:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-12  3:05 [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices Aaron Lu
2014-02-12 10:31 ` Chris Wilson
2014-02-12 10:52   ` Jani Nikula
2014-02-13  9:10   ` Aaron Lu
2014-02-13 10:08     ` Chris Wilson
2014-02-13 12:03       ` Daniel Vetter
2014-02-19  7:31         ` Aaron Lu
2014-02-19  7:33           ` Matthew Garrett
2014-02-19  8:59             ` Aaron Lu
2014-03-04 14:45               ` Daniel Vetter
2014-12-08  1:58                 ` Aaron Lu [this message]
2014-12-08 11:00                   ` Jani Nikula
2014-12-08 11:04                     ` [Intel-gfx] " Jani Nikula
2014-12-09  9:15                       ` Aaron Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=548505D2.8030904@intel.com \
    --to=aaron.lu@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jaime.91@hotmail.es \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rempel-privat.de \
    --cc=mjg59@srcf.ucam.org \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).