ACPI patches for 2.6.25-rc6

Here is the current queue for 2.6.25-rc6

thanks,
-Len

From: Venki Pallipadi <[email protected]>

This avoids the harmless WARNING by lockdep in acpi_processor_idle().

The reason for WARNING is because at the depth of idle handling code, some of the idle handlers disable interrupts, some times, while returning from the idle handler. After return, acpi_processor_idle and few other routines in the file did an unconditional local_irq_enable(). With LOCKDEP, enabling irq when it is already enabled generates the below WARNING.

---
 drivers/acpi/processor_idle.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

index 6f3b217..e8e2d88 100644
@@ -216,8 +216,10 @@ static void acpi_safe_halt(void)
 	 * test NEED_RESCHED:
 	 */
 	smp_mb();
-	if (!need_resched())
+	if (!need_resched()) {
 		safe_halt();
+		local_irq_disable();
+	}
 	current_thread_info()->status |= TS_POLLING;
 }
 

@@ -421,7 +423,9 @@ static void acpi_processor_idle(void)
 		else
 			acpi_safe_halt();
 
-		local_irq_enable();
+		if (irqs_disabled())
+			local_irq_enable();
+
 		return;
 	}
 

@@ -530,7 +534,9 @@ static void acpi_processor_idle(void)
 		 *       skew otherwise.
 		 */
 		sleep_ticks = 0xFFFFFFFF;
-		local_irq_enable();
+		if (irqs_disabled())
+			local_irq_enable();
+
 		break;
 
 	case ACPI_STATE_C2:

1.5.5.rc0.6.gdeda

From: Alexey Starikovskiy <[email protected]>

Acer BIOS has a bug which is exposed when a dead battery is present.

The package template that is used to describe battery status is over-written with sane values when the battery is live. But when the batter is dead, a bogus reference in the template is used. In this case, Linux returns a fault, when instead it should simply return that it doesn't know the missing value.

http://bugzilla.kernel.org/show_bug.cgi?id=8573
http://bugzilla.kernel.org/show_bug.cgi?id=10202

---
 drivers/acpi/battery.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

index f6215e8..d5729d5 100644
@@ -293,13 +293,12 @@ static int extract_package(struct acpi_battery *battery,
 				strncpy(ptr, (u8 *)&element->integer.value,
 					sizeof(acpi_integer));
 				ptr[sizeof(acpi_integer)] = 0;
-			} else return -EFAULT;
+			} else
+				*ptr = 0; /* don't have value */
 		} else {
-			if (element->type == ACPI_TYPE_INTEGER) {
-				int *x = (int *)((u8 *)battery +
-						offsets[i].offset);
-				*x = element->integer.value;
-			} else return -EFAULT;
+			int *x = (int *)((u8 *)battery + offsets[i].offset);
+			*x = (element->type == ACPI_TYPE_INTEGER) ?
+				element->integer.value : -1;
 		}
 	}
 	return 0;

1.5.5.rc0.6.gdeda

From: Len Brown <[email protected]>

This reverts commit 3152fb9f11cdd2fd8688c2c5cb805e5c09b53dd9.

This broke libsensors.

---
 Documentation/thermal/sysfs-api.txt |   22 +++---
 drivers/thermal/Kconfig             |    1 -
 drivers/thermal/thermal.c           |  169 ++++++-----------------------------
 3 files changed, 37 insertions(+), 155 deletions(-)

index d9f28be..ba9c2da 100644
@@ -143,10 +143,10 @@ type				Strings which represent the thermal zone type.
 				This is given by thermal zone driver as part of registration.
 				Eg: "ACPI thermal zone" indicates it's a ACPI thermal device
 				RO
-				Required
+				Optional
 
 temp				Current temperature as reported by thermal zone (sensor)
-				Unit: millidegree Celsius
+				Unit: degree Celsius
 				RO
 				Required
 

@@ -163,7 +163,7 @@ mode				One of the predefined values in [kernel, user]
 					  charge of the thermal management.
 
 trip_point_[0-*]_temp		The temperature above which trip point will be fired
-				Unit: millidegree Celsius
+				Unit: degree Celsius
 				RO
 				Optional
 

@@ -193,7 +193,7 @@ type				String which represents the type of device
 				eg. For memory controller device on intel_menlow platform:
 				this should be "Memory controller"
 				RO
-				Required
+				Optional
 
 max_state			The maximum permissible cooling state of this cooling device.
 				RO

@@ -219,16 +219,16 @@ the sys I/F structure will be built like this:
 
 |thermal_zone1:
 	|-----type:			ACPI thermal zone
-	|-----temp:			37000
+	|-----temp:			37
 	|-----mode:			kernel
-	|-----trip_point_0_temp:	100000
+	|-----trip_point_0_temp:	100
 	|-----trip_point_0_type:	critical
-	|-----trip_point_1_temp:	80000
+	|-----trip_point_1_temp:	80
 	|-----trip_point_1_type:	passive
-	|-----trip_point_2_temp:	70000
-	|-----trip_point_2_type:	active0
-	|-----trip_point_3_temp:	60000
-	|-----trip_point_3_type:	active1
+	|-----trip_point_2_temp:	70
+	|-----trip_point_2_type:	active[0]
+	|-----trip_point_3_temp:	60
+	|-----trip_point_3_type:	active[1]
 	|-----cdev0:			--->/sys/class/thermal/cooling_device0
 	|-----cdev0_trip_point:		1	/* cdev0 can be used for passive */
 	|-----cdev1:			--->/sys/class/thermal/cooling_device3

index 3ab313e..69f19f2 100644
@@ -4,7 +4,6 @@
 
 menuconfig THERMAL
 	bool "Generic Thermal sysfs driver"
-	select HWMON
 	default y
 	help
 	  Generic Thermal Sysfs driver offers a generic mechanism for

1.5.5.rc0.6.gdeda

From: Zhang, Rui <[email protected]>

(reverting the previous sysfs patch also reverted a fix
to the thermal units documentation, which is restored by this commit)

The generic thermal driver shows temperature in millidegree Celsius.

---
 Documentation/thermal/sysfs-api.txt |   22 +++++++++++-----------
 1 files changed, 11 insertions(+), 11 deletions(-)

index ba9c2da..d9f28be 100644
@@ -143,10 +143,10 @@ type				Strings which represent the thermal zone type.
 				This is given by thermal zone driver as part of registration.
 				Eg: "ACPI thermal zone" indicates it's a ACPI thermal device
 				RO
-				Optional
+				Required
 
 temp				Current temperature as reported by thermal zone (sensor)
-				Unit: degree Celsius
+				Unit: millidegree Celsius
 				RO
 				Required
 

@@ -163,7 +163,7 @@ mode				One of the predefined values in [kernel, user]
 					  charge of the thermal management.
 
 trip_point_[0-*]_temp		The temperature above which trip point will be fired
-				Unit: degree Celsius
+				Unit: millidegree Celsius
 				RO
 				Optional
 

@@ -193,7 +193,7 @@ type				String which represents the type of device
 				eg. For memory controller device on intel_menlow platform:
 				this should be "Memory controller"
 				RO
-				Optional
+				Required
 
 max_state			The maximum permissible cooling state of this cooling device.
 				RO

@@ -219,16 +219,16 @@ the sys I/F structure will be built like this:
 
 |thermal_zone1:
 	|-----type:			ACPI thermal zone
-	|-----temp:			37
+	|-----temp:			37000
 	|-----mode:			kernel
-	|-----trip_point_0_temp:	100
+	|-----trip_point_0_temp:	100000
 	|-----trip_point_0_type:	critical
-	|-----trip_point_1_temp:	80
+	|-----trip_point_1_temp:	80000
 	|-----trip_point_1_type:	passive
-	|-----trip_point_2_temp:	70
-	|-----trip_point_2_type:	active[0]
-	|-----trip_point_3_temp:	60
-	|-----trip_point_3_type:	active[1]
+	|-----trip_point_2_temp:	70000
+	|-----trip_point_2_type:	active0
+	|-----trip_point_3_temp:	60000
+	|-----trip_point_3_type:	active1
 	|-----cdev0:			--->/sys/class/thermal/cooling_device0
 	|-----cdev0_trip_point:		1	/* cdev0 can be used for passive */
 	|-----cdev1:			--->/sys/class/thermal/cooling_device3

1.5.5.rc0.6.gdeda

From: Len Brown <[email protected]>

The generic thermal I/F gets selected by ACPI_THERMAL -- its only current customer.
it doesn't need to clutter other configs by default.

---
 drivers/thermal/Kconfig |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

index 69f19f2..17e71d5 100644
@@ -4,7 +4,6 @@
 
 menuconfig THERMAL
 	bool "Generic Thermal sysfs driver"
-	default y
 	help
 	  Generic Thermal Sysfs driver offers a generic mechanism for
 	  thermal management. Usually it's made up of one or more thermal

1.5.5.rc0.6.gdeda

From: Len Brown <[email protected]>

This reverts commit 3fa2cdcc45a0176de15cac9dbf4ed2834ebf8932.

http://bugzilla.kernel.org/show_bug.cgi?id=9995

---
 drivers/acpi/video.c |   31 +------------------------------
 1 files changed, 1 insertions(+), 30 deletions(-)

index 1bc0c74..98f1d4e 100644
@@ -807,40 +807,11 @@ static void acpi_video_bus_find_cap(struct acpi_video_bus *video)
 static int acpi_video_bus_check(struct acpi_video_bus *video)
 {
 	acpi_status status = -ENOENT;
-	long device_id;
-	struct device *dev;
-	struct acpi_device *device;
+
 
 	if (!video)
 		return -EINVAL;
 
-	device = video->device;
-
-	status =
-	    acpi_evaluate_integer(device->handle, "_ADR", NULL, &device_id);
-
-	if (!ACPI_SUCCESS(status))
-		return -ENODEV;
-
-	/* We need to attempt to determine whether the _ADR refers to a
-	   PCI device or not. There's no terribly good way to do this,
-	   so the best we can hope for is to assume that there'll never
-	   be a video device in the host bridge */
-	if (device_id >= 0x10000) {
-		/* It looks like a PCI device. Does it exist? */
-		dev = acpi_get_physical_device(device->handle);
-	} else {
-		/* It doesn't look like a PCI device. Does its parent
-		   exist? */
-		acpi_handle phandle;
-		if (acpi_get_parent(device->handle, &phandle))
-			return -ENODEV;
-		dev = acpi_get_physical_device(phandle);
-	}
-	if (!dev)
-		return -ENODEV;
-	put_device(dev);
-
 	/* Since there is no HID, CID and so on for VGA driver, we have
 	 * to check well known required nodes.
 	 */

1.5.5.rc0.6.gdeda

acpi video brightness worked on the T61 before this patch, eg. in 2.6.24. acpi video brightness stopped working when this patch was applied. acpi video brightness works again when this patch (and its clone) were reverted.

IGD isn't part of this discussion, since that support didn't ship in 2.6.24, and isn't shipping in 2.6.25.

Enabling IGD, or any other feature, via OSI on a platform that has already shipped is effectively impossible. It would require every BIOS and every OS to be updated.

Yes, the thinkpad_acpi driver with brightness_enable=1 works.

The thinkpad_acpi driver is really useful.
It provides ways to get to thinkpad features for which no standard interface in Linux currently exists.

However, the thinkpad_acpi driver should not be used to provide features for which a generic method exists.

I understand that a distro may latch onto thinkpad_acpi to get features in the hands of customers as soon as possible. I understand that the transition off of custom solutions is never easy. brightness_enable=1 was added to ease that transition. If you have additional suggestions, please speak up.

This patch was far from obvious, including to Matthew, who created it.

-Len

It worked in a very broken way, by using the Nvidia ACPI graphics device, even you have an Intel graphics card plugged in.

IGD is the reason why this does not work as expected.

The only correct fix (as long as Linux does not support IGD) is a BIOS fix like this:

Nvidia device
_BCM implementation: use_int10
Intel device
if (OSI="IGD")
_BCM implementation: use_IGD
else
_BCM implementation: use_int10

and everything could work fine with the video.c implementation. I just realize that this does not work because we return true for OSI=Windows and these do not know about OSI="IGD".
This must be changed in future (I am still waiting for examples where it really makes sense and does some good to return OSI=Windows). We now are lucky because on ThinkPads the thinkpad_acpi driver can ugly, but easily work around this.
There may pop up other things (e.g. IGD on other machines and whatever other stuff) which will end in a Linux support impasse then.

Now this could get inverted and it would work (it is a bit embarrassing to suggest this to a vendor: Can you please invert the logic because we return true for Windows also)...:
Nvidia device
_BCM implementation: use_int10
Intel device

    if (OSI="NOIGD")

 _BCM implementation: use_int10
else
 _BCM implementation: use_IGD

That vendors are publishing OSI="Linux feature support" in their BIOS is a bit optimistic and we might end up trying to dig in the dark fiddling together things in vendor_acpi drivers as we always did.
But currently there is a move towards Linux also on laptops/workstations and those vendors who care to publish a BIOS which fully works on Linux and always should need the ability to do this.

PCI devices do not have a _STA function.
Therefore one has to look up PCI slot:dev.func and check whether the device is present and really plugged into the board.

Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html