Skip to contentSkip to conversation

i915: fix ACPI _DSM warning

PATCH Applied Peter Wu 2 participants 2 messages Aug 1, 2013 – Aug 5, 2013

Subsystems (2)
DRM drivers Intel i915
lore
Share & tools
lore

Peter Wu

author
#0 lore raw

PATCH 1/1 i915: fix ACPI _DSM warning

Since commit 29a241c (ACPICA: Add argument typechecking for all predefined ACPI names), _DSM parameters are validated which trigger the following warning:

    ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
    ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
    ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
    ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)

As the Intel _DSM method seems to ignore this parameter, let's comply to the ACPI spec and use a Package instead.

Signed-off-by Peter Wu <[email protected]>

---
What is this code useful for? It seems unfinished, all it does it printing some information when a mux is available, but besides that there is no interaction with the driver.

---
 drivers/gpu/drm/i915/intel_acpi.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/intel_acpi.c +8 -6
index bcbbaea..57fe1ae 100644
@@ -28,7 +28,7 @@ static const u8 intel_dsm_guid[] = {
 	0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
 };
 
-static int intel_dsm(acpi_handle handle, int func, int arg)
+static int intel_dsm(acpi_handle handle, int func)
 {
 	struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
 	struct acpi_object_list input;

@@ -46,8 +46,9 @@ static int intel_dsm(acpi_handle handle, int func, int arg)
 	params[1].integer.value = INTEL_DSM_REVISION_ID;
 	params[2].type = ACPI_TYPE_INTEGER;
 	params[2].integer.value = func;
-	params[3].type = ACPI_TYPE_INTEGER;
-	params[3].integer.value = arg;
+	params[3].type = ACPI_TYPE_PACKAGE;
+	params[3].package.count = 0;
+	params[3].package.elements = NULL;
 
 	ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
 	if (ret) {

@@ -151,8 +152,9 @@ static void intel_dsm_platform_mux_info(void)
 	params[1].integer.value = INTEL_DSM_REVISION_ID;
 	params[2].type = ACPI_TYPE_INTEGER;
 	params[2].integer.value = INTEL_DSM_FN_PLATFORM_MUX_INFO;
-	params[3].type = ACPI_TYPE_INTEGER;
-	params[3].integer.value = 0;
+	params[3].type = ACPI_TYPE_PACKAGE;
+	params[3].package.count = 0;
+	params[3].package.elements = NULL;
 
 	ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", &input,
 				   &output);

@@ -205,7 +207,7 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
 		return false;
 	}
 
-	ret = intel_dsm(dhandle, INTEL_DSM_FN_SUPPORTED_FUNCTIONS, 0);
+	ret = intel_dsm(dhandle, INTEL_DSM_FN_SUPPORTED_FUNCTIONS);
 	if (ret < 0) {
 		DRM_DEBUG_KMS("failed to get supported _DSM functions\n");
 		return false;
Signature · 1 line
1.8.3.4
Applied
#1 lore raw
Quoted 9 lines · Peter Wu

Since commit 29a241c (ACPICA: Add argument typechecking for all predefined ACPI names), _DSM parameters are validated which trigger the following warning:

    ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
    ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
    ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
    ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
Quoted 8 lines

As the Intel _DSM method seems to ignore this parameter, let's comply to the ACPI spec and use a Package instead.

Signed-off-by Peter Wu <[email protected]>

---
What is this code useful for? It seems unfinished, all it does it printing some information when a mux is available, but besides that there is no interaction with the driver.

Dunno how it all works exactly, but yours is not the only report:

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32602

Queued for -next, thanks for the patch.
-Daniel

Signature · 3 lines
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch