From: Aaron Lu <aaron.lu@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Oleksij Rempel <linux@rempel-privat.de>,
ACPI Devel Mailing List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices
Date: Thu, 13 Feb 2014 17:10:25 +0800 [thread overview]
Message-ID: <52FC8C01.1040002@intel.com> (raw)
In-Reply-To: <20140212103156.GC5298@nuc-i3427.alporthouse.com>
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?
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index acde2945eb8a..afdd7d84fb32 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -220,11 +220,11 @@ struct opregion_asle {
#define SWSCI_SBCB_POST_VBE_PM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 19)
#define SWSCI_SBCB_ENABLE_DISABLE_AUDIO SWSCI_FUNCTION_CODE(SWSCI_SBCB, 21)
-#define ACPI_OTHER_OUTPUT (0<<8)
-#define ACPI_VGA_OUTPUT (1<<8)
-#define ACPI_TV_OUTPUT (2<<8)
-#define ACPI_DIGITAL_OUTPUT (3<<8)
-#define ACPI_LVDS_OUTPUT (4<<8)
+#define ACPI_OTHER_OUTPUT 0
+#define ACPI_VGA_OUTPUT 1
+#define ACPI_TV_OUTPUT 2
+#define ACPI_DIGITAL_OUTPUT 3
+#define ACPI_LVDS_OUTPUT 4
#define MAX_DSLP 1500
@@ -616,6 +616,7 @@ static void intel_didl_outputs(struct drm_device *dev)
acpi_status status;
u32 temp;
int i = 0;
+ int index[5] = {0};
handle = ACPI_HANDLE(&dev->pdev->dev);
if (!handle || acpi_bus_get_device(handle, &acpi_dev))
@@ -693,8 +694,8 @@ blind_set:
break;
}
temp = ioread32(&opregion->acpi->didl[i]);
- iowrite32(temp | (1<<31) | output_type | i,
- &opregion->acpi->didl[i]);
+ iowrite32(temp | (1<<31) | (output_type << 8) |
+ index[output_type]++, &opregion->acpi->didl[i]);
i++;
}
goto end;
@@ -705,18 +706,44 @@ static void intel_setup_cadls(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_opregion *opregion = &dev_priv->opregion;
int i = 0;
+ int index[5] = {0};
u32 disp_id;
+ struct drm_connector *connector;
+
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ int output_type = ACPI_OTHER_OUTPUT;
- /* Initialize the CADL field by duplicating the DIDL values.
- * Technically, this is not always correct as display outputs may exist,
- * but not active. This initialization is necessary for some Clevo
- * laptops that check this field before processing the brightness and
- * display switching hotkeys. Just like DIDL, CADL is NULL-terminated if
- * there are less than eight devices. */
- do {
- disp_id = ioread32(&opregion->acpi->didl[i]);
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_VGA:
+ case DRM_MODE_CONNECTOR_DVIA:
+ output_type = ACPI_VGA_OUTPUT;
+ break;
+ case DRM_MODE_CONNECTOR_Composite:
+ case DRM_MODE_CONNECTOR_SVIDEO:
+ case DRM_MODE_CONNECTOR_Component:
+ case DRM_MODE_CONNECTOR_9PinDIN:
+ output_type = ACPI_TV_OUTPUT;
+ break;
+ case DRM_MODE_CONNECTOR_DVII:
+ case DRM_MODE_CONNECTOR_DVID:
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ output_type = ACPI_DIGITAL_OUTPUT;
+ break;
+ case DRM_MODE_CONNECTOR_eDP:
+ case DRM_MODE_CONNECTOR_LVDS:
+ output_type = ACPI_LVDS_OUTPUT;
+ break;
+ }
+ disp_id = (opregion->acpi->didl[0] & (1 << 31)) |
+ (output_type << 8) | index[output_type]++;
iowrite32(disp_id, &opregion->acpi->cadl[i]);
- } while (++i < 8 && disp_id != 0);
+ i++;
+ }
+
+ if (i < 8)
+ iowrite32(0, &opregion->acpi->cadl[i]);
}
void intel_opregion_init(struct drm_device *dev)
Thanks,
Aaron
WARNING: multiple messages have this Message-ID (diff)
From: Aaron Lu <aaron.lu@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Jani Nikula <jani.nikula@linux.intel.com>,
"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>
Subject: Re: [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices
Date: Thu, 13 Feb 2014 17:10:25 +0800 [thread overview]
Message-ID: <52FC8C01.1040002@intel.com> (raw)
In-Reply-To: <20140212103156.GC5298@nuc-i3427.alporthouse.com>
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?
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index acde2945eb8a..afdd7d84fb32 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -220,11 +220,11 @@ struct opregion_asle {
#define SWSCI_SBCB_POST_VBE_PM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 19)
#define SWSCI_SBCB_ENABLE_DISABLE_AUDIO SWSCI_FUNCTION_CODE(SWSCI_SBCB, 21)
-#define ACPI_OTHER_OUTPUT (0<<8)
-#define ACPI_VGA_OUTPUT (1<<8)
-#define ACPI_TV_OUTPUT (2<<8)
-#define ACPI_DIGITAL_OUTPUT (3<<8)
-#define ACPI_LVDS_OUTPUT (4<<8)
+#define ACPI_OTHER_OUTPUT 0
+#define ACPI_VGA_OUTPUT 1
+#define ACPI_TV_OUTPUT 2
+#define ACPI_DIGITAL_OUTPUT 3
+#define ACPI_LVDS_OUTPUT 4
#define MAX_DSLP 1500
@@ -616,6 +616,7 @@ static void intel_didl_outputs(struct drm_device *dev)
acpi_status status;
u32 temp;
int i = 0;
+ int index[5] = {0};
handle = ACPI_HANDLE(&dev->pdev->dev);
if (!handle || acpi_bus_get_device(handle, &acpi_dev))
@@ -693,8 +694,8 @@ blind_set:
break;
}
temp = ioread32(&opregion->acpi->didl[i]);
- iowrite32(temp | (1<<31) | output_type | i,
- &opregion->acpi->didl[i]);
+ iowrite32(temp | (1<<31) | (output_type << 8) |
+ index[output_type]++, &opregion->acpi->didl[i]);
i++;
}
goto end;
@@ -705,18 +706,44 @@ static void intel_setup_cadls(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_opregion *opregion = &dev_priv->opregion;
int i = 0;
+ int index[5] = {0};
u32 disp_id;
+ struct drm_connector *connector;
+
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ int output_type = ACPI_OTHER_OUTPUT;
- /* Initialize the CADL field by duplicating the DIDL values.
- * Technically, this is not always correct as display outputs may exist,
- * but not active. This initialization is necessary for some Clevo
- * laptops that check this field before processing the brightness and
- * display switching hotkeys. Just like DIDL, CADL is NULL-terminated if
- * there are less than eight devices. */
- do {
- disp_id = ioread32(&opregion->acpi->didl[i]);
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_VGA:
+ case DRM_MODE_CONNECTOR_DVIA:
+ output_type = ACPI_VGA_OUTPUT;
+ break;
+ case DRM_MODE_CONNECTOR_Composite:
+ case DRM_MODE_CONNECTOR_SVIDEO:
+ case DRM_MODE_CONNECTOR_Component:
+ case DRM_MODE_CONNECTOR_9PinDIN:
+ output_type = ACPI_TV_OUTPUT;
+ break;
+ case DRM_MODE_CONNECTOR_DVII:
+ case DRM_MODE_CONNECTOR_DVID:
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ output_type = ACPI_DIGITAL_OUTPUT;
+ break;
+ case DRM_MODE_CONNECTOR_eDP:
+ case DRM_MODE_CONNECTOR_LVDS:
+ output_type = ACPI_LVDS_OUTPUT;
+ break;
+ }
+ disp_id = (opregion->acpi->didl[0] & (1 << 31)) |
+ (output_type << 8) | index[output_type]++;
iowrite32(disp_id, &opregion->acpi->cadl[i]);
- } while (++i < 8 && disp_id != 0);
+ i++;
+ }
+
+ if (i < 8)
+ iowrite32(0, &opregion->acpi->cadl[i]);
}
void intel_opregion_init(struct drm_device *dev)
Thanks,
Aaron
next prev parent reply other threads:[~2014-02-13 9:10 UTC|newest]
Thread overview: 23+ 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:31 ` Chris Wilson
2014-02-12 10:52 ` Jani Nikula
2014-02-12 10:52 ` Jani Nikula
2014-02-13 9:10 ` Aaron Lu [this message]
2014-02-13 9:10 ` Aaron Lu
2014-02-13 10:08 ` Chris Wilson
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-02-19 8:59 ` Aaron Lu
2014-03-04 14:45 ` Daniel Vetter
2014-12-08 1:58 ` Aaron Lu
2014-12-08 1:58 ` Aaron Lu
2014-12-08 11:00 ` Jani Nikula
2014-12-08 11:00 ` Jani Nikula
2014-12-08 11:04 ` Jani Nikula
2014-12-08 11:04 ` [Intel-gfx] " Jani Nikula
2014-12-09 9:15 ` Aaron Lu
2014-12-09 9:15 ` [Intel-gfx] " 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=52FC8C01.1040002@intel.com \
--to=aaron.lu@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.