[lkml]   [2014]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices
    On Thu, Feb 13, 2014 at 11:08 AM, Chris Wilson <> wrote:
    > On Thu, Feb 13, 2014 at 05:10:25PM +0800, Aaron Lu wrote:
    >> On 02/12/2014 06:31 PM, Chris Wilson wrote:
    >> > On Wed, Feb 12, 2014 at 11:05:40AM +0800, Aaron Lu wrote:
    >> >> The ACPI table on ASUS UX302LA has more than 8 output devices under the
    >> >> graphics controller device node. The problem is, the real active output
    >> >> device, the LCD panel, is listed the last. The result is, the LCD's
    >> >> device id doesn't get recorded in the active device list CADL array and
    >> >> when the _DCS control method for the LCD device is executed, it returns
    >> >> 0x1d, meaning it is not active. This affects the hotkey delivery ASL
    >> >> code that will not deliver a notification if the output device is not
    >> >> active on backlight hotkey press.
    >> >>
    >> >> I don't see a clean way to solve this problem since the operation region
    >> >> spec doesn't allow more than 8 output devices so we have no way of
    >> >> storing all these output devices. The fact that output devices that have
    >> >> _BCM control method usually means they have a higher possibility of being
    >> >> used than those who don't made me choose a simple way to work around
    >> >> the buggy firmware by replacing the last entry in CADL array with the one
    >> >> that has _BCM control method. There is no specific reason why the last
    >> >> entry is picked instead of others.
    >> >
    >> > Another possibility is that the connector list is in rough priority
    >> > order so might be useful for sorting the CADL array.
    >> >
    >> > Since the CADL should only be a list of currently active devices, we
    >> > could just bite the bullet and repopulate it correctly after every
    >> > setcrtc.
    >> Thanks for the suggestion. As a first step, does the following un-tested
    >> patch look OK?
    > Yes. Maybe worth putting together the similar routines for blind
    > setting the didl and the cadl, or at least for computing the value from
    > the connector. For instance, the didl logic disagrees with the value of
    > index - is that relevant? I have a suspicion that the CADL entry should
    > match the DIDL entry for the connector, but that is not actually
    > mentioned in the opregion spec afaict.

    I think a problem is that often we have more than one output for a
    given type. So we need to somehow match them up to make sure we put
    the right ones intot didl/cadl lists. The issue here is that our
    connectors don't match up perfectly with the acpi output entries
    (since we have separate dp/hdmi outputs). But I think it would be
    worthwhile trying to match them up and store a link from struct
    intel_connector to the right acpi node acpi node.

    Then we could generate the didl/cadl lists by walking all connectors
    (only looking at the enabled ones for cadl) and evaluating the _ADR
    node of the linked apci node. As long as we ensure that we don't have
    duplicated entries we should be fine.

    This is a bit more work though ... And I have no idea really how
    firmware uses these lists (besides for backlight purposes apparently).
    Daniel Vetter
    Software Engineer, Intel Corporation
    +41 (0) 79 365 57 48 -

     \ /
      Last update: 2014-02-13 13:21    [W:0.026 / U:6.636 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site