ACPI & driver patches for 2.6.30-rc5

PATCH In review Len Brown 6 participants 35 messages May 16, 2009 – May 26, 2009 1 message not in the archive

Subsystems (8)

DRM drivers DRM misc ACPI x86 platform drivers +4 more subsystems

lore

Share & tools

lore

Len Brown

author reviewer

2009-05-16 06:02 UTC #0 lore raw

here is the queue for upstream right now.

thanks,
-Len

Len Brown

author reviewer

2009-05-16 06:02 UTC #1 lore raw

PATCH 1/19 ACPI video: dmi check for broken _BQC on Acer Aspire 5720

From: Zhang Rui <[email protected]>

On Acer Aspire 5720, _BQC always returns a value 9 smaller than the actual brightness level. Add dmi quirk for this laptop.

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

Tested-by Maxim Levitsky <[email protected]>

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Len Brown <[email protected]>

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

drivers/acpi/video.c +30 -0

index cd4fb75..7e8ee49 100644
@@ -538,6 +538,33 @@ acpi_video_device_lcd_set_level(struct acpi_video_device *device, int level)
 	return -EINVAL;
 }
 
+/*
+ * For some buggy _BQC methods, we need to add a constant value to
+ * the _BQC return value to get the actual current brightness level
+ */
+
+static int bqc_offset_aml_bug_workaround;
+static int __init video_set_bqc_offset(const struct dmi_system_id *d)
+{
+	bqc_offset_aml_bug_workaround = 9;
+	return 0;
+}
+
+static struct dmi_system_id video_dmi_table[] __initdata = {
+	/*
+	 * Broken _BQC workaround http://bugzilla.kernel.org/show_bug.cgi?id=13121
+	 */
+	{
+	 .callback = video_set_bqc_offset,
+	 .ident = "Acer Aspire 5720",
+	 .matches = {
+		DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+		DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5720"),
+		},
+	},
+	{}
+};
+
 static int
 acpi_video_device_lcd_get_level_current(struct acpi_video_device *device,
 					unsigned long long *level)

@@ -557,6 +584,7 @@ acpi_video_device_lcd_get_level_current(struct acpi_video_device *device,
 				*level = device->brightness->levels[*level + 2];
 
 			}
+			*level += bqc_offset_aml_bug_workaround;
 			device->brightness->curr = *level;
 			return 0;
 		} else {

@@ -2287,6 +2315,8 @@ EXPORT_SYMBOL(acpi_video_register);
 
 static int __init acpi_video_init(void)
 {
+	dmi_check_system(video_dmi_table);
+
 	if (intel_opregion_present())
 		return 0;

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #2 lore raw

PATCH 2/19 ACPICA: use acpi.* modparam namespace

In reply to Len Brown

From: Len Brown <[email protected]>

Add acpi/acpica/*.c to the acpi.* modparam namespace so that any modparams we stick into ACPICA do not expose ACPICA filenames to users.

There are currently only two modparams in ACPICA, just recently added for
http://bugzilla.kernel.org/show_bug.cgi?id=13041

With this change, they become

acpi.gts=1
acpi.bfs=1

rather than

hwsleep.gts=1
hwsleep.bfs=1

Signed-off-by Len Brown <[email protected]>

---
 drivers/acpi/acpica/Makefile |   27 +++++++++++++++------------
 1 files changed, 15 insertions(+), 12 deletions(-)

drivers/acpi/acpica/Makefile +15 ~~-12~~

index 17e5082..72ac28d 100644
@@ -5,40 +5,43 @@
 ccflags-y			:= -Os
 ccflags-$(CONFIG_ACPI_DEBUG)	+= -DACPI_DEBUG_OUTPUT
 
-obj-y := dsfield.o   dsmthdat.o  dsopcode.o  dswexec.o  dswscope.o \
+# use acpi.o to put all files here into acpi.o modparam namespace
+obj-y	+= acpi.o
+
+acpi-y := dsfield.o   dsmthdat.o  dsopcode.o  dswexec.o  dswscope.o \
 	 dsmethod.o  dsobject.o  dsutils.o   dswload.o  dswstate.o \
 	 dsinit.o
 
-obj-y += evevent.o  evregion.o  evsci.o    evxfevnt.o \
+acpi-y += evevent.o  evregion.o  evsci.o    evxfevnt.o \
 	 evmisc.o   evrgnini.o  evxface.o  evxfregn.o \
 	 evgpe.o    evgpeblk.o
 
-obj-y += exconfig.o  exfield.o  exnames.o   exoparg6.o  exresolv.o  exstorob.o\
+acpi-y += exconfig.o  exfield.o  exnames.o   exoparg6.o  exresolv.o  exstorob.o\
 	 exconvrt.o  exfldio.o  exoparg1.o  exprep.o    exresop.o   exsystem.o\
 	 excreate.o  exmisc.o   exoparg2.o  exregion.o  exstore.o   exutils.o \
 	 exdump.o    exmutex.o  exoparg3.o  exresnte.o  exstoren.o
 
-obj-y += hwacpi.o  hwgpe.o  hwregs.o  hwsleep.o hwxface.o hwvalid.o
+acpi-y += hwacpi.o  hwgpe.o  hwregs.o  hwsleep.o hwxface.o hwvalid.o
 
-obj-$(ACPI_FUTURE_USAGE) += hwtimer.o
+acpi-$(ACPI_FUTURE_USAGE) += hwtimer.o
 
-obj-y += nsaccess.o  nsload.o    nssearch.o  nsxfeval.o \
+acpi-y += nsaccess.o  nsload.o    nssearch.o  nsxfeval.o \
 	 nsalloc.o   nseval.o    nsnames.o   nsutils.o   nsxfname.o \
 	 nsdump.o    nsinit.o    nsobject.o  nswalk.o    nsxfobj.o  \
 	 nsparse.o   nspredef.o
 
-obj-$(ACPI_FUTURE_USAGE) += nsdumpdv.o
+acpi-$(ACPI_FUTURE_USAGE) += nsdumpdv.o
 
-obj-y += psargs.o    psparse.o  psloop.o pstree.o   pswalk.o  \
+acpi-y += psargs.o    psparse.o  psloop.o pstree.o   pswalk.o  \
 	 psopcode.o  psscope.o  psutils.o  psxface.o
 
-obj-y += rsaddr.o rscreate.o rsinfo.o rsio.o rslist.o rsmisc.o rsxface.o \
+acpi-y += rsaddr.o rscreate.o rsinfo.o rsio.o rslist.o rsmisc.o rsxface.o \
 	 rscalc.o  rsirq.o  rsmemory.o  rsutils.o
 
-obj-$(ACPI_FUTURE_USAGE) += rsdump.o
+acpi-$(ACPI_FUTURE_USAGE) += rsdump.o
 
-obj-y += tbxface.o tbinstal.o tbutils.o tbfind.o tbfadt.o tbxfroot.o
+acpi-y += tbxface.o tbinstal.o tbutils.o tbfind.o tbfadt.o tbxfroot.o
 
-obj-y += utalloc.o utdebug.o uteval.o utinit.o utmisc.o utxface.o \
+acpi-y += utalloc.o utdebug.o uteval.o utinit.o utmisc.o utxface.o \
 		utcopy.o utdelete.o utglobal.o utmath.o utobject.o \
 		utstate.o utmutex.o utobject.o utresrc.o utlock.o

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #3 lore raw

PATCH 3/19 ACPI: video: DMI workaround another broken Acer BIOS enabling display brightness

In reply to Len Brown

From: Len Brown <[email protected]>

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

Signed-off-by Len Brown <[email protected]>

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

drivers/acpi/video.c +8 -0

index 7e8ee49..3a3d156 100644
@@ -562,6 +562,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = {
 		DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5720"),
 		},
 	},
+	{
+	 .callback = video_set_bqc_offset,
+	 .ident = "Acer Aspire 5710Z",
+	 .matches = {
+		DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+		DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5710Z"),
+		},
+	},
 	{}
 };

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #4 lore raw

PATCH 4/19 ACPI: power: update error message

In reply to Len Brown

From: Len Brown <[email protected]>

"Transitioning device [%s] to D%d" is not correct. We print this line when we attempted to transition the device, and it failed.

So instead, print
"Device [%s] failed to transition to D%d\n"

This can happen under two conditions:

1. acpi_power_transition() fails when trying to handle the _ON/_OFF for associated power resource.

2. acpi_evaluate_object() on the explicit _PS0/_PS3 for that actual device could fail.

this change clarifies, but doesn't fix
http://bugzilla.kernel.org/show_bug.cgi?id=13243

Signed-off-by Len Brown <[email protected]>

---
 drivers/acpi/bus.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

drivers/acpi/bus.c +1 -1

index e8f7b64..ae862f1 100644
@@ -312,7 +312,7 @@ int acpi_bus_set_power(acpi_handle handle, int state)
       end:
 	if (result)
 		printk(KERN_WARNING PREFIX
-			      "Transitioning device [%s] to D%d\n",
+			      "Device [%s] failed to transition to D%d\n",
 			      device->pnp.bus_id, state);
 	else {
 		device->power.state = state;

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #5 lore raw

PATCH 5/19 ACPI: suspend: don't let device _PS3 failure prevent suspend

In reply to Len Brown

From: Len Brown <[email protected]>

6328a57401dc5f5cf9931738eb7268fcd8058c49
"Enable PNPACPI _PSx Support, v3"

added a call to acpi_bus_set_power(handle, ACPI_STATE_D3) to pnpacpi_disable_resource() before the existing call to evaluate _DIS on the device.

This caused suspend to fail on the system in
http://bugzilla.kernel.org/show_bug.cgi?id=13243
because the sanity check to verify we entered _PS3 failed on the serial port.

As a work-around, that sanity check can be disabled system-wide with "acpi.power_nocheck=1"

Or perhaps we should just shrug off the _PS3 failure and carry on with _DIS like we used to -- which is what this patch does.

Signed-off-by Len Brown <[email protected]>

---
 drivers/pnp/pnpacpi/core.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

drivers/pnp/pnpacpi/core.c +3 -5

index 9a3a682..9496494 100644
@@ -110,11 +110,9 @@ static int pnpacpi_disable_resources(struct pnp_dev *dev)
 
 	/* acpi_unregister_gsi(pnp_irq(dev, 0)); */
 	ret = 0;
-	if (acpi_bus_power_manageable(handle)) {
-		ret = acpi_bus_set_power(handle, ACPI_STATE_D3);
-		if (ret)
-			return ret;
-	}
+	if (acpi_bus_power_manageable(handle))
+		acpi_bus_set_power(handle, ACPI_STATE_D3);
+		/* continue even if acpi_bus_set_power() fails */
 	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_DIS", NULL, NULL)))
 		ret = -ENODEV;
 	return ret;

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #6 lore raw

PATCH 6/19 eeepc-laptop: fix wlan rfkill state change during init

In reply to Len Brown

From: Alan Jenkins <[email protected]>

When an rfkill device is registered, the rfkill core will change its state to the system default. So we need to prepare for state changes *before* we register it. That means installing the eeepc-specific ACPI callback which handles the hotplug of the wireless network adaptor.

This problem doesn't occur during normal operation. You have to

1) Boot with wireless enabled. eeepc-laptop should load automatically.
2) modprobe -r eeepc-laptop
3) modprobe eeepc-laptop

On boot, the default rfkill state will be set to enabled. With the current core code, step 2) will disable the wireless. Therefore in step 3), the wireless will change state during registration, from disabled to enabled. But without this fix, the PCI device for the wireless adaptor will not appear.

Signed-off-by Alan Jenkins <[email protected]>

Acked-by Matthew Garrett <[email protected]>

Signed-off-by Corentin Chary <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/platform/x86/eeepc-laptop.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

drivers/platform/x86/eeepc-laptop.c +3 -3

index 6f54fd1..e21f7cd 100644
@@ -649,6 +649,9 @@ static int eeepc_hotk_add(struct acpi_device *device)
 	if (ACPI_FAILURE(status))
 		printk(EEEPC_ERR "Error installing notify handler\n");
 
+	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6");
+	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");
+
 	if (get_acpi(CM_ASL_WLAN) != -1) {
 		ehotk->eeepc_wlan_rfkill = rfkill_allocate(&device->dev,
 							   RFKILL_TYPE_WLAN);

@@ -704,9 +707,6 @@ static int eeepc_hotk_add(struct acpi_device *device)
 			goto bluetooth_fail;
 	}
 
-	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6");
-	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");
-
 	return 0;
 
  bluetooth_fail:

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #7 lore raw

PATCH 7/19 eeepc-laptop: report brightness control events via the input layer

In reply to Len Brown

From: Darren Salt <[email protected]>

This maps the brightness control events to one of two keys, either KEY_BRIGHTNESSDOWN or KEY_BRIGHTNESSUP, as needed.

Some mapping has to be done due to the fact that the BIOS reports them as <base value> + <current brightness index>; the selection is done according to the sign of the change in brightness (if this is 0, no keypress is reported).

(Ref. http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-April/002001.html)

Signed-off-by Darren Salt <[email protected]>

Signed-off-by Corentin Chary <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/platform/x86/eeepc-laptop.c |   29 ++++++++++++++++++++++++++---
 1 files changed, 26 insertions(+), 3 deletions(-)

drivers/platform/x86/eeepc-laptop.c +26 -3

index e21f7cd..f54cfea 100644
@@ -166,6 +166,8 @@ static struct key_entry eeepc_keymap[] = {
 	{KE_KEY, 0x1b, KEY_ZOOM },
 	{KE_KEY, 0x1c, KEY_PROG2 },
 	{KE_KEY, 0x1d, KEY_PROG3 },
+	{KE_KEY, NOTIFY_BRN_MIN,     KEY_BRIGHTNESSDOWN },
+	{KE_KEY, NOTIFY_BRN_MIN + 2, KEY_BRIGHTNESSUP },
 	{KE_KEY, 0x30, KEY_SWITCHVIDEOMODE },
 	{KE_KEY, 0x31, KEY_SWITCHVIDEOMODE },
 	{KE_KEY, 0x32, KEY_SWITCHVIDEOMODE },

@@ -512,11 +514,16 @@ static int eeepc_hotk_check(void)
 	return 0;
 }
 
-static void notify_brn(void)
+static int notify_brn(void)
 {
+	/* returns the *previous* brightness, or -1 */
 	struct backlight_device *bd = eeepc_backlight_device;
-	if (bd)
+	if (bd) {
+		int old = bd->props.brightness;
 		bd->props.brightness = read_brightness(bd);
+		return old;
+	}
+	return -1;
 }
 
 static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)

@@ -558,17 +565,33 @@ static void eeepc_hotk_notify(acpi_handle handle, u32 event, void *data)
 {
 	static struct key_entry *key;
 	u16 count;
+	int brn = -ENODEV;
 
 	if (!ehotk)
 		return;
 	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX)
-		notify_brn();
+		brn = notify_brn();
 	count = ehotk->event_count[event % 128]++;
 	acpi_bus_generate_proc_event(ehotk->device, event, count);
 	acpi_bus_generate_netlink_event(ehotk->device->pnp.device_class,
 					dev_name(&ehotk->device->dev), event,
 					count);
 	if (ehotk->inputdev) {
+		if (brn != -ENODEV) {
+			/* brightness-change events need special
+			 * handling for conversion to key events
+			 */
+			if (brn < 0)
+				brn = event;
+			else
+				brn += NOTIFY_BRN_MIN;
+			if (event < brn)
+				event = NOTIFY_BRN_MIN; /* brightness down */
+			else if (event > brn)
+				event = NOTIFY_BRN_MIN + 2; /* ... up */
+			else
+				event = NOTIFY_BRN_MIN + 1; /* ... unchanged */
+		}
 		key = eepc_get_entry_by_scancode(event);
 		if (key) {
 			switch (key->type) {

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #8 lore raw

PATCH 8/19 eeepc-laptop: Work around rfkill firmware bug

In reply to Len Brown

From: Alan Jenkins <[email protected]>

1) Buggy firmware can change the RFKILL state by itself. This is easily detected. The RFKILL API states that in such cases, we should call rfkill_force_state() to notify the core.

I have reported the bug to Asus. I believe this is the right thing to do for robustness, even if this particular firmware bug is fixed.

2) The same bug causes the wireless toggle key to be reported as 0x11 instead of 0x10. 0x11 is otherwise unused, so it should be safe to add this as a new keycode.

The bug is triggered by removing the laptop battery while hibernated.

On resume, the wireless toggle key causes the firmware to toggle the wireless state itself. (Also, the key is reported as 0x11 when the current wireless state is OFF).

This is very poor behaviour because the OS can't predict whether the firmware is controlling the RFKILL state.

Without this workaround, the bug means users have to press the wireless toggle key twice to enable, due to the OS/firmware conflict. (Assuming rfkill-input or equivalent is being used). The workaround avoids this.

I believe that acpid scripts which toggle the value of the sysfs state file when the toggle key is pressed will be rendered ineffective by the bug, regardless of this workaround. If they simply toggle the state, when the firmware has already toggled it, then you will never see a state change.

Tested on "EEEPC 4G" only.

Signed-off-by Alan Jenkins <[email protected]>

Signed-off-by Corentin Chary <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/platform/x86/eeepc-laptop.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

drivers/platform/x86/eeepc-laptop.c +7 -1

index f54cfea..57f21f0 100644
@@ -158,6 +158,7 @@ enum { KE_KEY, KE_END };
 static struct key_entry eeepc_keymap[] = {
 	/* Sleep already handled via generic ACPI code */
 	{KE_KEY, 0x10, KEY_WLAN },
+	{KE_KEY, 0x11, KEY_WLAN },
 	{KE_KEY, 0x12, KEY_PROG1 },
 	{KE_KEY, 0x13, KEY_MUTE },
 	{KE_KEY, 0x14, KEY_VOLUMEDOWN },

@@ -528,6 +529,7 @@ static int notify_brn(void)
 
 static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 {
+	enum rfkill_state state;
 	struct pci_dev *dev;
 	struct pci_bus *bus = pci_find_bus(0, 1);

@@ -539,7 +541,9 @@ static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 		return;
 	}
 
-	if (get_acpi(CM_ASL_WLAN) == 1) {
+	eeepc_wlan_rfkill_state(ehotk->eeepc_wlan_rfkill, &state);
+
+	if (state == RFKILL_STATE_UNBLOCKED) {
 		dev = pci_get_slot(bus, 0);
 		if (dev) {
 			/* Device already present */

@@ -559,6 +563,8 @@ static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 			pci_dev_put(dev);
 		}
 	}
+
+	rfkill_force_state(ehotk->eeepc_wlan_rfkill, state);
 }
 
 static void eeepc_hotk_notify(acpi_handle handle, u32 event, void *data)

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #9 lore raw

PATCH 9/19 eeepc-laptop: support for super hybrid engine (SHE)

In reply to Len Brown

From: Grigori Goronzy <[email protected]>

The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.

The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.

Signed-off-by Grigori Goronzy <[email protected]>

Signed-off-by Corentin Chary <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/platform/x86/eeepc-laptop.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

drivers/platform/x86/eeepc-laptop.c +2 -0

index 57f21f0..7aaf587 100644
@@ -384,11 +384,13 @@ static ssize_t show_sys_acpi(int cm, char *buf)
 EEEPC_CREATE_DEVICE_ATTR(camera, CM_ASL_CAMERA);
 EEEPC_CREATE_DEVICE_ATTR(cardr, CM_ASL_CARDREADER);
 EEEPC_CREATE_DEVICE_ATTR(disp, CM_ASL_DISPLAYSWITCH);
+EEEPC_CREATE_DEVICE_ATTR(cpufv, CM_ASL_CPUFV);
 
 static struct attribute *platform_attributes[] = {
 	&dev_attr_camera.attr,
 	&dev_attr_cardr.attr,
 	&dev_attr_disp.attr,
+	&dev_attr_cpufv.attr,
 	NULL
 };

Signature · 1 line

1.6.0.6

Alan Jenkins

2009-05-24 09:28 UTC #10 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 9 lines · Len Brown

From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.

Quoted 8 lines

The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---

Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.

I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to normal. There is no apparent effect on performance.

This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8 :-).

I think this is the only attribute which needs this treatment. It looks like the SHE feature may have been attempted for the 701 model, but not completed on time.

Thanks!
Alan

Corentin Chary

maintainer

2009-05-24 17:23 UTC #11 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 34 lines · Alan Jenkins

Quoted 9 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.
Quoted 8 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to normal. There is no apparent effect on performance.
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8 :-).

Quoted 7 lines

I think this is the only attribute which needs this treatment. It looks like the SHE feature may have been attempted for the 701 model, but not completed on time.
Thanks!
Alan

Hi,
Thanks for the repport. Can you send me your dsdt ? I can't upgrade my bios right now.
Thanks

Signature · 6 lines

Corentin Chary
http://xf.iksaif.net - http://uffs.org
--
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Corentin Chary

maintainer

2009-05-25 08:13 UTC #13 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 32 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:

Quoted 31 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 28 lines · <[email protected]> wrote:
Quoted 9 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.
Quoted 8 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to normal. There is no apparent effect on performance.

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8

Hi, Can you try this patch ? It seems to works for me.

Quoted 1 line

From c357105fe0016f71d92d7a11500d7cd72b70282f Mon Sep 17 00:00:00 2001

From: Corentin Chary <[email protected]>
Date: Mon, 25 May 2009 10:08:00 +0200
Subject: [PATCH 3/3] eeepc-laptop: Fix cpufv

Limit cpufv input to acceptable values.
Make cpufv output more readable.

According to the dsdt, the value returned by CFVG is composed by the current setting in the first byte and the number of settings (starting from 0) in the second byte.

Signed-off-by Corentin Chary <[email protected]>

---
 drivers/platform/x86/eeepc-laptop.c |   59 ++++++++++++++++++++++++++++++++++-
 1 files changed, 58 insertions(+), 1 deletions(-)

drivers/platform/x86/eeepc-laptop.c +58 -1

index a0845b2..4e1cf2d 100644
@@ -395,7 +395,64 @@ static ssize_t show_sys_acpi(int cm, char *buf)
 EEEPC_CREATE_DEVICE_ATTR(camera, CM_ASL_CAMERA);
 EEEPC_CREATE_DEVICE_ATTR(cardr, CM_ASL_CARDREADER);
 EEEPC_CREATE_DEVICE_ATTR(disp, CM_ASL_DISPLAYSWITCH);
-EEEPC_CREATE_DEVICE_ATTR(cpufv, CM_ASL_CPUFV);
+
+struct eeepc_cpufv
+{
+	int num;
+	int cur;
+};
+
+static int get_cpufv(struct eeepc_cpufv *c)
+{
+	c->cur = get_acpi(CM_ASL_CPUFV);
+	c->num = (c->cur >> 8) & 0xff;
+	c->cur &= 0xff;
+	if (c->cur < 0 || c->num <= 0 || c->num > 12)
+		return -ENODEV;
+	return 0;
+}
+
+static ssize_t show_cpufv(struct device *dev,
+			  struct device_attribute *attr,
+			  char *buf)
+{
+	struct eeepc_cpufv c;
+	int i;
+	ssize_t len = 0;
+
+	if (get_cpufv(&c))
+		return sprintf(buf, "<unsupported>\n");
+	for (i = 0; i < c.num; i++)
+		len += sprintf(buf + len, "%d%s ", i, i == c.cur ? "*" : "");
+	len += sprintf(buf + len, "\n");
+	return len;
+}
+
+static ssize_t store_cpufv(struct device *dev,
+			   struct device_attribute *attr,
+			   const char *buf, size_t count)
+{
+	struct eeepc_cpufv c;
+	int rv, value;
+
+	if (get_cpufv(&c))
+		return -ENODEV;
+	rv = parse_arg(buf, count, &value);
+	if (rv < 0)
+		return rv;
+	if (!rv || value < 0 || value >= c.num)
+		return -EINVAL;
+	set_acpi(CM_ASL_CPUFV, value);
+	return rv;
+}
+
+static struct device_attribute dev_attr_cpufv = {
+	.attr = {
+		.name = "cpufv",
+		.mode = 0644 },
+	.show   = show_cpufv,
+	.store  = store_cpufv
+};
 
 static struct attribute *platform_attributes[] = {
 	&dev_attr_camera.attr,

Signature · 1 line

1.6.3.1

Alan Jenkins

2009-05-25 09:44 UTC #14 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 37 lines · Corentin Chary

Quoted 35 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 33 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 29 lines · <[email protected]> wrote:
Quoted 9 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.
Quoted 9 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to normal. There is no apparent effect on performance.

Quoted 8 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8
Hi, Can you try this patch ? It seems to works for me.

Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.

Do any of the models this actually works on, have only 2 different modes? I thought SHE included at least three, including an "overclocked" mode. Perhaps the cpufv file could be disabled for the 701 by checking the number of modes.

I'm thinking about distributions designed for all EeePC models, which will want to include an SHE applet, but will want an easy way to avoid running it on the 701, where it can't work.

BTW, is there a convention for sysfs files like this? You've used "*" to indicate the current value. /sys/power/disk uses square brackets instead. I see the "*" could be clearer though, when the options are single digits.

Regards
Alan

Corentin Chary

maintainer

2009-05-25 09:59 UTC #15 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 44 lines · Alan Jenkins

Quoted 43 lines · Corentin Chary
Quoted 40 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 38 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 34 lines · <[email protected]> wrote:
Quoted 9 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.
Quoted 9 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to normal. There is no apparent effect on performance.
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8

Quoted 5 lines

Quoted 2 lines
Hi, Can you try this patch ? It seems to works for me.
Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.

It works on mine (original bios). But I don't know how to see if there is a performance change.
Is there a quick cpu bench ?

Quoted 4 lines

Do any of the models this actually works on, have only 2 different modes? I thought SHE included at least three, including an "overclocked" mode. Perhaps the cpufv file could be disabled for the 701 by checking the number of modes.

I know the 1000h have 3 modes. I don't for others. Does someone have such a laptop on the list ?

Quoted 4 lines

BTW, is there a convention for sysfs files like this? You've used "*" to indicate the current value. /sys/power/disk uses square brackets instead. I see the "*" could be clearer though, when the options are single digits.

I/O Scheduler also use brackets.. don't know is there is a strict convention.

Signature · 6 lines

Corentin Chary
http://xf.iksaif.net - http://uffs.org
--
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

Alan Jenkins

2009-05-25 10:07 UTC #16 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 56 lines · Corentin Chary

Quoted 53 lines · Alan Jenkins
Quoted 51 lines · Corentin Chary
Quoted 39 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 36 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 31 lines · <[email protected]> wrote:
Quoted 9 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.
Quoted 10 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to normal. There is no apparent effect on performance.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8
Hi, Can you try this patch ? It seems to works for me.

Quoted 8 lines

Quoted 3 lines
Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.
It works on mine (original bios). But I don't know how to see if there is a performance change.
Is there a quick cpu bench ?

I used:

time for {1..10000}; do echo -n; done

It's a bit bogus - I expect it would show if my 630Mhz processor jumped to 900Mhz, but smaller changes might be lost in noise.

<http://pavelmachek.livejournal.com/77425.html> suggests "time factor $[65863223*65863159]", which should be better.

I think it's also significant that the current (630Mhz) setting is "1". I would expect "0" to be slower - but in the original 701 BIOS, 630Mhz is the slower of the two speeds, right?

Quoted 17 lines

Quoted 5 lines
Do any of the models this actually works on, have only 2 different modes? I thought SHE included at least three, including an "overclocked" mode. Perhaps the cpufv file could be disabled for the 701 by checking the number of modes.
I know the 1000h have 3 modes. I don't for others. Does someone have such a laptop on the list ?
Quoted 5 lines
BTW, is there a convention for sysfs files like this? You've used "*" to indicate the current value. /sys/power/disk uses square brackets instead. I see the "*" could be clearer though, when the options are single digits.
I/O Scheduler also use brackets.. don't know is there is a strict convention.

Corentin Chary

maintainer

2009-05-25 11:19 UTC #17 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 73 lines · Alan Jenkins

Quoted 56 lines · Corentin Chary
Quoted 53 lines · Alan Jenkins
Quoted 51 lines · Corentin Chary
Quoted 39 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 36 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 31 lines · <[email protected]> wrote:
Quoted 9 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.
Quoted 10 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to normal. There is no apparent effect on performance.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8
Hi, Can you try this patch ? It seems to works for me.
Quoted 8 lines
Quoted 3 lines
Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.
It works on mine (original bios). But I don't know how to see if there is a performance change.
Is there a quick cpu bench ?
I used:
time for {1..10000}; do echo -n; done
It's a bit bogus - I expect it would show if my 630Mhz processor jumped to 900Mhz, but smaller changes might be lost in noise.

Quoted 6 lines

<http://pavelmachek.livejournal.com/77425.html> suggests "time factor $[65863223*65863159]", which should be better.
I think it's also significant that the current (630Mhz) setting is "1". I would expect "0" to be slower - but in the original 701 BIOS, 630Mhz is the slower of the two speeds, right?

1 - time factor: ~ 1.574s - default, seems to be 630Mhz
0 - time factor: ~ 1.01s - seems to be 900

Signature · 6 lines

Corentin Chary
http://xf.iksaif.net - http://uffs.org
--
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

Alan Jenkins

2009-05-25 11:50 UTC #18 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 89 lines · Corentin Chary

Quoted 86 lines · Alan Jenkins
Quoted 65 lines · Corentin Chary
Quoted 61 lines · Alan Jenkins
Quoted 58 lines · Corentin Chary
Quoted 43 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 39 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 33 lines · <[email protected]> wrote:
Quoted 9 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.
Quoted 11 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to normal. There is no apparent effect on performance.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8
Hi, Can you try this patch ? It seems to works for me.
Quoted 9 lines
Quoted 4 lines
Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.
It works on mine (original bios). But I don't know how to see if there is a performance change.
Is there a quick cpu bench ?
I used:
time for {1..10000}; do echo -n; done
It's a bit bogus - I expect it would show if my 630Mhz processor jumped to 900Mhz, but smaller changes might be lost in noise.
<http://pavelmachek.livejournal.com/77425.html> suggests "time factor $[65863223*65863159]", which should be better.

Quoted 9 lines

Quoted 4 lines
I think it's also significant that the current (630Mhz) setting is "1". I would expect "0" to be slower - but in the original 701 BIOS, 630Mhz is the slower of the two speeds, right?
1 - time factor: ~ 1.574s - default, seems to be 630Mhz
0 - time factor: ~ 1.01s - seems to be 900

How illogical :-). Oh - I should have read the commit message, this is the expected order (and proper SHE just has the extra state: 2 / "performance").

Perhaps we should DMI-blacklist 701s with newer BIOS versions, so we only provide the performance control when it is available from the BIOS setup screen. The specific version is well-documented e.g. on forum.eeeuser.com.

Thanks for your time
Alan

Corentin Chary

maintainer

2009-05-26 10:12 UTC #19 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 118 lines · Alan Jenkins

Quoted 107 lines · Corentin Chary
Quoted 103 lines · Alan Jenkins
Quoted 79 lines · Corentin Chary
Quoted 74 lines · Alan Jenkins
Quoted 69 lines · Corentin Chary
Quoted 51 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 46 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 39 lines · <[email protected]> wrote:
Quoted 12 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks
and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and
voltage.
Quoted 11 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to
normal. There is no apparent effect on performance.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8
Hi, Can you try this patch ? It seems to works for me.
Quoted 10 lines
Quoted 4 lines
Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.
It works on mine (original bios). But I don't know how to see if there is a performance change.
Is there a quick cpu bench ?
I used:
time for {1..10000}; do echo -n; done
It's a bit bogus - I expect it would show if my 630Mhz processor jumped to 900Mhz, but smaller changes might be lost in noise.
<http://pavelmachek.livejournal.com/77425.html> suggests "time factor $[65863223*65863159]", which should be better.
Quoted 9 lines
Quoted 4 lines
I think it's also significant that the current (630Mhz) setting is "1". I would expect "0" to be slower - but in the original 701 BIOS, 630Mhz is the slower of the two speeds, right?
1 - time factor: ~ 1.574s - default, seems to be 630Mhz 0 - time factor: ~ 1.01s - seems to be 900

Quoted 7 lines

How illogical :-). Oh - I should have read the commit message, this is the expected order (and proper SHE just has the extra state: 2 / "performance").
Perhaps we should DMI-blacklist 701s with newer BIOS versions, so we only provide the performance control when it is available from the BIOS setup screen. The specific version is well-documented e.g. on forum.eeeuser.com.

Upgraded my 701 to latest bios 1302. Everything works fine. I've got a 701 4G, yours is a 701SD ?

Thanks

Signature · 6 lines

Corentin Chary
http://xf.iksaif.net - http://uffs.org
--
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

Alan Jenkins

2009-05-26 10:15 UTC #20 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 130 lines · Corentin Chary

Quoted 118 lines · Alan Jenkins
Quoted 106 lines · Corentin Chary
Quoted 102 lines · Alan Jenkins
Quoted 78 lines · Corentin Chary
Quoted 73 lines · Alan Jenkins
Quoted 69 lines · Corentin Chary
Quoted 50 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 45 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 38 lines · <[email protected]> wrote:
Quoted 11 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks
and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and
voltage.
Quoted 12 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to
normal. There is no apparent effect on performance.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8
Hi, Can you try this patch ? It seems to works for me.
Quoted 11 lines
Quoted 5 lines
Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.
It works on mine (original bios). But I don't know how to see if there is a performance change.
Is there a quick cpu bench ?
I used:
time for {1..10000}; do echo -n; done
It's a bit bogus - I expect it would show if my 630Mhz processor jumped to 900Mhz, but smaller changes might be lost in noise.
<http://pavelmachek.livejournal.com/77425.html> suggests "time factor $[65863223*65863159]", which should be better.
Quoted 10 lines
Quoted 5 lines
I think it's also significant that the current (630Mhz) setting is "1". I would expect "0" to be slower - but in the original 701 BIOS, 630Mhz is the slower of the two speeds, right?
1 - time factor: ~ 1.574s - default, seems to be 630Mhz
0 - time factor: ~ 1.01s - seems to be 900
Quoted 8 lines
How illogical :-). Oh - I should have read the commit message, this is the expected order (and proper SHE just has the extra state: 2 / "performance").
Perhaps we should DMI-blacklist 701s with newer BIOS versions, so we only provide the performance control when it is available from the BIOS setup screen. The specific version is well-documented e.g. on forum.eeeuser.com.

Quoted 5 lines

Upgraded my 701 to latest bios 1302. Everything works fine. I've got a 701 4G, yours is a 701SD ?
Thanks

No, mine is a 701 4G. Weird.

Alan

Francesco Lattanzio

2009-05-26 17:28 UTC #21 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 134 lines · Alan Jenkins

Quoted 133 lines · Corentin Chary
Quoted 118 lines · Alan Jenkins
Quoted 106 lines · Corentin Chary
Quoted 102 lines · Alan Jenkins
Quoted 78 lines · Corentin Chary
Quoted 73 lines · Alan Jenkins
Quoted 69 lines · Corentin Chary
Quoted 50 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 45 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 38 lines · <[email protected]> wrote:
Quoted 11 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks
and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and
voltage.
Quoted 12 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to
normal. There is no apparent effect on performance.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8
Hi, Can you try this patch ? It seems to works for me.
Quoted 11 lines
Quoted 5 lines
Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.
It works on mine (original bios). But I don't know how to see if there is a performance change.
Is there a quick cpu bench ?
I used:
time for {1..10000}; do echo -n; done
It's a bit bogus - I expect it would show if my 630Mhz processor jumped to 900Mhz, but smaller changes might be lost in noise.
<http://pavelmachek.livejournal.com/77425.html> suggests "time factor $[65863223*65863159]", which should be better.
Quoted 10 lines
Quoted 5 lines
I think it's also significant that the current (630Mhz) setting is "1". I would expect "0" to be slower - but in the original 701 BIOS, 630Mhz is the slower of the two speeds, right?
1 - time factor: ~ 1.574s - default, seems to be 630Mhz
0 - time factor: ~ 1.01s - seems to be 900
Quoted 8 lines
How illogical :-). Oh - I should have read the commit message, this is the expected order (and proper SHE just has the extra state: 2 / "performance").
Perhaps we should DMI-blacklist 701s with newer BIOS versions, so we only provide the performance control when it is available from the BIOS setup screen. The specific version is well-documented e.g. on forum.eeeuser.com.
Upgraded my 701 to latest bios 1302. Everything works fine. I've got a 701 4G, yours is a 701SD ?

Quoted 6 lines

Quoted 2 lines
Thanks
No, mine is a 701 4G. Weird.
Alan

This patch also works for 1000H. However for 901 I received discordant reports -- maybe a BIOS upgrade could fix this issue. Both 1000H and 901 have three possible configuration, with 0 the highest performant and 2 the lowest.

Signature · 1 line

Francesco Lattanzio <[email protected]>

Alan Jenkins

2009-05-26 17:43 UTC #22 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 157 lines · Francesco Lattanzio

Quoted 155 lines · Alan Jenkins
Quoted 153 lines · Corentin Chary
Quoted 134 lines · Alan Jenkins
Quoted 119 lines · Corentin Chary
Quoted 114 lines · Alan Jenkins
Quoted 93 lines · Corentin Chary
Quoted 75 lines · Alan Jenkins
Quoted 70 lines · Corentin Chary
Quoted 64 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 58 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 50 lines · <[email protected]> wrote:
Quoted 24 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance
preset through a ACPI function for just this purpose. SHE
underclocks
and undervolts the FSB and undervolts the CPU (at preset 2,
"powersave"), or slightly overclocks the CPU (at preset 0,
"performance"). Preset 1 is the default setting with default
clocks and
voltage.
The new eeepc-laptop driver doesn't support it anymore.
The attached patch adds support for it to eeepc-laptop. It's very
straight-forward and almost trivial.
Signed-off-by: Grigori Goronzy <[email protected]>
Signed-off-by: Corentin Chary <[email protected]>
Signed-off-by: Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to
normal. There is no apparent effect on performance.
This is stupid, because we _do_ appear to check the BIOS supported features bitmask, but that's Asus firmware for you. Can you please add an extra test, so this file only allows reads or writes if the current value is 0 or 1? If you're quick you might slip it into -rc8
Quoted 12 lines
Quoted 6 lines
Hi, Can you try this patch ? It seems to works for me.
Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.
Quoted 7 lines
It works on mine (original bios). But I don't know how to see if there is a performance change.
Is there a quick cpu bench ?
I used:
time for {1..10000}; do echo -n; done
It's a bit bogus - I expect it would show if my 630Mhz processor jumped to 900Mhz, but smaller changes might be lost in noise.
<http://pavelmachek.livejournal.com/77425.html> suggests "time factor $[65863223*65863159]", which should be better.
Quoted 12 lines
Quoted 6 lines
I think it's also significant that the current (630Mhz) setting is "1". I would expect "0" to be slower - but in the original 701 BIOS, 630Mhz is the slower of the two speeds, right?
1 - time factor: ~ 1.574s - default, seems to be 630Mhz
0 - time factor: ~ 1.01s - seems to be 900
Quoted 9 lines
How illogical :-). Oh - I should have read the commit message, this is the expected order (and proper SHE just has the extra state: 2 / "performance").
Perhaps we should DMI-blacklist 701s with newer BIOS versions, so we only provide the performance control when it is available from the BIOS setup screen. The specific version is well-documented e.g. on forum.eeeuser.com.
Upgraded my 701 to latest bios 1302. Everything works fine. I've got a 701 4G, yours is a 701SD ?
Thanks

Quoted 7 lines

Quoted 4 lines
No, mine is a 701 4G. Weird.
Alan
This patch also works for 1000H. However for 901 I received discordant reports -- maybe a BIOS upgrade could fix this issue. Both 1000H and 901 have three possible configuration, with 0 the highest performant and 2 the lowest.

My BIOS is the same though, version 1302. I think the only other possibilities are that my machine is just broken, or Asus changed the hardware at some point.

Corentin Chary

maintainer

2009-05-26 18:05 UTC #23 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

Quoted 162 lines · Alan Jenkins

Quoted 161 lines · Francesco Lattanzio
Quoted 159 lines · Alan Jenkins
Quoted 147 lines · Corentin Chary
Quoted 134 lines · Alan Jenkins
Quoted 119 lines · Corentin Chary
Quoted 114 lines · Alan Jenkins
Quoted 93 lines · Corentin Chary
Quoted 75 lines · Alan Jenkins
Quoted 70 lines · Corentin Chary
Quoted 64 lines · On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
Quoted 58 lines · Corentin Chary
On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
Quoted 50 lines · <[email protected]> wrote:
On 5/16/09, Len Brown <[email protected]> wrote:
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance
preset through a ACPI function for just this purpose. SHE
underclocks
and undervolts the FSB and undervolts the CPU (at preset 2,
"powersave"), or slightly overclocks the CPU (at preset 0,
"performance"). Preset 1 is the default setting with default
clocks and
voltage.
The new eeepc-laptop driver doesn't support it anymore.
The attached patch adds support for it to eeepc-laptop. It's very
straight-forward and almost trivial.
Signed-off-by: Grigori Goronzy <[email protected]>
Signed-off-by: Corentin Chary <[email protected]>
Signed-off-by: Len Brown <[email protected]>
---
Hi, out of curiosity I tried this on my EeePC 701. I upgraded the
BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from.
The file returns the value "513". If I write "1" to it, nothing
happens. If I write "0" to it, the speakers start hissing and the
file then returns the value "512". Writing "1" again gets it back
to
normal. There is no apparent effect on performance.
This is stupid, because we _do_ appear to check the BIOS supported
features bitmask, but that's Asus firmware for you. Can you please
add an extra test, so this file only allows reads or writes if the
current value is 0 or 1? If you're quick you might slip it into
-rc8
Quoted 12 lines
Quoted 6 lines
Hi, Can you try this patch ? It seems to works for me.
Thanks, it does make the interface less confusing. The behaviour (no performance change, hissing speakers) is the same.
Quoted 7 lines
It works on mine (original bios). But I don't know how to see if there is a performance change.
Is there a quick cpu bench ?
I used:
time for {1..10000}; do echo -n; done
It's a bit bogus - I expect it would show if my 630Mhz processor jumped to 900Mhz, but smaller changes might be lost in noise.
<http://pavelmachek.livejournal.com/77425.html> suggests "time factor $[65863223*65863159]", which should be better.
Quoted 12 lines
Quoted 6 lines
I think it's also significant that the current (630Mhz) setting is "1". I would expect "0" to be slower - but in the original 701 BIOS, 630Mhz is the slower of the two speeds, right?
1 - time factor: ~ 1.574s - default, seems to be 630Mhz 0 - time factor: ~ 1.01s - seems to be 900
Quoted 9 lines
How illogical :-). Oh - I should have read the commit message, this is the expected order (and proper SHE just has the extra state: 2 / "performance").
Perhaps we should DMI-blacklist 701s with newer BIOS versions, so we only provide the performance control when it is available from the BIOS setup screen. The specific version is well-documented e.g. on forum.eeeuser.com.
Quoted 6 lines
Upgraded my 701 to latest bios 1302. Everything works fine. I've got a 701 4G, yours is a 701SD ?
Thanks
No, mine is a 701 4G. Weird.
Alan

Quoted 8 lines

Quoted 3 lines
This patch also works for 1000H. However for 901 I received discordant reports -- maybe a BIOS upgrade could fix this issue. Both 1000H and 901 have three possible configuration, with 0 the highest performant and 2 the lowest.
My BIOS is the same though, version 1302. I think the only other possibilities are that my machine is just broken, or Asus changed the hardware at some point.

Maybe it's because I tested my patch with a 2.6.28 kernel. I should try with a git kernel.

Signature · 6 lines

Corentin Chary
http://xf.iksaif.net - http://uffs.org
--
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

Corentin Chary

maintainer

2009-05-24 20:24 UTC #24 lore raw

Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)

In reply to Alan Jenkins

Quoted 19 lines · Alan Jenkins

Quoted 9 lines · Len Brown
From: Grigori Goronzy <[email protected]>
The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage.
Quoted 8 lines
The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial.
Signed-off-by Grigori Goronzy <[email protected]>
Signed-off-by Corentin Chary <[email protected]>
Signed-off-by Len Brown <[email protected]>
---

Quoted 8 lines

Hi, out of curiosity I tried this on my EeePC 701. I upgraded the BIOS to the latest version available a few months ago.
I find that the file is present and can successfully be read from. The file returns the value "513". If I write "1" to it, nothing happens. If I write "0" to it, the speakers start hissing and the file then returns the value "512". Writing "1" again gets it back to normal. There is no apparent effect on performance.

After checking multiple dsdt :
x >> 8 = configurations possibles
x & 0xFF = current config

512 : 2 configurations possible, configuration 0
513: 2 configurations possible, configuration 1

For me it's a bug in the BIOS.
Anyway the output of the cpufv file is not very clear. I'll fix that and I'll test what it does on my 701 with an old bios.

Signature · 6 lines

Corentin Chary
http://xf.iksaif.net - http://uffs.org
--
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

Len Brown

author reviewer

2009-05-16 06:02 UTC #25 lore raw

PATCH 10/19 asus-laptop: fix input keycode

In reply to Len Brown

From: Corentin Chary <[email protected]>

KEY_STOP is now KEY_STOPCD
It's the correct key to stop a media
BTN_EXTRA is now KEY_SCREENLOCK:
The laptop manual tells us that this key is for screenlock
KEY_TV is now KEY_PROG1
So it can be reported to X server

Ref: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361505

Signed-off-by Corentin Chary <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/platform/x86/asus-laptop.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

drivers/platform/x86/asus-laptop.c +3 -3

index eeafc6c..bfc1a88 100644
@@ -269,16 +269,16 @@ static struct key_entry asus_keymap[] = {
 	{KE_KEY, 0x34, KEY_SWITCHVIDEOMODE},
 	{KE_KEY, 0x40, KEY_PREVIOUSSONG},
 	{KE_KEY, 0x41, KEY_NEXTSONG},
-	{KE_KEY, 0x43, KEY_STOP},
+	{KE_KEY, 0x43, KEY_STOPCD},
 	{KE_KEY, 0x45, KEY_PLAYPAUSE},
 	{KE_KEY, 0x50, KEY_EMAIL},
 	{KE_KEY, 0x51, KEY_WWW},
-	{KE_KEY, 0x5C, BTN_EXTRA},  /* Performance */
+	{KE_KEY, 0x5C, KEY_SCREENLOCK},  /* Screenlock */
 	{KE_KEY, 0x5D, KEY_WLAN},
 	{KE_KEY, 0x61, KEY_SWITCHVIDEOMODE},
 	{KE_KEY, 0x6B, BTN_TOUCH}, /* Lock Mouse */
 	{KE_KEY, 0x82, KEY_CAMERA},
-	{KE_KEY, 0x8A, KEY_TV},
+	{KE_KEY, 0x8A, KEY_PROG1},
 	{KE_KEY, 0x95, KEY_MEDIA},
 	{KE_KEY, 0x99, KEY_PHONE},
 	{KE_END, 0},

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #26 lore raw

PATCH 11/19 eeepc-laptop: unregister_rfkill_notifier on failure

In reply to Len Brown

From: Corentin Chary <[email protected]>

If there is a failure during eeepc_hotk_add() we need to remove the acpi_notify_handler.

Signed-off-by Corentin Chary <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/platform/x86/eeepc-laptop.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

drivers/platform/x86/eeepc-laptop.c +2 -0

index 7aaf587..353a898 100644
@@ -748,6 +748,8 @@ static int eeepc_hotk_add(struct acpi_device *device)
  wlan_fail:
 	if (ehotk->eeepc_wlan_rfkill)
 		rfkill_free(ehotk->eeepc_wlan_rfkill);
+	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
+	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
  ehotk_fail:
 	kfree(ehotk);
 	ehotk = NULL;

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #27 lore raw

PATCH 12/19 thermal: fix off-by-1 error in trip point trigger condition

In reply to Len Brown

From: Vladimir Zajac <[email protected]>

This patch fixes a regression caused by commit b1569e99c795bf83b4ddf41c4f1c42761ab7f75e
"ACPI: move thermal trip handling to generic thermal layer" which accidentally changed trip point trigger condition to
temp > trip_temp

This patch changes the trigger condition back to
temp >= trip_temp

Signed-off-by Vladimir Zajac <[email protected]>

Acked-by Zhang Rui <[email protected]>

Acked-by Matthew Garrett <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/thermal/thermal_sys.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

drivers/thermal/thermal_sys.c +4 -4

index d0b093b..5e38ba1 100644
@@ -961,7 +961,7 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
 
 		switch (trip_type) {
 		case THERMAL_TRIP_CRITICAL:
-			if (temp > trip_temp) {
+			if (temp >= trip_temp) {
 				if (tz->ops->notify)
 					ret = tz->ops->notify(tz, count,
 							      trip_type);

@@ -974,7 +974,7 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
 			}
 			break;
 		case THERMAL_TRIP_HOT:
-			if (temp > trip_temp)
+			if (temp >= trip_temp)
 				if (tz->ops->notify)
 					tz->ops->notify(tz, count, trip_type);
 			break;

@@ -986,14 +986,14 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
 
 				cdev = instance->cdev;
 
-				if (temp > trip_temp)
+				if (temp >= trip_temp)
 					cdev->ops->set_cur_state(cdev, 1);
 				else
 					cdev->ops->set_cur_state(cdev, 0);
 			}
 			break;
 		case THERMAL_TRIP_PASSIVE:
-			if (temp > trip_temp || tz->passive)
+			if (temp >= trip_temp || tz->passive)
 				thermal_zone_device_passive(tz, temp,
 							    trip_temp, count);
 			break;

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #28 lore raw

PATCH 13/19 ACPI: resume: re-enable SCI-enable workaround

In reply to Len Brown

From: Lin Ming <[email protected]>

The BIOS bug workaround mistakenly got disabled when we followed the ACPI specification more closely by ignoring OS updates to that bit.

(The BIOS is supposed to update SCI_EN, not the OS)

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

Signed-off-by Lin Ming <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/acpi/acpica/aclocal.h |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

drivers/acpi/acpica/aclocal.h +6 -1

index 772ee5c..2ec394a 100644
@@ -787,7 +787,12 @@ struct acpi_bit_register_info {
 
 /* For control registers, both ignored and reserved bits must be preserved */
 
-#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0201	/* Bits 9, 0(SCI_EN) */
+/*
+ * The ACPI spec says to ignore PM1_CTL.SCI_EN (bit 0)
+ * but we need to be able to write ACPI_BITREG_SCI_ENABLE directly
+ * as a BIOS workaround on some machines.
+ */
+#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0200	/* Bits 9 */
 #define ACPI_PM1_CONTROL_RESERVED_BITS          0xC1F8	/* Bits 14-15, 3-8 */
 #define ACPI_PM1_CONTROL_PRESERVED_BITS \
 	       (ACPI_PM1_CONTROL_IGNORED_BITS | ACPI_PM1_CONTROL_RESERVED_BITS)

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #29 lore raw

PATCH 14/19 ACPI: suspend: restore BM_RLD on resume

In reply to Len Brown

From: Len Brown <[email protected]>

In 2.6.29, 31878dd86b7df9a147f5e6cc6e07092b4308782b "ACPI: remove BM_RLD access from idle entry path" moved BM_RLD initialization to init-time from run time.

But we discovered that some BIOS do not restore BM_RLD after suspend, causing device errors on C3 and C4 after resume. So now the kernel restores BM_RLD.

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

Signed-off-by Len Brown <[email protected]>

---
 drivers/acpi/processor_idle.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

drivers/acpi/processor_idle.c +23 -0

index f7ca8c5..c1d59cf 100644
@@ -202,15 +202,38 @@ static void acpi_state_timer_broadcast(struct acpi_processor *pr,
  * Suspend / resume control
  */
 static int acpi_idle_suspend;
+static u32 saved_bm_rld;
+
+static void acpi_idle_bm_rld_save(void)
+{
+	acpi_read_bit_register(ACPI_BITREG_BUS_MASTER_RLD, &saved_bm_rld);
+}
+static void acpi_idle_bm_rld_restore(void)
+{
+	u32 resumed_bm_rld;
+
+	acpi_read_bit_register(ACPI_BITREG_BUS_MASTER_RLD, &resumed_bm_rld);
+
+	if (resumed_bm_rld != saved_bm_rld)
+		acpi_write_bit_register(ACPI_BITREG_BUS_MASTER_RLD, saved_bm_rld);
+}
 
 int acpi_processor_suspend(struct acpi_device * device, pm_message_t state)
 {
+	if (acpi_idle_suspend == 1)
+		return 0;
+
+	acpi_idle_bm_rld_save();
 	acpi_idle_suspend = 1;
 	return 0;
 }
 
 int acpi_processor_resume(struct acpi_device * device)
 {
+	if (acpi_idle_suspend == 0)
+		return 0;
+
+	acpi_idle_bm_rld_restore();
 	acpi_idle_suspend = 0;
 	return 0;
 }

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #30 lore raw

PATCH 15/19 ACPI, i915: build fix

In reply to Len Brown

From: Len Brown <[email protected]>

drivers/built-in.o: In function `intel_opregion_init':
(.text+0x9d540): undefined reference to `acpi_video_register'

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

Signed-off-by Len Brown <[email protected]>

---
 drivers/gpu/drm/Kconfig |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

drivers/gpu/drm/Kconfig +6 -0

index 3a22eb9..f33d252 100644
@@ -83,6 +83,12 @@ config DRM_I915
 config DRM_I915_KMS
 	bool "Enable modesetting on intel by default"
 	depends on DRM_I915
+	# i915 KMS depends on ACPI_VIDEO when ACPI is enabled
+	# but for select to work, need to select ACPI_VIDEO's dependencies, ick
+	select VIDEO_OUTPUT_CONTROL if ACPI
+	select BACKLIGHT_CLASS_DEVICE if ACPI
+	select INPUT if ACPI
+	select ACPI_VIDEO if ACPI
 	help
 	  Choose this option if you want kernel modesetting enabled by default,
 	  and you have a new enough userspace to support this. Running old

Signature · 1 line

1.6.0.6

yakui_zhao

2009-05-18 02:48 UTC #31 lore raw

Re: [PATCH 15/19] ACPI, i915: build fix

Quoted 4 lines · Len Brown

From: Len Brown <[email protected]>
drivers/built-in.o: In function `intel_opregion_init':
(.text+0x9d540): undefined reference to `acpi_video_register'

Hi,
When the KMS is selected in kernel configuration, the issue will be
fixed.
But if KMS is not set in kernel configuration, the issue will
still exist.

How about that the ACPI_VIDEO depends on the I915 instead of I915_KMS?

Thanks.

    ---
 drivers/gpu/drm/Kconfig |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6/drivers/gpu/drm/Kconfig
===================================================================
--- linux-2.6.orig/drivers/gpu/drm/Kconfig 2009-05-15 13:53:06.000000000
+0800
+++ linux-2.6/drivers/gpu/drm/Kconfig 2009-05-18 10:45:37.000000000
+0800
@@ -71,6 +71,10 @@
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FB
+ select VIDEO_OUTPUT_CONTROL if ACPI
+ select BACKLIGHT_CLASS_DEVICE if ACPI
+ select INPUT if ACPI
+ select ACPI_VIDEO if ACPI
tristate "i915 driver"
help
Choose this option if you have a system that has Intel 830M, 845G,

Quoted 25 lines

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

Signed-off-by Len Brown <[email protected]>

---
 drivers/gpu/drm/Kconfig |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

drivers/gpu/drm/Kconfig +6 -0

index 3a22eb9..f33d252 100644
@@ -83,6 +83,12 @@ config DRM_I915
 config DRM_I915_KMS
 	bool "Enable modesetting on intel by default"
 	depends on DRM_I915
+	# i915 KMS depends on ACPI_VIDEO when ACPI is enabled
+	# but for select to work, need to select ACPI_VIDEO's dependencies, ick
+	select VIDEO_OUTPUT_CONTROL if ACPI
+	select BACKLIGHT_CLASS_DEVICE if ACPI
+	select INPUT if ACPI
+	select ACPI_VIDEO if ACPI
 	help
 	  Choose this option if you want kernel modesetting enabled by default,
 	  and you have a new enough userspace to support this. Running old

Len Brown

author reviewer

2009-05-16 06:02 UTC #32 lore raw

PATCH 16/19 ACPI processor: introduce module parameter processor.ignore_tpc

In reply to Len Brown

From: Zhang Rui <[email protected]>

Introduce module parameter processor.ignore_tpc.

Some laptops are shipped with buggy _TPC,
this module parameter is used to to disable the buggy support.

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

Signed-off-by Zhang Rui <[email protected]>

Tested-by James Ettle <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/acpi/processor_throttling.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

drivers/acpi/processor_throttling.c +17 -0

index d0d1f4d..5f09fb8 100644
@@ -45,6 +45,14 @@
 #define _COMPONENT              ACPI_PROCESSOR_COMPONENT
 ACPI_MODULE_NAME("processor_throttling");
 
+/* ignore_tpc:
+ *  0 -> acpi processor driver doesn't ignore _TPC values
+ *  1 -> acpi processor driver ignores _TPC values
+ */
+static int ignore_tpc;
+module_param(ignore_tpc, int, 0644);
+MODULE_PARM_DESC(ignore_tpc, "Disable broken BIOS _TPC throttling support");
+
 struct throttling_tstate {
 	unsigned int cpu;		/* cpu nr */
 	int target_state;		/* target T-state */

@@ -283,6 +291,10 @@ static int acpi_processor_get_platform_limit(struct acpi_processor *pr)
 
 	if (!pr)
 		return -EINVAL;
+
+	if (ignore_tpc)
+		goto end;
+
 	status = acpi_evaluate_integer(pr->handle, "_TPC", NULL, &tpc);
 	if (ACPI_FAILURE(status)) {
 		if (status != AE_NOT_FOUND) {

@@ -290,6 +302,8 @@ static int acpi_processor_get_platform_limit(struct acpi_processor *pr)
 		}
 		return -ENODEV;
 	}
+
+end:
 	pr->throttling_platform_limit = (int)tpc;
 	return 0;
 }

@@ -302,6 +316,9 @@ int acpi_processor_tstate_has_changed(struct acpi_processor *pr)
 	struct acpi_processor_limit *limit;
 	int target_state;
 
+	if (ignore_tpc)
+		return 0;
+
 	result = acpi_processor_get_platform_limit(pr);
 	if (result) {
 		/* Throttling Limit is unsupported */

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #33 lore raw

PATCH 17/19 ACPI processor: reset the throttling state once it's invalid

In reply to Len Brown

From: Zhang Rui <[email protected]>

If the BIOS hands us an invalid throttling state, write a valid state.

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

Signed-off-by Zhang Rui <[email protected]>

Tested-by James Ettle <[email protected]>

Signed-off-by Len Brown <[email protected]>

---
 drivers/acpi/processor_throttling.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

drivers/acpi/processor_throttling.c +8 -0

index 5f09fb8..7f16f5f 100644
@@ -838,6 +838,14 @@ static int acpi_processor_get_throttling_ptc(struct acpi_processor *pr)
 	ret = acpi_read_throttling_status(pr, &value);
 	if (ret >= 0) {
 		state = acpi_get_throttling_state(pr, value);
+		if (state == -1) {
+			ACPI_WARNING((AE_INFO,
+				"Invalid throttling state, reset\n"));
+			state = 0;
+			ret = acpi_processor_set_throttling(pr, state);
+			if (ret)
+				return ret;
+		}
 		pr->throttling.state = state;
 	}

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #34 lore raw

PATCH 18/19 ACPI: idle: fix init-time TSC check regression

In reply to Len Brown

From: Len Brown <[email protected]>

A previous 2.6.30 patch, a71e4917dc0ebbcb5a0ecb7ca3486643c1c9a6e2, (ACPI: idle: mark_tsc_unstable() at init-time, not run-time) erroneously disabled the TSC on systems that did not actually have valid deep C-states.

Move the check after the deep-C-states are validated, via new helper, tsc_check_state(), hich replaces tsc_halts_in_c().

Signed-off-by Len Brown <[email protected]>

Acked-by Venkatesh Pallipadi <[email protected]>

Acked-by Thomas Gleixner <[email protected]>

Tested-by Frans Pop <[email protected]>

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

drivers/acpi/processor_idle.c +9 -8

index f7ca8c5..e39a40a 100644
@@ -216,7 +216,7 @@ int acpi_processor_resume(struct acpi_device * device)
 }
 
 #if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
-static int tsc_halts_in_c(int state)
+static void tsc_check_state(int state)
 {
 	switch (boot_cpu_data.x86_vendor) {
 	case X86_VENDOR_AMD:

@@ -226,13 +226,17 @@ static int tsc_halts_in_c(int state)
 		 * C/P/S0/S1 states when this bit is set.
 		 */
 		if (boot_cpu_has(X86_FEATURE_NONSTOP_TSC))
-			return 0;
+			return;
 
 		/*FALL THROUGH*/
 	default:
-		return state > ACPI_STATE_C1;
+		/* TSC could halt in idle, so notify users */
+		if (state > ACPI_STATE_C1)
+			mark_tsc_unstable("TSC halts in idle");
 	}
 }
+#else
+static void tsc_check_state(int state) { return; }
 #endif
 
 static int acpi_processor_get_power_info_fadt(struct acpi_processor *pr)

@@ -581,11 +585,6 @@ static int acpi_processor_power_verify(struct acpi_processor *pr)
 	for (i = 1; i < ACPI_PROCESSOR_MAX_POWER; i++) {
 		struct acpi_processor_cx *cx = &pr->power.states[i];
 
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
-		/* TSC could halt in idle, so notify users */
-		if (tsc_halts_in_c(cx->type))
-			mark_tsc_unstable("TSC halts in idle");;
-#endif
 		switch (cx->type) {
 		case ACPI_STATE_C1:
 			cx->valid = 1;

@@ -603,6 +602,8 @@ static int acpi_processor_power_verify(struct acpi_processor *pr)
 				acpi_timer_check_state(i, pr, cx);
 			break;
 		}
+		if (cx->valid)
+			tsc_check_state(cx->type);
 
 		if (cx->valid)
 			working++;

Signature · 1 line

1.6.0.6

Len Brown

author reviewer

2009-05-16 06:02 UTC #35 lore raw

PATCH 19/19 ACPI: Idle C-states disabled by max_cstate should not disable the TSC

In reply to Len Brown

From: Len Brown <[email protected]>

Processor idle power states C2 and C3 stop the TSC on many machines. Linux recognizes this situation and marks the TSC as unstable:

Marking TSC unstable due to TSC halts in idle

But if those same machines are booted with "processor.max_cstate=1", then there is no need to validate C2 and C3, and no need to disable the TSC, which can be reliably used as a clocksource.

Signed-off-by Len Brown <[email protected]>

Acked-by Thomas Gleixner <[email protected]>

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

drivers/acpi/processor_idle.c +1 -1

index e39a40a..e65476f 100644
@@ -582,7 +582,7 @@ static int acpi_processor_power_verify(struct acpi_processor *pr)
 
 	pr->power.timer_broadcast_on_state = INT_MAX;
 
-	for (i = 1; i < ACPI_PROCESSOR_MAX_POWER; i++) {
+	for (i = 1; i < ACPI_PROCESSOR_MAX_POWER && i <= max_cstate; i++) {
 		struct acpi_processor_cx *cx = &pr->power.states[i];
 
 		switch (cx->type) {

Signature · 1 line

1.6.0.6