ACPICA: simplify SCI_EN workaround

acpi_hw_set_mode() double checks its effectiveness
by calling acpi_hw_get_mode() -- polling up to 3 seconds.

It would be more logical for its caller, acpi_enable()
acpi_enable() to do the double-checking.  (lets assume
that acpi_disable() isn't interesting)

The ACPI specification is unclear on this point.
Some parts say that the BIOS sets SCI_EN and then returns to the OS,
but one part says "OSPM polls the SCI_EN bit until it is sampled SET".

The systems I have on hand do the former,
SCI_EN is observed to be set upon return from the BIOS.

So we move the check up out of acpi_hw_set_mode()
up into acpi_enable() where it makes logical sense.

Then we replace the 3-second polling loop
with a single check.  If this check fails, we'll see:

	"Hardware did not enter ACPI mode"

and the system will bail out of ACPI initialization
and likely fail to boot.  If we see that in practice,
we can restore the polling, but put it into acpi_enable.

This patch is important if acpi_enable() is used in
the resume from S3 path.  Many systems today are seen
coming back from S3 with SCI_EN off, and then failing
to set SCI_EN in response to acpi_enable().  Those systems
will take 3 seconds longer to resume due to this loop.

However, it is possible that we will not use acpi_enable()
in the S3 resume path, and bang SCI_EN directly, which
would make the loop harmless, as it would be invisible
to all systems except those that need it.

Signed-off-by: Len Brown <len.brown@intel.com>

drivers/acpi/acpica/evxfevnt.c

@@ -69,7 +69,7 @@ acpi_ev_get_gpe_device(struct acpi_gpe_xrupt_info *gpe_xrupt_info,
 
 acpi_status acpi_enable(void)
 {
-	acpi_status status = AE_OK;
+	acpi_status status;
 
 	ACPI_FUNCTION_TRACE(acpi_enable);
 
@@ -84,21 +84,30 @@ acpi_status acpi_enable(void)
 	if (acpi_hw_get_mode() == ACPI_SYS_MODE_ACPI) {
 		ACPI_DEBUG_PRINT((ACPI_DB_INIT,
 				  "System is already in ACPI mode\n"));
-	} else {
-		/* Transition to ACPI mode */
+		return_ACPI_STATUS(AE_OK);
+	}
 
-		status = acpi_hw_set_mode(ACPI_SYS_MODE_ACPI);
-		if (ACPI_FAILURE(status)) {
-			ACPI_ERROR((AE_INFO,
-				    "Could not transition to ACPI mode"));
-			return_ACPI_STATUS(status);
-		}
+	/* Transition to ACPI mode */
 
-		ACPI_DEBUG_PRINT((ACPI_DB_INIT,
-				  "Transition to ACPI mode successful\n"));
+	status = acpi_hw_set_mode(ACPI_SYS_MODE_ACPI);
+	if (ACPI_FAILURE(status)) {
+		ACPI_ERROR((AE_INFO,
+			    "Could not transition to ACPI mode"));
+		return_ACPI_STATUS(status);
 	}
 
-	return_ACPI_STATUS(status);
+	/* Sanity check that transition succeeded */
+
+	if (acpi_hw_get_mode() != ACPI_SYS_MODE_ACPI) {
+		ACPI_ERROR((AE_INFO,
+			    "Hardware did not enter ACPI mode"));
+		return_ACPI_STATUS(AE_NO_HARDWARE_RESPONSE);
+	}
+
+	ACPI_DEBUG_PRINT((ACPI_DB_INIT,
+			  "Transition to ACPI mode successful\n"));
+
+	return_ACPI_STATUS(AE_OK);
 }
 
 ACPI_EXPORT_SYMBOL(acpi_enable)

drivers/acpi/acpica/hwacpi.c

@@ -63,7 +63,6 @@ acpi_status acpi_hw_set_mode(u32 mode)
 {
 
 	acpi_status status;
-	u32 retry;
 
 	ACPI_FUNCTION_TRACE(hw_set_mode);
 
@@ -125,24 +124,7 @@ acpi_status acpi_hw_set_mode(u32 mode)
 		return_ACPI_STATUS(status);
 	}
 
-	/*
-	 * Some hardware takes a LONG time to switch modes. Give them 3 sec to
-	 * do so, but allow faster systems to proceed more quickly.
-	 */
-	retry = 3000;
-	while (retry) {
-		if (acpi_hw_get_mode() == mode) {
-			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-					  "Mode %X successfully enabled\n",
-					  mode));
-			return_ACPI_STATUS(AE_OK);
-		}
-		acpi_os_stall(1000);
-		retry--;
-	}
-
-	ACPI_ERROR((AE_INFO, "Hardware did not change modes"));
-	return_ACPI_STATUS(AE_NO_HARDWARE_RESPONSE);
+	return_ACPI_STATUS(AE_OK);
 }
 
 /*******************************************************************************