Re: [PATCH 0/5] Laptop driver documentation changes for 2.6.25
On Sat, 09 Feb 2008 01:31:57 + Carlos Corbacho wrote: The following series implements the proposed creation of Documentation/laptops, and the movement of all the laptop driver documentation to this directory. I've also taken the opportunity to tack on the acer-wmi documentation in the final patch of this series. Because all the drivers in question go through the ACPI tree anyway, it's probably easiest if this change goes through the ACPI tree as well. This should all be 2.6.25 material, since there is no code change here, just rearranging the Documentation files, and updating Kconfig entries where required. I've also tested this series against Linus' latest git tree, with no problems applying it there. Hi, so should we also move Documentation/laptop-mode.txt to laptops/ dir? Carlos Corbacho (5): acer-wmi - Add documentation sonypi - Move sonypi.txt to Documentation/laptops sony-laptop - Move sony-laptop.txt to Documentation/laptops thinkpad-acpi - Move thinkpad-acpi.txt to Documentation/laptops Documentation - Create laptops sub-directory Documentation/00-INDEX |8 Documentation/laptops/00-INDEX | 10 Documentation/laptops/acer-wmi.txt | 202 + Documentation/laptops/sony-laptop.txt | 117 +++ Documentation/laptops/sonypi.txt| 152 +++ Documentation/laptops/thinkpad-acpi.txt | 1365 +++ Documentation/sony-laptop.txt | 117 --- Documentation/sonypi.txt| 152 --- Documentation/thinkpad-acpi.txt | 1365 --- drivers/char/Kconfig|2 drivers/misc/Kconfig| 10 11 files changed, 1856 insertions(+), 1644 deletions(-) create mode 100644 Documentation/laptops/00-INDEX create mode 100644 Documentation/laptops/acer-wmi.txt create mode 100644 Documentation/laptops/sony-laptop.txt create mode 100644 Documentation/laptops/sonypi.txt create mode 100644 Documentation/laptops/thinkpad-acpi.txt delete mode 100644 Documentation/sony-laptop.txt delete mode 100644 Documentation/sonypi.txt delete mode 100644 Documentation/thinkpad-acpi.txt --- ~Randy - 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: BIOS _OSI(Linux) query ignored - PowerEdge 1950
On Mon, 11 Feb 2008, Krzysztof Oledzki wrote: On Sun, 10 Feb 2008, Len Brown wrote: On Sunday 10 February 2008 17:09, Krzysztof Oledzki wrote: Hello, ACPI: EC: Look up EC in DSDT ACPI: BIOS _OSI(Linux) query ignored ACPI: DMI System Vendor: Dell Inc. ACPI: DMI Product Name: PowerEdge 1950 ACPI: DMI Product Version: ACPI: DMI Board Name: 0TT740 ACPI: DMI BIOS Vendor: Dell Inc. ACPI: DMI BIOS Date: 10/27/2007 ACPI: Please send DMI info above to linux-acpi@vger.kernel.org please send me the output from acpidump. Attached. Strange. I have one more identical server but acpidump is for unknown reason different. Also attached. Best regards, Krzysztof Olędzki acpidump-dell1950-v2.gz Description: Binary data
Re: [Bug-fix]:2.6.25-rc0 Generic thermal management [Patch 1/2]: validating input parameters
On Mon, 11 Feb 2008 15:57:06 +0530
Thomas, Sujith [EMAIL PROTECTED] wrote:
From: Thomas Sujith [EMAIL PROTECTED]
Added sanity checks for interface functions in thermal with
other modules such as fan, processor, video etc..
Signed-off-by: Thomas Sujith [EMAIL PROTECTED]
---
drivers/thermal/thermal.c | 69
+-
The patch is fairly seriously wordwrapped.
1 files changed, 44 insertions(+), 25 deletions(-)
Index: linux-2.6.24-rc3/drivers/thermal/thermal.c
===
--- linux-2.6.24-rc3.orig/drivers/thermal/thermal.c
+++ linux-2.6.24-rc3/drivers/thermal/thermal.c
@@ -301,13 +301,27 @@ int thermal_zone_bind_cooling_device(str
{
struct thermal_cooling_device_instance *dev;
struct thermal_cooling_device_instance *pos;
+ struct thermal_zone_device *pos1;
+ struct thermal_cooling_device *pos2;
int result;
+ if (!tz || !cdev)
+ return -EINVAL;
Is this change actually needed? It's sloppy for a caller to be passing
invalid arguments into a callee, and it's not good for the callee to just
hide that sloppiness.
- return NULL;
+ return ERR_PTR(-EINVAL);
the patch adds several spaces like this in places where we don't normally
put them.
-
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 2/5] Provide acpi_check_{mem_}region.
On Mon, 11 Feb 2008 11:55:46 -0800, Andrew Morton wrote: On Sun, 10 Feb 2008 13:25:36 +0100 Jean Delvare wrote: Andrew, both patches are Acked-by: Jean Delvare [EMAIL PROTECTED] We already have Signed-off-by:you, which I figure outranks acked-by: ;) Yeah but that wasn't the same me. That was me-developer-at-suse, who doesn't yet have the same aura as me-maintainer-of-i2c-and-former-maintainer-of-hwmon ;) and I am totally fine with you pushing them to Linus now. But of course having Mark's ack would be good too. That would be nice. But I'll merge them mid-week anyway unless Mark actually nacks them: http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch Yeah, sounds like a good plan, thanks for taking care. -- Jean Delvare - 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: [GIT PATCH] ACPI patches for 2.6.25-rc0 (#2)
On Monday 11 February 2008 09:17:43 Ingo Molnar wrote: no, it does not help - see the attached .config and the crash.log. Thanks Ingo - the cause of the crash is ACPI being disabled on your system for some reason. I can reproduce your crash every time here with acpi=off. The two WMI based drivers (acer-wmi, tc1100-wmi) in the kernel both need a simple patch each to fix this - patches to follow. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D - 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: Exposing WMI on Linux
Len, Ok, I will take a deep dive into this and try to provide answers to the questions below, including how to use the data in management frameworks such as CIMOMs. Anas Len Brown wrote: On Wednesday 30 May 2007 16:12, you wrote: Here are some pointers as promised: http://developer.novell.com/wiki/index.php/OMC This is a Novell project with many providers dealing will many aspects of the OS. They also provide RPMs for OpenSUSE and is the main source for the OpenWBEM CIMOM binaries for SUSE. http://sblim.wiki.sourceforge.net/ Is the IBM project dealing with instrumentation and home of the SFCB CIMOM targeting embedded environments and only supports CMPI providers. http://sblim.wiki.sourceforge.net/ProviderCmpiSysfs is a sysfs provider. Seems to be old but is a good example. http://openpegasus.org/ This is the home of the OpenPeagsus CIMOM, supported by multiple vendors. http://www.dmtf.org/standards/wbem/ is about the WBEM protocol. Also the tutorial is good: http://www.wbemsolutions.com/tutorials/CIM/wbem.html http://cimple.org/ tries to make writing providers easy. Anas, We could use some help on how to expose WMI to user-space in Linux. (Then we could use some help on user-space using that interface:-) Carlos has cooked up an ACPI-WMI mapping driver for Linux, and has two in-kernel platform specific drivers that want to talk to it (acer-laptop and HP Compaq TC1100 Tablets), and Matthew has been poking at an HP driver to use WMI to access some laptop functionas as well. But nobody is thinking about how to hook this up to the user-space management infrastructure in Linux, and what the kernel/user interface to to best do that would be. Carlos prototyped a sysfs I/F, but that doesn't seem to fit the WMI transaction model, so he's wondering if an ioctl I/F would be more appropriate where transaction consistency can be enforced by the driver, perhaps with a library on top of it. Please advise. thanks, -Len - 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
[PATCH][drivers/pnp/pnpacpi/core.c] __initdata is not an identifier
sparse complains at drivers/pnp/pnpacpi/core.c:39 with the error:
Trying to use reserved word '__attribute__' as identifier
Expected ) in function declarator, got .init.data
and at drivers/pnp/pnpacpi/core.c:49:38 with the error:
undefined identifier 'excluded_id_list'
With the patch below these sparse complaints do not occur
---
__initdata is not an identifier
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
index 662b4c2..c283a9a 100644
--- a/drivers/pnp/pnpacpi/core.c
+++ b/drivers/pnp/pnpacpi/core.c
@@ -36,7 +36,7 @@ static int num = 0;
* have irqs (PIC, Timer) because we call acpi_register_gsi.
* Finally, only devices that have a CRS method need to be in this list.
*/
-static struct __initdata acpi_device_id excluded_id_list[] = {
+static struct acpi_device_id excluded_id_list[] __initdata = {
{PNP0C09, 0}, /* EC */
{PNP0C0F, 0}, /* Link device */
{PNP, 0}, /* PIC */
-
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
power comsumption low and raise then
I am running kernel 2.6.24.1 on my Core2Duo Laptop. I trying to measure and lower the power consumption. I noticed that after I logged in and started KDE (3.5.8) the system needs only little power (about 9 W, measured with an external power meter, no battery plugged in). But then usually after 10-15 minutes the power consumption raises to 22-25 W. I did not start any extra programs, I do not touch the system at all just watching the powermeter ... The system is idle all the time and I do not see any significant output in syslog. I trying to find out what might cause this behavior. But I am at a loss. Can anyone help me to find out what is causing this behavior? Steffen - 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: 2.6.25-rc1 regression - suspend to ram
On Tue, Feb 12, 2008 at 12:10:54AM +0100, R. J. Wysocki wrote:
On Monday, 11 of February 2008, Lukas Hejtmanek wrote:
Hello,
Hi,
2.6.25-rc1 takes really long time till it suspends (about 30-40secs, used to
be about 5 secs at all) and it is resuming about few minutes. While
resuming,
capslock toggles the capslock led but with few secs delay.
2.6.24-git15 was OK. 2.6.24 is OK.
I have Lenovo ThinkPad T61.
If you have CONFIG_CPU_IDLE set, please try to boot with idle=poll and see if
that helps.
Just sent this patch to fix a regression in acpi processor_idle.c on another
thread. Can you try the patch below and check whether that helps.
Thanks,
Venki
Earlier patch (bc71bec91f9875ef825d12104acf3bf4ca215fa4) broke
suspend resume on many laptops. The problem was reported by
Carlos R. Mafra and Calvin Walton, who bisected the issue to above patch.
The problem was because, C2 and C3 code were calling acpi_idle_enter_c1
directly, with C2 or C3 as state parameter, while suspend/resume was in
progress. The patch bc71bec started making use of that state information,
assuming that it would always be referring to C1 state. This caused the
problem with suspend-resume as we ended up using C2/C3 state indirectly.
Fix this by adding acpi_idle_suspend check in enter_c1.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.25-rc1/drivers/acpi/processor_idle.c
===
--- linux-2.6.25-rc1.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.25-rc1/drivers/acpi/processor_idle.c
@@ -1420,6 +1420,14 @@ static int acpi_idle_enter_c1(struct cpu
return 0;
local_irq_disable();
+
+ /* Do not access any ACPI IO ports in suspend path */
+ if (acpi_idle_suspend) {
+ acpi_safe_halt();
+ local_irq_enable();
+ return 0;
+ }
+
if (pr-flags.bm_check)
acpi_idle_update_bm_rld(pr, cx);
-
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
acpi_apic_instance=2
Hi, I ran the kernel with the acpi_apic_instance=2 option and I found that the fan works different. The power supplier was attached to my laptop at the time which means that the fan should rotate continuously like usually, but it starts to work only when the cooling is needed. The computer with default instance works in that way only when the power comes from battery. So it seems that the default acpi table depends on the power state. The benefit of using acpi_apic_instance=2 is the quiet work of the plugged machine. I did not try to change the acpi instance without power supplier. cacy I have sony vaio SZ series - 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: BIOS _OSI(Linux) query ignored - PowerEdge 1950
On Monday 11 February 2008 12:27, Krzysztof Oledzki wrote:
On Sun, 10 Feb 2008, Len Brown wrote:
On Sunday 10 February 2008 17:09, Krzysztof Oledzki wrote:
Hello,
ACPI: EC: Look up EC in DSDT
ACPI: BIOS _OSI(Linux) query ignored
ACPI: DMI System Vendor: Dell Inc.
ACPI: DMI Product Name: PowerEdge 1950
ACPI: DMI Product Version:
ACPI: DMI Board Name: 0TT740
ACPI: DMI BIOS Vendor: Dell Inc.
ACPI: DMI BIOS Date: 10/27/2007
ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
Thanks for the acpidiump output.
acpi_osi=Linux is a NOP on this box.
cheers,
-Len
It looks like Dell went out of their way to make Linux a recognized OS,
but the code that actually accesses TOOS makes Linux a synonym for Vista,
which we have w/o OSI(Linux). The exception is the PCI root bridge HID/CID
exchange, where only Vista gets PCIe native.
Name (TOOS, 0x00)
Method (INIC, 0, NotSerialized)
{
If (CondRefOf (_OSI, Local0))
{
If (\_OSI (Windows 2001))
{
Store (0x05, TOOS)
}
If (\_OSI (Windows 2001.1))
{
Store (0x06, TOOS)
}
If (\_OSI (Windows 2001.1 SP1))
{
Store (0x07, TOOS)
}
If (\_OSI (Windows 2006))
{
Store (0x08, TOOS)
}
If (\_OSI (Windows 2006.1))
{
Store (0x08, TOOS)
}
If (\_OSI (Linux))
{
Store (0x01, TOOS)
# The windows compatible value of TOOS gets overwritten
# to 1 on OSI(Linux)
}
}
Else
{
Store (\_OS, Local0)
Store (SCMP (Local0, Microsoft Windows NT), Local1)
If (Not (Local1))
{
Store (0x04, TOOS)
}
Else
{
Store (SCMP (Local0, Microsoft Windows), Local2)
If (Not (Local2))
{
Store (0x02, TOOS)
}
Else
{
Store (SCMP (Local0, Microsoft WindowsME:Millennium
Edition), Local3)
If (Not (Local3))
{
Store (0x03, TOOS)
}
}
}
}
}
If (LGreaterEqual (\_SB.TOOS, 0x08))
{
Store (0x080AD041, \_SB.PCI0._HID)
Store (0x030AD041, \_SB.PCI0._CID)
}
Else
{
Store (0x030AD041, \_SB.PCI0._HID)
Store (0x080AD041, \_SB.PCI0._CID)
}
-
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 1/2] acer-wmi - Fail gracefully if ACPI is disabled
On Mon, 11 Feb 2008, Carlos Corbacho wrote:
WMI drivers, like their ACPI counterparts, should also check if ACPI is
disabled or not, and bail out if so, otherwise we cause a crash.
Shouldn't wmi_has_guid() just return false if ACPI isn't enabled, and
the drivers should just then always give up?
The proper way to get there would seem to be to just do this instead..
We should *not* add some random ACPI workarounds to individual drivers, we
should just make the wmi subsystem so robust that nobody *cares* if acpi
exists or is enabled on that machine.
Linus
---
drivers/acpi/wmi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c
index 36b84ab..457ed3d 100644
--- a/drivers/acpi/wmi.c
+++ b/drivers/acpi/wmi.c
@@ -673,11 +673,11 @@ static int __init acpi_wmi_init(void)
{
acpi_status result;
+ INIT_LIST_HEAD(wmi_blocks.list);
+
if (acpi_disabled)
return -ENODEV;
- INIT_LIST_HEAD(wmi_blocks.list);
-
result = acpi_bus_register_driver(acpi_wmi_driver);
if (result 0) {
-
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
[PATCH 2/2] tc1100-wmi - Fail gracefully if ACPI is disabled
tc1100-wmi - Fail gracefully if ACPI is disabled
From: Carlos Corbacho [EMAIL PROTECTED]
WMI drivers, like their ACPI counterparts, should also check if ACPI is
disabled or not, and bail out if so, otherwise we cause a crash.
Spotted by Ingo Molnar.
Signed-off-by: Carlos Corbacho [EMAIL PROTECTED]
CC: Ingo Molnar [EMAIL PROTECTED]
CC: Linus Torvalds [EMAIL PROTECTED]
CC: Andrew Morton [EMAIL PROTECTED]
CC: Len Brown [EMAIL PROTECTED]
---
drivers/misc/tc1100-wmi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/tc1100-wmi.c b/drivers/misc/tc1100-wmi.c
index f25e4c9..cb8f79f 100644
--- a/drivers/misc/tc1100-wmi.c
+++ b/drivers/misc/tc1100-wmi.c
@@ -263,6 +263,9 @@ static int __init tc1100_init(void)
{
int result = 0;
+ if (acpi_disabled)
+ return -ENODEV;
+
if (!wmi_has_guid(GUID))
return -ENODEV;
-
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 0/5] Laptop driver documentation changes for 2.6.25
On Monday 11 February 2008 19:23:39 Randy Dunlap wrote: On Sat, 09 Feb 2008 01:31:57 + Carlos Corbacho wrote: The following series implements the proposed creation of Documentation/laptops, and the movement of all the laptop driver documentation to this directory. I've also taken the opportunity to tack on the acer-wmi documentation in the final patch of this series. Because all the drivers in question go through the ACPI tree anyway, it's probably easiest if this change goes through the ACPI tree as well. This should all be 2.6.25 material, since there is no code change here, just rearranging the Documentation files, and updating Kconfig entries where required. I've also tested this series against Linus' latest git tree, with no problems applying it there. Hi, so should we also move Documentation/laptop-mode.txt to laptops/ dir? [CC'ing Bart Samwel on this, as he wrote Documentation/laptop-mode.txt] Yes, we probably should. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D - 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: BIOS _OSI(Linux) query ignored - PowerEdge 1950
On Sun, 10 Feb 2008, Len Brown wrote: On Sunday 10 February 2008 17:09, Krzysztof Oledzki wrote: Hello, ACPI: EC: Look up EC in DSDT ACPI: BIOS _OSI(Linux) query ignored ACPI: DMI System Vendor: Dell Inc. ACPI: DMI Product Name: PowerEdge 1950 ACPI: DMI Product Version: ACPI: DMI Board Name: 0TT740 ACPI: DMI BIOS Vendor: Dell Inc. ACPI: DMI BIOS Date: 10/27/2007 ACPI: Please send DMI info above to linux-acpi@vger.kernel.org please send me the output from acpidump. Attached. Best regards, Krzysztof Olędzki acpidump-dell1950.gz Description: Binary data
[PATCH] CPU_IDLE: Documentation for CPU_IDLE
Documentation for cpuidle infrastructure. This patch was submitted once a while back. But, somehow got dropped or never made it upstream. Resending with updates. Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Index: linux-2.6.25-rc/Documentation/cpuidle/core.txt === --- /dev/null +++ linux-2.6.25-rc/Documentation/cpuidle/core.txt @@ -0,0 +1,17 @@ + + Supporting multiple CPU idle levels in kernel + + cpuidle + +General Information: + +Various CPUs today support multiple idle levels that are differentiated +by varying exit latencies and power consumption during idle. +cpuidle is a generic in-kernel infrastructure that separates +idle policy (governor) from idle mechanism (driver) and provides a +standardized infrastructure to support independent development of +governors and drivers. + +cpuidle resides under drivers/cpuidle. + + Index: linux-2.6.25-rc/Documentation/cpuidle/driver.txt === --- /dev/null +++ linux-2.6.25-rc/Documentation/cpuidle/driver.txt @@ -0,0 +1,32 @@ + + + Supporting multiple CPU idle levels in kernel + + cpuidle drivers + + + + +cpuidle driver hooks into the cpuidle infrastructure and handles the +architecture/platform dependent part of CPU idle states. Driver +provides the platform idle state detection capability and also +has mechanisms in place to support actual entry-exit into CPU idle states. + +cpuidle driver initializes the cpuidle_device structure for each CPU device +and registers with cpuidle using cpuidle_register_device. + +It can also support the dynamic changes (like battery - AC), by using +cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device, +cpuidle_resume_and_unlock. + +Interfaces: +extern int cpuidle_register_driver(struct cpuidle_driver *drv); +extern void cpuidle_unregister_driver(struct cpuidle_driver *drv); +extern int cpuidle_register_device(struct cpuidle_device *dev); +extern void cpuidle_unregister_device(struct cpuidle_device *dev); + +extern void cpuidle_pause_and_lock(void); +extern void cpuidle_resume_and_unlock(void); +extern int cpuidle_enable_device(struct cpuidle_device *dev); +extern void cpuidle_disable_device(struct cpuidle_device *dev); + Index: linux-2.6.25-rc/Documentation/cpuidle/sysfs.txt === --- /dev/null +++ linux-2.6.25-rc/Documentation/cpuidle/sysfs.txt @@ -0,0 +1,81 @@ + + + Supporting multiple CPU idle levels in kernel + + cpuidle sysfs + +System global cpuidle related information and tunables are under +/sys/devices/system/cpu/cpuidle + +The current interfaces in this directory has self-explanatory names: +* current_driver +* current_governor_ro + +With cpuidle_sysfs_switch boot option (meant for developer testing) +following objects are visible instead. +* current_driver +* available_governors +* current_governor +In this case user can switch the governor at run time by writing +onto current_governor. + + +Per logical CPU specific cpuidle information are under +/sys/devices/system/cpu/cpuX/cpuidle +for each online cpu X + + +# ls -lR /sys/devices/system/cpu/cpu0/cpuidle/ +/sys/devices/system/cpu/cpu0/cpuidle/: +total 0 +drwxr-xr-x 2 root root 0 Feb 8 10:42 state0 +drwxr-xr-x 2 root root 0 Feb 8 10:42 state1 +drwxr-xr-x 2 root root 0 Feb 8 10:42 state2 +drwxr-xr-x 2 root root 0 Feb 8 10:42 state3 + +/sys/devices/system/cpu/cpu0/cpuidle/state0: +total 0 +-r--r--r-- 1 root root 4096 Feb 8 10:42 desc +-r--r--r-- 1 root root 4096 Feb 8 10:42 latency +-r--r--r-- 1 root root 4096 Feb 8 10:42 name +-r--r--r-- 1 root root 4096 Feb 8 10:42 power +-r--r--r-- 1 root root 4096 Feb 8 10:42 time +-r--r--r-- 1 root root 4096 Feb 8 10:42 usage + +/sys/devices/system/cpu/cpu0/cpuidle/state1: +total 0 +-r--r--r-- 1 root root 4096 Feb 8 10:42 desc +-r--r--r-- 1 root root 4096 Feb 8 10:42 latency +-r--r--r-- 1 root root 4096 Feb 8 10:42 name +-r--r--r-- 1 root root 4096 Feb 8 10:42 power +-r--r--r-- 1 root root 4096 Feb 8 10:42 time +-r--r--r-- 1 root root 4096 Feb 8 10:42 usage + +/sys/devices/system/cpu/cpu0/cpuidle/state2: +total 0 +-r--r--r-- 1 root root 4096 Feb 8 10:42 desc +-r--r--r-- 1 root root 4096 Feb 8 10:42 latency +-r--r--r-- 1 root root 4096 Feb 8 10:42 name +-r--r--r-- 1 root root 4096 Feb 8 10:42 power +-r--r--r-- 1 root root 4096 Feb 8 10:42 time +-r--r--r-- 1 root root 4096 Feb 8 10:42 usage + +/sys/devices/system/cpu/cpu0/cpuidle/state3: +total 0 +-r--r--r-- 1 root root 4096 Feb 8 10:42 desc +-r--r--r-- 1 root root 4096 Feb 8 10:42 latency +-r--r--r-- 1 root root 4096 Feb 8 10:42 name +-r--r--r-- 1 root root 4096 Feb 8 10:42 power +-r--r--r-- 1 root root 4096 Feb 8 10:42 time
Re: 2.6.25-rc1 regression - suspend to ram
On Monday, 11 of February 2008, Lukas Hejtmanek wrote: Hello, Hi, 2.6.25-rc1 takes really long time till it suspends (about 30-40secs, used to be about 5 secs at all) and it is resuming about few minutes. While resuming, capslock toggles the capslock led but with few secs delay. 2.6.24-git15 was OK. 2.6.24 is OK. I have Lenovo ThinkPad T61. If you have CONFIG_CPU_IDLE set, please try to boot with idle=poll and see if that helps. Thanks, Rafael - 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: If acpi_osi=Linux works better, pleas e notify linux-acpi@vger.kernel.org
On Feb 11, 2008 3:29 AM, Len Brown [EMAIL PROTECTED] wrote: In both BIOS V1.21 and V1.31 it appears to be a no-op. The only way I could imagine it could have an effect is if somethign in SMM is looking at the LINX variable. Based on past lack of Linux awareness from this particular vendor, the chances of that happening seem quite small. thanks, -Len It was the suspend/resume process and the subsequent use of the C2 state that made the difference. And the wireless stability is also another issue. Sorry, guess it was wishful thinking. - 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 2/5] Provide acpi_check_{mem_}region.
On Sun, 10 Feb 2008 13:25:36 +0100
Jean Delvare [EMAIL PROTECTED] wrote:
Hi Andrew,
On Thu, 7 Feb 2008 23:40:02 -0800, Andrew Morton wrote:
On Wed, 24 Oct 2007 16:32:59 +0200 Thomas Renninger [EMAIL PROTECTED]
wrote:
Provide acpi_check_{mem_}region.
Drivers can additionally check against possible ACPI interference by also
invoking this shortly before they call request_region.
If -EBUSY is returned, the driver must not load.
Use acpi_enforce_resources=strict/lax/no options to:
- strict: let conflicting drivers fail to load with an error message
- lax:let conflicting driver work normal with a warning message
- no: no functional change at all
OK, so Len has merged these into the acpi test tree. My understanding is
that once this work hits mainline, we can then merge
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch.
Correct. Same applies to a second patch:
check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
Both patches should be merged upstream at the same time.
My normal approach would be to send
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch to Mark for
inclusion in git-hwmon one Len has merged the prerequisites into mainline.
Problem is, if Len merges late in the 2.6.26 merge window, Mark might not
have time to gets these changes into mainline before 2.6.27. Which is all
getting a bit dumb considering I first merged everything in October.
Fortunately things aren't mormally _this_ inefficient when one follows the
rules - this was an unusual patchset.
But still, I think we could afford to speed things up a bit more than that.
We could ask Len to consider merging this work into 2.6.25 and then if
Mark can ack check-for-acpi-resource-conflicts-in-hwmon-drivers.patch
(below) for an akpm-merge, we're good to go. But I do recall that people
were a bit uncertain about it all back in October.
Please share your thoughts with us.
Len already merged all the acpi bits for 2.6.25 as far as I can see, so
all that is missing now is these two patches:
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch
check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
Both have been in -mm for quite some time.
Yup, the prerequisites appear to be in mainline now.
In the default mode (acpi_enforce_resources=lax) these patches simply
print warnings but still let the drivers load, so they are safe to
merge, and the sooner, the better. The idea is to get feedback on how
many systems out there have ACPI resource conflicts. Then we'll see how
we can address them (if at all.)
I don't remember anyone objecting to these patches, and anyway the
problem has been there for years and nobody took care, so if anyone
really isn't happy with the solution designed by Thomas, that person
will have to do the work and submit something better later. That
shouldn't delay the merge of what we have now.
Andrew, both patches are
Acked-by: Jean Delvare [EMAIL PROTECTED]
We already have Signed-off-by:you, which I figure outranks acked-by: ;)
and I am totally fine with you pushing them to Linus now. But of course
having Mark's ack would be good too.
That would be nice. But I'll merge them mid-week anyway unless Mark actually
nacks them:
http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
Thanks.
-
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: 2.6.25-rc1 regression - suspend to ram
On Monday, February 11, 2008 3:22 pm Venki Pallipadi wrote: On Tue, Feb 12, 2008 at 12:10:54AM +0100, R. J. Wysocki wrote: On Monday, 11 of February 2008, Lukas Hejtmanek wrote: Hello, Hi, 2.6.25-rc1 takes really long time till it suspends (about 30-40secs, used to be about 5 secs at all) and it is resuming about few minutes. While resuming, capslock toggles the capslock led but with few secs delay. 2.6.24-git15 was OK. 2.6.24 is OK. I have Lenovo ThinkPad T61. If you have CONFIG_CPU_IDLE set, please try to boot with idle=poll and see if that helps. Just sent this patch to fix a regression in acpi processor_idle.c on another thread. Can you try the patch below and check whether that helps. Excellent, that patch makes things work for me (including console restore). Thanks a lot Venki. Jesse - 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
[Bug-fix]:2.6.25-rc0 Generic thermal management [Patch 1/2]: validating input parameters
From: Thomas Sujith [EMAIL PROTECTED]
Added sanity checks for interface functions in thermal with
other modules such as fan, processor, video etc..
Signed-off-by: Thomas Sujith [EMAIL PROTECTED]
---
drivers/thermal/thermal.c | 69
+-
1 files changed, 44 insertions(+), 25 deletions(-)
Index: linux-2.6.24-rc3/drivers/thermal/thermal.c
===
--- linux-2.6.24-rc3.orig/drivers/thermal/thermal.c
+++ linux-2.6.24-rc3/drivers/thermal/thermal.c
@@ -301,13 +301,27 @@ int thermal_zone_bind_cooling_device(str
{
struct thermal_cooling_device_instance *dev;
struct thermal_cooling_device_instance *pos;
+ struct thermal_zone_device *pos1;
+ struct thermal_cooling_device *pos2;
int result;
+ if (!tz || !cdev)
+ return -EINVAL;
+
if (trip = tz-trips ||
(trip 0 trip != THERMAL_TRIPS_NONE))
return -EINVAL;
- if (!tz || !cdev)
+ list_for_each_entry(pos1, thermal_tz_list, node) {
+ if (pos1 == tz)
+ break;
+ }
+ list_for_each_entry(pos2, thermal_cdev_list, node) {
+ if (pos2 == cdev)
+ break;
+ }
+
+ if (tz != pos1 || cdev != pos2)
return -EINVAL;
dev =
@@ -373,6 +387,9 @@ int thermal_zone_unbind_cooling_device(s
{
struct thermal_cooling_device_instance *pos, *next;
+ if (!tz || !cdev)
+ return -EINVAL;
+
mutex_lock(tz-lock);
list_for_each_entry_safe(pos, next, tz-cooling_devices, node)
{
if (pos-tz == tz pos-trip == trip
@@ -427,21 +444,24 @@ struct thermal_cooling_device *thermal_c
struct thermal_zone_device *pos;
int result;
+ if (!type)
+ return ERR_PTR(-EINVAL);
+
if (strlen(type) = THERMAL_NAME_LENGTH)
- return NULL;
+ return ERR_PTR(-EINVAL);
if (!ops || !ops-get_max_state || !ops-get_cur_state ||
!ops-set_cur_state)
- return NULL;
+ return ERR_PTR(-EINVAL);
cdev = kzalloc(sizeof(struct thermal_cooling_device),
GFP_KERNEL);
if (!cdev)
- return NULL;
+ return ERR_PTR(-ENOMEM);
result = get_idr(thermal_cdev_idr, thermal_idr_lock,
cdev-id);
if (result) {
kfree(cdev);
- return NULL;
+ return ERR_PTR(result);
}
strcpy(cdev-type, type);
@@ -453,16 +473,14 @@ struct thermal_cooling_device *thermal_c
if (result) {
release_idr(thermal_cdev_idr, thermal_idr_lock,
cdev-id);
kfree(cdev);
- return NULL;
+ return ERR_PTR(result);
}
/* sys I/F */
- if (type) {
- result = device_create_file(cdev-device,
- dev_attr_cdev_type);
- if (result)
- goto unregister;
- }
+ result = device_create_file(cdev-device,
+ dev_attr_cdev_type);
+ if (result)
+ goto unregister;
result = device_create_file(cdev-device, dev_attr_max_state);
if (result)
@@ -490,7 +508,7 @@ struct thermal_cooling_device *thermal_c
unregister:
release_idr(thermal_cdev_idr, thermal_idr_lock, cdev-id);
device_unregister(cdev-device);
- return NULL;
+ return ERR_PTR(result);
}
EXPORT_SYMBOL(thermal_cooling_device_register);
@@ -559,18 +577,21 @@ struct thermal_zone_device *thermal_zone
int result;
int count;
+ if (!type)
+ return ERR_PTR(-EINVAL);
+
if (strlen(type) = THERMAL_NAME_LENGTH)
- return NULL;
+ return ERR_PTR(-EINVAL);
if (trips THERMAL_MAX_TRIPS || trips 0)
- return NULL;
+ return ERR_PTR(-EINVAL);
if (!ops || !ops-get_temp)
- return NULL;
+ return ERR_PTR(-EINVAL);
tz = kzalloc(sizeof(struct thermal_zone_device), GFP_KERNEL);
if (!tz)
- return NULL;
+ return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(tz-cooling_devices);
idr_init(tz-idr);
@@ -578,7 +599,7 @@ struct thermal_zone_device *thermal_zone
result = get_idr(thermal_tz_idr, thermal_idr_lock, tz-id);
if (result) {
kfree(tz);
- return NULL;
+ return ERR_PTR(result);
}
strcpy(tz-type, type);
@@ -591,15 +612,13 @@ struct thermal_zone_device *thermal_zone
if (result) {
release_idr(thermal_tz_idr, thermal_idr_lock, tz-id);
kfree(tz);
- return NULL;
+ return ERR_PTR(result);
}
/* sys I/F */
-
[Bug-fix]:2.6.25-rc0 Generic thermal management:ACPI [Patch 2/2]: buildfix for CONFIG_THERMAL=n
From: Thomas Sujith [EMAIL PROTECTED]
Conditional dependency is being added for the generic thermal management
driver so that ACPI drivers can work without the presence of generic
thermal driver. Additional checks are added to fan,video,processor
and intel_menlow driver to have the right interpretation of
returned data.
Signed-off-by: Thomas Sujith [EMAIL PROTECTED]
---
drivers/acpi/fan.c| 31 +++
drivers/acpi/processor_core.c | 32 +++-
drivers/acpi/video.c |4
drivers/misc/intel_menlow.c | 12
include/linux/thermal.h | 25 -
5 files changed, 70 insertions(+), 34 deletions(-)
Index: linux-2.6.24-rc3/drivers/acpi/fan.c
===
--- linux-2.6.24-rc3.orig/drivers/acpi/fan.c
+++ linux-2.6.24-rc3/drivers/acpi/fan.c
@@ -248,22 +248,29 @@ static int acpi_fan_add(struct acpi_devi
cdev = thermal_cooling_device_register(Fan, device,
fan_cooling_ops);
- if (cdev)
+ if (IS_ERR(cdev)) {
+ result = PTR_ERR(cdev);
+ goto end;
+ }
+
+ if (cdev) {
printk(KERN_INFO PREFIX
%s is registered as cooling_device%d\n,
device-dev.bus_id, cdev-id);
- else
- goto end;
- acpi_driver_data(device) = cdev;
- result = sysfs_create_link(device-dev.kobj,
cdev-device.kobj,
- thermal_cooling);
- if (result)
- return result;
- result = sysfs_create_link(cdev-device.kobj,
device-dev.kobj,
- device);
-if (result)
-return result;
+ acpi_driver_data(device) = cdev;
+ result = sysfs_create_link(device-dev.kobj,
+ cdev-device.kobj,
+ thermal_cooling);
+ if (result)
+ return result;
+
+ result = sysfs_create_link(cdev-device.kobj,
+ device-dev.kobj,
+ device);
+ if (result)
+ return result;
+ }
result = acpi_fan_add_fs(device);
if (result)
Index: linux-2.6.24-rc3/drivers/acpi/processor_core.c
===
--- linux-2.6.24-rc3.orig/drivers/acpi/processor_core.c
+++ linux-2.6.24-rc3/drivers/acpi/processor_core.c
@@ -670,21 +670,27 @@ static int __cpuinit acpi_processor_star
pr-cdev = thermal_cooling_device_register(Processor, device,
processor_cooling_ops);
- if (pr-cdev)
- printk(KERN_INFO PREFIX
- %s is registered as cooling_device%d\n,
- device-dev.bus_id, pr-cdev-id);
- else
+ if (IS_ERR(pr-cdev)) {
+ result = PTR_ERR(pr-cdev);
goto end;
+ }
- result = sysfs_create_link(device-dev.kobj,
pr-cdev-device.kobj,
- thermal_cooling);
- if (result)
- return result;
- result = sysfs_create_link(pr-cdev-device.kobj,
device-dev.kobj,
- device);
- if (result)
- return result;
+ if (pr-cdev) {
+ printk(KERN_INFO PREFIX
+ %s is registered as cooling_device%d\n,
+ device-dev.bus_id, pr-cdev-id);
+
+ result = sysfs_create_link(device-dev.kobj,
+ pr-cdev-device.kobj,
+ thermal_cooling);
+ if (result)
+ return result;
+ result = sysfs_create_link(pr-cdev-device.kobj,
+ device-dev.kobj,
+ device);
+ if (result)
+ return result;
+ }
if (pr-flags.throttling) {
printk(KERN_INFO PREFIX %s [%s] (supports,
Index: linux-2.6.24-rc3/drivers/acpi/video.c
===
--- linux-2.6.24-rc3.orig/drivers/acpi/video.c
+++ linux-2.6.24-rc3/drivers/acpi/video.c
@@ -720,6 +720,10 @@ static void acpi_video_device_find_cap(s
device-cdev = thermal_cooling_device_register(LCD,
device-dev,
video_cooling_ops);
+
+ if (IS_ERR(device-cdev))
+ return;
+
if (device-cdev) {
printk(KERN_INFO PREFIX
%s is registered as
cooling_device%d\n,
Index:
dmi info requested...
ACPI: DMI System Vendor: Dell Inc. ACPI: DMI Product Name: Precision WorkStation 690 ACPI: DMI Product Version: ACPI: DMI Board Name: 0MY171 ACPI: DMI BIOS Vendor: Dell Inc. ACPI: DMI BIOS Date: 08/20/2007 ACPI: Please send DMI info above to linux-acpi@vger.kernel.org Note my 410 Workstation ID's DMI as 2.2, but doesn't seem to provide any output. Should it at least provide the send DMI info line if it is enabled correctly? What's this for, anyway? - 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
[PATCH] ACPI, CPU_IDLE: Add more information about C-states
From: Venkatesh Pallipadi [EMAIL PROTECTED]
Add a new sysfs entry under cpuidle states. desc - can be used by driver to
communicate to userspace any specific information about the state.
This helps in identifying the exact hardware C-states behind the ACPI C-state
definition.
Idea is to export this through powertop, which will help to map the C-state
reported by powertop to actual hardware C-state.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6.25-rc/arch/x86/kernel/acpi/cstate.c
===
--- linux-2.6.25-rc.orig/arch/x86/kernel/acpi/cstate.c
+++ linux-2.6.25-rc/arch/x86/kernel/acpi/cstate.c
@@ -126,6 +126,8 @@ int acpi_processor_ffh_cstate_probe(unsi
printk(KERN_DEBUG Monitor-Mwait will be used to enter C-%d
state\n, cx-type);
}
+ snprintf(cx-desc, ACPI_CX_DESC_LEN, ACPI FFH INTEL MWAIT 0x%x,
+cx-address);
out:
set_cpus_allowed(current, saved_mask);
Index: linux-2.6.25-rc/drivers/acpi/processor_idle.c
===
--- linux-2.6.25-rc.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.25-rc/drivers/acpi/processor_idle.c
@@ -917,11 +917,16 @@ static int acpi_processor_get_power_info
* Otherwise, ignore this info and continue.
*/
cx.entry_method = ACPI_CSTATE_HALT;
+ snprintf(cx.desc, ACPI_CX_DESC_LEN, ACPI HLT);
} else {
continue;
}
+ } else {
+ snprintf(cx.desc, ACPI_CX_DESC_LEN, ACPI IOPORT 0x%x,
+cx.address);
}
+
obj = (element-package.elements[2]);
if (obj-type != ACPI_TYPE_INTEGER)
continue;
@@ -1620,6 +1625,11 @@ static int acpi_processor_setup_cpuidle(
return -EINVAL;
}
+ for (i = 0; i CPUIDLE_STATE_MAX; i++) {
+ dev-states[i].name[0] = '\0';
+ dev-states[i].desc[0] = '\0';
+ }
+
for (i = 1; i ACPI_PROCESSOR_MAX_POWER i = max_cstate; i++) {
cx = pr-power.states[i];
state = dev-states[count];
@@ -1636,6 +1646,7 @@ static int acpi_processor_setup_cpuidle(
cpuidle_set_statedata(state, cx);
snprintf(state-name, CPUIDLE_NAME_LEN, C%d, i);
+ strncpy(state-desc, cx-desc, CPUIDLE_DESC_LEN);
state-exit_latency = cx-latency;
state-target_residency = cx-latency * 6;
state-power_usage = cx-power;
Index: linux-2.6.25-rc/drivers/cpuidle/sysfs.c
===
--- linux-2.6.25-rc.orig/drivers/cpuidle/sysfs.c
+++ linux-2.6.25-rc/drivers/cpuidle/sysfs.c
@@ -218,16 +218,23 @@ static ssize_t show_state_##_name(struct
return sprintf(buf, %u\n, state-_name);\
}
-static ssize_t show_state_name(struct cpuidle_state *state, char *buf)
-{
- return sprintf(buf, %s\n, state-name);
+#define define_show_state_str_function(_name) \
+static ssize_t show_state_##_name(struct cpuidle_state *state, char *buf) \
+{ \
+ if (state-_name[0] == '\0')\
+ return sprintf(buf, null\n);\
+ return sprintf(buf, %s\n, state-_name);\
}
define_show_state_function(exit_latency)
define_show_state_function(power_usage)
define_show_state_function(usage)
define_show_state_function(time)
+define_show_state_str_function(name)
+define_show_state_str_function(desc)
+
define_one_state_ro(name, show_state_name);
+define_one_state_ro(desc, show_state_desc);
define_one_state_ro(latency, show_state_exit_latency);
define_one_state_ro(power, show_state_power_usage);
define_one_state_ro(usage, show_state_usage);
@@ -235,6 +242,7 @@ define_one_state_ro(time, show_state_tim
static struct attribute *cpuidle_state_default_attrs[] = {
attr_name.attr,
+ attr_desc.attr,
attr_latency.attr,
attr_power.attr,
attr_usage.attr,
Index: linux-2.6.25-rc/include/acpi/processor.h
===
--- linux-2.6.25-rc.orig/include/acpi/processor.h
+++ linux-2.6.25-rc/include/acpi/processor.h
@@ -32,9 +32,11 @@
#define DOMAIN_COORD_TYPE_SW_ANY 0xfd
#define DOMAIN_COORD_TYPE_HW_ALL 0xfe
-#define ACPI_CSTATE_SYSTEMIO (0)
-#define ACPI_CSTATE_FFH(1)
-#define ACPI_CSTATE_HALT (2)
+#define ACPI_CSTATE_SYSTEMIO 0
+#define ACPI_CSTATE_FFH1
+#define ACPI_CSTATE_HALT 2
+
+#define ACPI_CX_DESC_LEN 32
/* Power Management */
@@ -74,6 +76,7 @@ struct acpi_processor_cx {
u64 time;
struct acpi_processor_cx_policy promotion;
struct
