ACPI & driver patches for 2.6.30-rc5

ACPI & driver patches for 2.6.30-rc5

[Len Brown]

here is the queue for upstream right now.

thanks,
-Len

[PATCH 01/19] ACPI video: dmi check for broken _BQC on Acer Aspire 5720

[Len Brown]

From: Zhang Rui <rui.zhang@intel.com>

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 <maximlevitsky@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/video.c |   30 ++++++++++++++++++++++++++++++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index cd4fb75..7e8ee49 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -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;
 
-- 
1.6.0.6

[PATCH 02/19] ACPICA: use acpi.* modparam namespace

[Len Brown]

From: Len Brown <len.brown@intel.com>

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 <len.brown@intel.com>
---
 drivers/acpi/acpica/Makefile |   27 +++++++++++++++------------
 1 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index 17e5082..72ac28d 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -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
-- 
1.6.0.6

[PATCH 03/19] ACPI: video: DMI workaround another broken Acer BIOS enabling display brightness

[Len Brown]

From: Len Brown <len.brown@intel.com>

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

Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/video.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 7e8ee49..3a3d156 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -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"),
+		},
+	},
 	{}
 };
 
-- 
1.6.0.6

[PATCH 04/19] ACPI: power: update error message

[Len Brown]

From: Len Brown <len.brown@intel.com>

"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 <len.brown@intel.com>
---
 drivers/acpi/bus.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index e8f7b64..ae862f1 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -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;
-- 
1.6.0.6

[PATCH 05/19] ACPI: suspend: don't let device _PS3 failure prevent suspend

[Len Brown]

From: Len Brown <len.brown@intel.com>

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 <len.brown@intel.com>
---
 drivers/pnp/pnpacpi/core.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
index 9a3a682..9496494 100644
--- a/drivers/pnp/pnpacpi/core.c
+++ b/drivers/pnp/pnpacpi/core.c
@@ -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;
-- 
1.6.0.6

[PATCH 06/19] eeepc-laptop: fix wlan rfkill state change during init

[Len Brown]

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

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 <alan-jenkins@tuffmail.co.uk>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/platform/x86/eeepc-laptop.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 6f54fd1..e21f7cd 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -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:
-- 
1.6.0.6

[PATCH 07/19] eeepc-laptop: report brightness control events via the input layer

[Len Brown]

From: Darren Salt <linux@youmustbejoking.demon.co.uk>

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 <linux@youmustbejoking.demon.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/platform/x86/eeepc-laptop.c |   29 ++++++++++++++++++++++++++---
 1 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index e21f7cd..f54cfea 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -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) {
-- 
1.6.0.6

[PATCH 08/19] eeepc-laptop: Work around rfkill firmware bug

[Len Brown]

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

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 <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/platform/x86/eeepc-laptop.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index f54cfea..57f21f0 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -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)
-- 
1.6.0.6

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

[Len Brown]

From: Grigori Goronzy <greg@chown.ath.cx>

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 <greg@chown.ath.cx>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/platform/x86/eeepc-laptop.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 57f21f0..7aaf587 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -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
 };
 
-- 
1.6.0.6

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

[Alan Jenkins]

On 5/16/09, Len Brown <lenb@kernel.org> wrote:
> From: Grigori Goronzy <greg@chown.ath.cx>
>
> 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 <greg@chown.ath.cx>
> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---

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

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

[Corentin Chary]

On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
<sourcejedi.lkml@googlemail.com> wrote:
> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>> From: Grigori Goronzy <greg@chown.ath.cx>
>>
>> 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 <greg@chown.ath.cx>
>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>> Signed-off-by: Len Brown <len.brown@intel.com>
>> ---
>
> 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
>

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

-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Corentin Chary]

On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
> Corentin Chary wrote:
> > On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
> >
> > <sourcejedi.lkml@googlemail.com> wrote:
> >> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
> >>> From: Grigori Goronzy <greg@chown.ath.cx>
> >>>
> >>> 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 <greg@chown.ath.cx>
> >>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
> >>> Signed-off-by: Len Brown <len.brown@intel.com>
> >>> ---
> >>
> >> 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

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

>From c357105fe0016f71d92d7a11500d7cd72b70282f Mon Sep 17 00:00:00 2001
From: Corentin Chary <corentincj@iksaif.net>
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 <corentincj@iksaif.net>
---
 drivers/platform/x86/eeepc-laptop.c |   59 ++++++++++++++++++++++++++++++++++-
 1 files changed, 58 insertions(+), 1 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index a0845b2..4e1cf2d 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -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,
-- 
1.6.3.1

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

[Alan Jenkins]

Corentin Chary wrote:
> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>   
>> Corentin Chary wrote:
>>     
>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>
>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>       
>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>         
>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>
>>>>> 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 <greg@chown.ath.cx>
>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>> ---
>>>>>           
>>>> 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
>>>>         
>
> 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

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

[Corentin Chary]

On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
<alan-jenkins@tuffmail.co.uk> wrote:
> Corentin Chary wrote:
>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>>
>>> Corentin Chary wrote:
>>>
>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>>
>>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>>
>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>>
>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>
>>>>>> 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 <greg@chown.ath.cx>
>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>>> ---
>>>>>>
>>>>> 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
>>>>>
>>
>> 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 ?

> 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 ?

> 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
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alan Jenkins]

Corentin Chary wrote:
> On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
> <alan-jenkins@tuffmail.co.uk> wrote:
>   
>> Corentin Chary wrote:
>>     
>>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>>>
>>>       
>>>> Corentin Chary wrote:
>>>>
>>>>         
>>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>>>
>>>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>>>
>>>>>           
>>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>>>
>>>>>>             
>>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>>
>>>>>>> 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 <greg@chown.ath.cx>
>>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>>>> ---
>>>>>>>
>>>>>>>               
>>>>>> 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
>>>>>>
>>>>>>             
>>> 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 ?
>   

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?

>> 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 ?
>
>   
>> 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.
>   

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

[Corentin Chary]

On Mon, May 25, 2009 at 12:07 PM, Alan Jenkins
<alan-jenkins@tuffmail.co.uk> wrote:
> Corentin Chary wrote:
>> On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
>> <alan-jenkins@tuffmail.co.uk> wrote:
>>
>>> Corentin Chary wrote:
>>>
>>>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>>>>
>>>>
>>>>> Corentin Chary wrote:
>>>>>
>>>>>
>>>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>>>>
>>>>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>>>
>>>>>>>> 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 <greg@chown.ath.cx>
>>>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>> 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 ?
>>
>
> 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?

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

-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alan Jenkins]

Corentin Chary wrote:
> On Mon, May 25, 2009 at 12:07 PM, Alan Jenkins
> <alan-jenkins@tuffmail.co.uk> wrote:
>   
>> Corentin Chary wrote:
>>     
>>> On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>
>>>       
>>>> Corentin Chary wrote:
>>>>
>>>>         
>>>>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Corentin Chary wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>>>>>
>>>>>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>>>>
>>>>>>>>> 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 <greg@chown.ath.cx>
>>>>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>> 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 ?
>>>
>>>       
>> 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?
>>     
>
> 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

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

[Corentin Chary]

On Mon, May 25, 2009 at 1:51 PM, Alan Jenkins
<alan-jenkins@tuffmail.co.uk> wrote:
> Corentin Chary wrote:
>>
>> On Mon, May 25, 2009 at 12:07 PM, Alan Jenkins
>> <alan-jenkins@tuffmail.co.uk> wrote:
>>
>>>
>>> Corentin Chary wrote:
>>>
>>>>
>>>> On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
>>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>>
>>>>
>>>>>
>>>>> Corentin Chary wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Corentin Chary wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>>>>>>
>>>>>>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>>>>>
>>>>>>>>>> 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 <greg@chown.ath.cx>
>>>>>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>> 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 ?
>>>>
>>>>
>>>
>>> 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?
>>>
>>
>> 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.
>

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

Thanks


-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alan Jenkins]

Corentin Chary wrote:
> On Mon, May 25, 2009 at 1:51 PM, Alan Jenkins
> <alan-jenkins@tuffmail.co.uk> wrote:
>   
>> Corentin Chary wrote:
>>     
>>> On Mon, May 25, 2009 at 12:07 PM, Alan Jenkins
>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>
>>>       
>>>> Corentin Chary wrote:
>>>>
>>>>         
>>>>> On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
>>>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Corentin Chary wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> Corentin Chary wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>>>>>>>
>>>>>>>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>>>>>>
>>>>>>>>>>> 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 <greg@chown.ath.cx>
>>>>>>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>>>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> 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 ?
>>>>>
>>>>>
>>>>>           
>>>> 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?
>>>>
>>>>         
>>> 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.
>>
>>     
>
> 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

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

[Francesco Lattanzio]

On Tue, May 26, 2009 at 11:15:12AM +0100, Alan Jenkins wrote:
> Corentin Chary wrote:
> > On Mon, May 25, 2009 at 1:51 PM, Alan Jenkins
> > <alan-jenkins@tuffmail.co.uk> wrote:
> >   
> >> Corentin Chary wrote:
> >>     
> >>> On Mon, May 25, 2009 at 12:07 PM, Alan Jenkins
> >>> <alan-jenkins@tuffmail.co.uk> wrote:
> >>>
> >>>       
> >>>> Corentin Chary wrote:
> >>>>
> >>>>         
> >>>>> On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
> >>>>> <alan-jenkins@tuffmail.co.uk> wrote:
> >>>>>
> >>>>>
> >>>>>           
> >>>>>> Corentin Chary wrote:
> >>>>>>
> >>>>>>
> >>>>>>             
> >>>>>>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>               
> >>>>>>>> Corentin Chary wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>                 
> >>>>>>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
> >>>>>>>>>
> >>>>>>>>> <sourcejedi.lkml@googlemail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>                   
> >>>>>>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>                     
> >>>>>>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
> >>>>>>>>>>>
> >>>>>>>>>>> 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 <greg@chown.ath.cx>
> >>>>>>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
> >>>>>>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
> >>>>>>>>>>> ---
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>                       
> >>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>                     
> >>>>>>> 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 ?
> >>>>>
> >>>>>
> >>>>>           
> >>>> 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?
> >>>>
> >>>>         
> >>> 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.
> >>
> >>     
> >
> > 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
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.

-- 
Francesco Lattanzio <franz.lattanzio@gmail.com>

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

[Alan Jenkins]

Francesco Lattanzio wrote:
> On Tue, May 26, 2009 at 11:15:12AM +0100, Alan Jenkins wrote:
>   
>> Corentin Chary wrote:
>>     
>>> On Mon, May 25, 2009 at 1:51 PM, Alan Jenkins
>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>   
>>>       
>>>> Corentin Chary wrote:
>>>>     
>>>>         
>>>>> On Mon, May 25, 2009 at 12:07 PM, Alan Jenkins
>>>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>>>
>>>>>       
>>>>>           
>>>>>> Corentin Chary wrote:
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
>>>>>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>>>> Corentin Chary wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>>> Corentin Chary wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>>>>>>>>>
>>>>>>>>>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <greg@chown.ath.cx>
>>>>>>>>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>>>>>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                       
>>>>>>>>>>>>>                           
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>> 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 ?
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>> 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?
>>>>>>
>>>>>>         
>>>>>>             
>>>>> 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.
>>>>
>>>>     
>>>>         
>>> 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
>>     
> 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.

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

[Corentin Chary]

On Tue, May 26, 2009 at 7:43 PM, Alan Jenkins
<alan-jenkins@tuffmail.co.uk> wrote:
> Francesco Lattanzio wrote:
>> On Tue, May 26, 2009 at 11:15:12AM +0100, Alan Jenkins wrote:
>>
>>> Corentin Chary wrote:
>>>
>>>> On Mon, May 25, 2009 at 1:51 PM, Alan Jenkins
>>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>>
>>>>
>>>>> Corentin Chary wrote:
>>>>>
>>>>>
>>>>>> On Mon, May 25, 2009 at 12:07 PM, Alan Jenkins
>>>>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Corentin Chary wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
>>>>>>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Corentin Chary wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Corentin Chary wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>>>>>>>>>>
>>>>>>>>>>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <greg@chown.ath.cx>
>>>>>>>>>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>>>>>>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> 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 ?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>> 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
>>>
>> 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.

-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Corentin Chary]

On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
<sourcejedi.lkml@googlemail.com> wrote:
> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>> From: Grigori Goronzy <greg@chown.ath.cx>
>>
>> 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 <greg@chown.ath.cx>
>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>> Signed-off-by: Len Brown <len.brown@intel.com>
>> ---
>
> 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.

-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/19] asus-laptop: fix input keycode

[Len Brown]

From: Corentin Chary <corentincj@iksaif.net>

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 <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/platform/x86/asus-laptop.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c
index eeafc6c..bfc1a88 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -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},
-- 
1.6.0.6

[PATCH 11/19] eeepc-laptop: unregister_rfkill_notifier on failure

[Len Brown]

From: Corentin Chary <corentincj@iksaif.net>

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

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/platform/x86/eeepc-laptop.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 7aaf587..353a898 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -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;
-- 
1.6.0.6

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

[Len Brown]

From: Vladimir Zajac <eightgraph@gmail.com>

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 <eightgraph@gmail.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/thermal/thermal_sys.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index d0b093b..5e38ba1 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -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;
-- 
1.6.0.6

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

[Len Brown]

From: Lin Ming <ming.m.lin@intel.com>

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 <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/acpica/aclocal.h |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 772ee5c..2ec394a 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -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)
-- 
1.6.0.6

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

[Len Brown]

From: Len Brown <len.brown@intel.com>

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 <len.brown@intel.com>
---
 drivers/acpi/processor_idle.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index f7ca8c5..c1d59cf 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -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;
 }
-- 
1.6.0.6

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

[Len Brown]

From: Len Brown <len.brown@intel.com>

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 <len.brown@intel.com>
---
 drivers/gpu/drm/Kconfig |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3a22eb9..f33d252 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -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
-- 
1.6.0.6

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

[yakui_zhao]

On Sat, 2009-05-16 at 14:02 +0800, Len Brown wrote:
> From: Len Brown <len.brown@intel.com>
> 
> 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,

> 
> http://bugzilla.kernel.org/show_bug.cgi?id=13165
> 
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---
>  drivers/gpu/drm/Kconfig |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 3a22eb9..f33d252 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -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

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

[Len Brown]

From: Zhang Rui <rui.zhang@intel.com>

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 <rui.zhang@intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/processor_throttling.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_throttling.c b/drivers/acpi/processor_throttling.c
index d0d1f4d..5f09fb8 100644
--- a/drivers/acpi/processor_throttling.c
+++ b/drivers/acpi/processor_throttling.c
@@ -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 */
-- 
1.6.0.6

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

[Len Brown]

From: Zhang Rui <rui.zhang@intel.com>

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 <rui.zhang@intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/processor_throttling.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_throttling.c b/drivers/acpi/processor_throttling.c
index 5f09fb8..7f16f5f 100644
--- a/drivers/acpi/processor_throttling.c
+++ b/drivers/acpi/processor_throttling.c
@@ -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;
 	}
 
-- 
1.6.0.6

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

[Len Brown]

From: Len Brown <len.brown@intel.com>

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 <len.brown@intel.com>
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Frans Pop <elendil@planet.nl>
---
 drivers/acpi/processor_idle.c |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index f7ca8c5..e39a40a 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -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++;
-- 
1.6.0.6

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

[Len Brown]

From: Len Brown <len.brown@intel.com>

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 <len.brown@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/acpi/processor_idle.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index e39a40a..e65476f 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -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) {
-- 
1.6.0.6