ACPI & driver patches for 2.6.30-rc5
Subsystems (8)
Len Brown
reviewerPATCH 4/19 ACPI: power: update error message
In reply to Len BrownFrom: 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
--- drivers/acpi/bus.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/acpi/bus.c +1 -1
@@ -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
reviewerPATCH 7/19 eeepc-laptop: report brightness control events via the input layer
In reply to Len BrownFrom: 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)
--- drivers/platform/x86/eeepc-laptop.c | 29 ++++++++++++++++++++++++++--- 1 files changed, 26 insertions(+), 3 deletions(-)
drivers/platform/x86/eeepc-laptop.c +26 -3
@@ -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
reviewerPATCH 8/19 eeepc-laptop: Work around rfkill firmware bug
In reply to Len BrownFrom: 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.
--- drivers/platform/x86/eeepc-laptop.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-)
drivers/platform/x86/eeepc-laptop.c +7 -1
@@ -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
reviewerPATCH 9/19 eeepc-laptop: support for super hybrid engine (SHE)
In reply to Len BrownFrom: 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.
--- drivers/platform/x86/eeepc-laptop.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
drivers/platform/x86/eeepc-laptop.c +2 -0
@@ -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
Len Brown
reviewerPATCH 11/19 eeepc-laptop: unregister_rfkill_notifier on failure
In reply to Len BrownFrom: Corentin Chary <[email protected]>
If there is a failure during eeepc_hotk_add() we need to remove the acpi_notify_handler.
--- drivers/platform/x86/eeepc-laptop.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
drivers/platform/x86/eeepc-laptop.c +2 -0
@@ -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
reviewerPATCH 1/19 ACPI video: dmi check for broken _BQC on Acer Aspire 5720
In reply to Len BrownFrom: 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
--- drivers/acpi/video.c | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-)
drivers/acpi/video.c +30 -0
@@ -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
reviewerPATCH 10/19 asus-laptop: fix input keycode
In reply to Len BrownFrom: Corentin Chary <[email protected]>
KEY_STOP is now KEY_STOPCD
It's the correct key to stop a mediaBTN_EXTRA is now KEY_SCREENLOCK:
The laptop manual tells us that this key is for screenlockKEY_TV is now KEY_PROG1
So it can be reported to X server
Ref: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361505
--- drivers/platform/x86/asus-laptop.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
drivers/platform/x86/asus-laptop.c +3 -3
@@ -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
reviewerPATCH 15/19 ACPI, i915: build fix
In reply to Len BrownFrom: 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
--- drivers/gpu/drm/Kconfig | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
drivers/gpu/drm/Kconfig +6 -0
@@ -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
Len Brown
reviewerPATCH 17/19 ACPI processor: reset the throttling state once it's invalid
In reply to Len BrownFrom: 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
--- drivers/acpi/processor_throttling.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
drivers/acpi/processor_throttling.c +8 -0
@@ -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
reviewerPATCH 18/19 ACPI: idle: fix init-time TSC check regression
In reply to Len BrownFrom: 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().
--- drivers/acpi/processor_idle.c | 17 +++++++++-------- 1 files changed, 9 insertions(+), 8 deletions(-)
drivers/acpi/processor_idle.c +9 -8
@@ -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
reviewerPATCH 12/19 thermal: fix off-by-1 error in trip point trigger condition
In reply to Len BrownFrom: 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
--- drivers/thermal/thermal_sys.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
drivers/thermal/thermal_sys.c +4 -4
@@ -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
reviewerPATCH 3/19 ACPI: video: DMI workaround another broken Acer BIOS enabling display brightness
In reply to Len BrownFrom: Len Brown <[email protected]>
http://bugzilla.kernel.org/show_bug.cgi?id=13121
--- drivers/acpi/video.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
drivers/acpi/video.c +8 -0
@@ -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
reviewerPATCH 5/19 ACPI: suspend: don't let device _PS3 failure prevent suspend
In reply to Len BrownFrom: 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.
--- drivers/pnp/pnpacpi/core.c | 8 +++----- 1 files changed, 3 insertions(+), 5 deletions(-)
drivers/pnp/pnpacpi/core.c +3 -5
@@ -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
reviewerPATCH 13/19 ACPI: resume: re-enable SCI-enable workaround
In reply to Len BrownFrom: 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
--- drivers/acpi/acpica/aclocal.h | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
drivers/acpi/acpica/aclocal.h +6 -1
@@ -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
reviewerPATCH 14/19 ACPI: suspend: restore BM_RLD on resume
In reply to Len BrownFrom: 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
--- drivers/acpi/processor_idle.c | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-)
drivers/acpi/processor_idle.c +23 -0
@@ -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
reviewerhere is the queue for upstream right now.
thanks,
-Len
Len Brown
reviewerPATCH 2/19 ACPICA: use acpi.* modparam namespace
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
--- drivers/acpi/acpica/Makefile | 27 +++++++++++++++------------ 1 files changed, 15 insertions(+), 12 deletions(-)
drivers/acpi/acpica/Makefile +15 -12
@@ -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
reviewerPATCH 6/19 eeepc-laptop: fix wlan rfkill state change during init
In reply to Len BrownFrom: 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.
--- drivers/platform/x86/eeepc-laptop.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
drivers/platform/x86/eeepc-laptop.c +3 -3
@@ -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
reviewerPATCH 16/19 ACPI processor: introduce module parameter processor.ignore_tpc
In reply to Len BrownFrom: 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
--- drivers/acpi/processor_throttling.c | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
drivers/acpi/processor_throttling.c +17 -0
@@ -45,6 +45,14 @@#define _COMPONENT ACPI_PROCESSOR_COMPONENTACPI_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
reviewerPATCH 19/19 ACPI: Idle C-states disabled by max_cstate should not disable the TSC
In reply to Len BrownFrom: 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.
--- drivers/acpi/processor_idle.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/acpi/processor_idle.c +1 -1
@@ -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
Re: [PATCH 15/19] ACPI, i915: build fix
In reply to Len BrownQuoted 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@@ -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
Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)
In reply to Len BrownQuoted 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
maintainerRe: [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
Corentin Chary
maintainerRe: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)
In reply to Alan JenkinsQuoted 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
Corentin Chary
maintainerRe: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)
In reply to a message not in the archiveQuoted 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
c357105fe0016f71d92d7a11500d7cd72b70282fMon 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.
--- drivers/platform/x86/eeepc-laptop.c | 59 ++++++++++++++++++++++++++++++++++- 1 files changed, 58 insertions(+), 1 deletions(-)
drivers/platform/x86/eeepc-laptop.c +58 -1
@@ -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
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
maintainerRe: [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
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/diskuses 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
maintainerRe: [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
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
maintainerRe: [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
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 900Quoted 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
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 900Quoted 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]>
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 900Quoted 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
maintainerRe: [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
-rc8Quoted 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