* [patch 17/23] acpi: ia64: wake on LAN fix
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, takeuchi_satoru, tony.luck
From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Currently wakeup capability is available if and only if
CONFIG_ACPI_SLEEP=y. But S5 is not a sleep state. This patch makes ACPI
subsystem to be able to wakeup from S5 state even if sleep mode is not
supported.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/sleep/Makefile | 3 +--
drivers/acpi/sleep/poweroff.c | 1 +
drivers/acpi/sleep/proc.c | 16 ++++++++++++++++
drivers/acpi/sleep/wakeup.c | 2 ++
4 files changed, 20 insertions(+), 2 deletions(-)
diff -puN drivers/acpi/sleep/Makefile~acpi-ia64-wake-on-lan-fix drivers/acpi/sleep/Makefile
--- devel/drivers/acpi/sleep/Makefile~acpi-ia64-wake-on-lan-fix 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/sleep/Makefile 2006-03-21 22:30:06.000000000 -0800
@@ -1,5 +1,4 @@
-obj-y := poweroff.o wakeup.o
+obj-y := poweroff.o wakeup.o proc.o
obj-$(CONFIG_ACPI_SLEEP) += main.o
-obj-$(CONFIG_ACPI_SLEEP_PROC_FS) += proc.o
EXTRA_CFLAGS += $(ACPI_CFLAGS)
diff -puN drivers/acpi/sleep/poweroff.c~acpi-ia64-wake-on-lan-fix drivers/acpi/sleep/poweroff.c
--- devel/drivers/acpi/sleep/poweroff.c~acpi-ia64-wake-on-lan-fix 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/sleep/poweroff.c 2006-03-21 22:30:06.000000000 -0800
@@ -45,6 +45,7 @@ void acpi_power_off(void)
/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
printk("%s called\n", __FUNCTION__);
local_irq_disable();
+ acpi_enable_wakeup_device(ACPI_STATE_S5);
/* Some SMP machines only can poweroff in boot CPU */
acpi_enter_sleep_state(ACPI_STATE_S5);
}
diff -puN drivers/acpi/sleep/proc.c~acpi-ia64-wake-on-lan-fix drivers/acpi/sleep/proc.c
--- devel/drivers/acpi/sleep/proc.c~acpi-ia64-wake-on-lan-fix 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/sleep/proc.c 2006-03-21 22:30:06.000000000 -0800
@@ -70,6 +70,7 @@ acpi_system_write_sleep(struct file *fil
}
#endif /* CONFIG_ACPI_SLEEP_PROC_SLEEP */
+#ifdef CONFIG_ACPI_SLEEP
static int acpi_system_alarm_seq_show(struct seq_file *seq, void *offset)
{
u32 sec, min, hr;
@@ -339,6 +340,7 @@ acpi_system_write_alarm(struct file *fil
end:
return_VALUE(result ? result : count);
}
+#endif /* CONFIG_ACPI_SLEEP */
extern struct list_head acpi_wakeup_device_list;
extern spinlock_t acpi_device_lock;
@@ -357,6 +359,10 @@ acpi_system_wakeup_device_seq_show(struc
if (!dev->wakeup.flags.valid)
continue;
+#ifndef CONFIG_ACPI_SLEEP
+ if (dev->wakeup.sleep_state != ACPI_STATE_S5)
+ continue;
+#endif
spin_unlock(&acpi_device_lock);
seq_printf(seq, "%4s %4d %s%8s\n",
dev->pnp.bus_id,
@@ -394,6 +400,10 @@ acpi_system_write_wakeup_device(struct f
container_of(node, struct acpi_device, wakeup_list);
if (!dev->wakeup.flags.valid)
continue;
+#ifndef CONFIG_ACPI_SLEEP
+ if (dev->wakeup.sleep_state != ACPI_STATE_S5)
+ continue;
+#endif
if (!strncmp(dev->pnp.bus_id, str, 4)) {
dev->wakeup.state.enabled =
@@ -452,6 +462,7 @@ static struct file_operations acpi_syste
};
#endif /* CONFIG_ACPI_SLEEP_PROC_SLEEP */
+#ifdef CONFIG_ACPI_SLEEP
static struct file_operations acpi_system_alarm_fops = {
.open = acpi_system_alarm_open_fs,
.read = seq_read,
@@ -467,6 +478,7 @@ static u32 rtc_handler(void *context)
return ACPI_INTERRUPT_HANDLED;
}
+#endif /* CONFIG_ACPI_SLEEP */
static int acpi_sleep_proc_init(void)
{
@@ -484,12 +496,14 @@ static int acpi_sleep_proc_init(void)
entry->proc_fops = &acpi_system_sleep_fops;
#endif
+#ifdef CONFIG_ACPI_SLEEP
/* 'alarm' [R/W] */
entry =
create_proc_entry("alarm", S_IFREG | S_IRUGO | S_IWUSR,
acpi_root_dir);
if (entry)
entry->proc_fops = &acpi_system_alarm_fops;
+#endif
/* 'wakeup device' [R/W] */
entry =
@@ -498,7 +512,9 @@ static int acpi_sleep_proc_init(void)
if (entry)
entry->proc_fops = &acpi_system_wakeup_device_fops;
+#ifdef CONFIG_ACPI_SLEEP
acpi_install_fixed_event_handler(ACPI_EVENT_RTC, rtc_handler, NULL);
+#endif
return 0;
}
diff -puN drivers/acpi/sleep/wakeup.c~acpi-ia64-wake-on-lan-fix drivers/acpi/sleep/wakeup.c
--- devel/drivers/acpi/sleep/wakeup.c~acpi-ia64-wake-on-lan-fix 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/sleep/wakeup.c 2006-03-21 22:30:06.000000000 -0800
@@ -48,6 +48,7 @@ void acpi_enable_wakeup_device_prep(u8 s
}
spin_unlock(&acpi_device_lock);
}
+#endif
/**
* acpi_enable_wakeup_device - enable wakeup devices
@@ -100,6 +101,7 @@ void acpi_enable_wakeup_device(u8 sleep_
spin_unlock(&acpi_device_lock);
}
+#ifdef CONFIG_ACPI_SLEEP
/**
* acpi_disable_wakeup_device - disable devices' wakeup capability
* @sleep_state: ACPI state
_
^ permalink raw reply
* [patch 18/23] ACPI: remove __init/__exit from Asus .add()/.remove() methods
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Even though the devices claimed by asus_acpi.c can not be hot-plugged, the
driver registration infrastructure allows the .add() and .remove() methods to
be called at any time while the driver is registered. So remove __init and
__exit from them.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/asus_acpi.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff -puN drivers/acpi/asus_acpi.c~acpi-remove-__init-__exit-from-asus-add-remove-methods drivers/acpi/asus_acpi.c
--- devel/drivers/acpi/asus_acpi.c~acpi-remove-__init-__exit-from-asus-add-remove-methods 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/asus_acpi.c 2006-03-21 22:30:06.000000000 -0800
@@ -817,7 +817,7 @@ typedef int (proc_writefunc) (struct fil
unsigned long count, void *data);
static int
-__init asus_proc_add(char *name, proc_writefunc * writefunc,
+asus_proc_add(char *name, proc_writefunc * writefunc,
proc_readfunc * readfunc, mode_t mode,
struct acpi_device *device)
{
@@ -836,7 +836,7 @@ __init asus_proc_add(char *name, proc_wr
return 0;
}
-static int __init asus_hotk_add_fs(struct acpi_device *device)
+static int asus_hotk_add_fs(struct acpi_device *device)
{
struct proc_dir_entry *proc;
mode_t mode;
@@ -954,7 +954,7 @@ static void asus_hotk_notify(acpi_handle
* This function is used to initialize the hotk with right values. In this
* method, we can make all the detection we want, and modify the hotk struct
*/
-static int __init asus_hotk_get_info(void)
+static int asus_hotk_get_info(void)
{
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_buffer dsdt = { ACPI_ALLOCATE_BUFFER, NULL };
@@ -1101,7 +1101,7 @@ static int __init asus_hotk_get_info(voi
return AE_OK;
}
-static int __init asus_hotk_check(void)
+static int asus_hotk_check(void)
{
int result = 0;
@@ -1121,7 +1121,7 @@ static int __init asus_hotk_check(void)
static int asus_hotk_found;
-static int __init asus_hotk_add(struct acpi_device *device)
+static int asus_hotk_add(struct acpi_device *device)
{
acpi_status status = AE_OK;
int result;
_
^ permalink raw reply
* [patch 15/23] HPET: fix ACPI memory range length handling
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
ACPI address space descriptors contain _MIN, _MAX, and _LEN. _MIN and _MAX
are the bounds within which the region can be moved (this is clarified in
Table 6-38 of the ACPI 3.0 spec). We should use _LEN to determine the size
of the region, not _MAX - _MIN + 1.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/char/hpet.c | 5 +----
1 files changed, 1 insertion(+), 4 deletions(-)
diff -puN drivers/char/hpet.c~hpet-fix-acpi-memory-range-length-handling drivers/char/hpet.c
--- devel/drivers/char/hpet.c~hpet-fix-acpi-memory-range-length-handling 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/char/hpet.c 2006-03-21 22:30:06.000000000 -0800
@@ -925,11 +925,8 @@ static acpi_status hpet_resources(struct
status = acpi_resource_to_address64(res, &addr);
if (ACPI_SUCCESS(status)) {
- unsigned long size;
-
- size = addr.maximum - addr.minimum + 1;
hdp->hd_phys_address = addr.minimum;
- hdp->hd_address = ioremap(addr.minimum, size);
+ hdp->hd_address = ioremap(addr.minimum, addr.address_length);
if (hpet_is_known(hdp)) {
printk(KERN_DEBUG "%s: 0x%lx is busy\n",
_
^ permalink raw reply
* [patch 14/23] ACPI: fix memory hotplug range length handling
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Address space descriptors contain _MIN, _MAX, and _LEN. _MIN and _MAX are
the bounds within which the region can be moved (this is clarified in Table
6-38 of the ACPI 3.0 spec). We should use _LEN to determine the size of
the region, not _MAX - _MIN + 1.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/acpi_memhotplug.c | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff -puN drivers/acpi/acpi_memhotplug.c~acpi-fix-memory-hotplug-range-length-handling drivers/acpi/acpi_memhotplug.c
--- devel/drivers/acpi/acpi_memhotplug.c~acpi-fix-memory-hotplug-range-length-handling 2006-03-21 22:30:06.000000000 -0800
+++ devel-akpm/drivers/acpi/acpi_memhotplug.c 2006-03-21 22:30:06.000000000 -0800
@@ -74,7 +74,7 @@ struct acpi_memory_device {
unsigned short caching; /* memory cache attribute */
unsigned short write_protect; /* memory read/write attribute */
u64 start_addr; /* Memory Range start physical addr */
- u64 end_addr; /* Memory Range end physical addr */
+ u64 length; /* Memory Range length */
};
static int
@@ -97,12 +97,11 @@ acpi_memory_get_device_resources(struct
if (ACPI_SUCCESS(status)) {
if (address64.resource_type == ACPI_MEMORY_RANGE) {
/* Populate the structure */
- mem_device->caching =
- address64.info.mem.caching;
+ mem_device->caching = address64.info.mem.caching;
mem_device->write_protect =
address64.info.mem.write_protect;
mem_device->start_addr = address64.minimum;
- mem_device->end_addr = address64.maximum;
+ mem_device->length = address64.address_length;
}
}
@@ -197,8 +196,7 @@ static int acpi_memory_enable_device(str
* Tell the VM there is more memory here...
* Note: Assume that this function returns zero on success
*/
- result = add_memory(mem_device->start_addr,
- (mem_device->end_addr - mem_device->start_addr) + 1);
+ result = add_memory(mem_device->start_addr, mem_device->length);
if (result) {
ACPI_ERROR((AE_INFO, "add_memory failed"));
mem_device->state = MEMORY_INVALID_STATE;
@@ -247,7 +245,7 @@ static int acpi_memory_disable_device(st
{
int result;
u64 start = mem_device->start_addr;
- u64 len = mem_device->end_addr - start + 1;
+ u64 len = mem_device->length;
ACPI_FUNCTION_TRACE("acpi_memory_disable_device");
_
^ permalink raw reply
* [patch 13/23] ACPI: print wakeup device list on same line as label
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Print the ACPI wakeup device list on the same line as the label to make
"dmesg | grep ACPI" output more useful.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/sleep/wakeup.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/acpi/sleep/wakeup.c~acpi-print-wakeup-device-list-on-same-line-as-label drivers/acpi/sleep/wakeup.c
--- devel/drivers/acpi/sleep/wakeup.c~acpi-print-wakeup-device-list-on-same-line-as-label 2006-03-21 22:30:05.000000000 -0800
+++ devel-akpm/drivers/acpi/sleep/wakeup.c 2006-03-21 22:30:05.000000000 -0800
@@ -155,7 +155,7 @@ static int __init acpi_wakeup_device_ini
if (acpi_disabled)
return 0;
- printk("ACPI wakeup devices: \n");
+ printk(KERN_INFO PREFIX "wakeup devices: ");
spin_lock(&acpi_device_lock);
list_for_each_safe(node, next, &acpi_wakeup_device_list) {
_
^ permalink raw reply
* [patch 11/23] ACPI: make acpi_bus_register_driver() return success/failure, not device count
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
acpi_bus_register_driver() should not return the number of devices claimed.
We're not asking to find devices, we're making a driver available to devices,
including hot-pluggable devices that may appear in the future.
I audited all callers of acpi_bus_register_driver(), and except asus_acpi.c
and sonypi.c (fixed in previous patches), all either ignore the return value
or test only for failure (<0).
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/scan.c | 16 +++++-----------
1 files changed, 5 insertions(+), 11 deletions(-)
diff -puN drivers/acpi/scan.c~acpi-make-acpi_bus_register_driver-return-success-failure-not-device-count drivers/acpi/scan.c
--- devel/drivers/acpi/scan.c~acpi-make-acpi_bus_register_driver-return-success-failure-not-device-count 2006-03-21 22:30:05.000000000 -0800
+++ devel-akpm/drivers/acpi/scan.c 2006-03-21 22:30:05.000000000 -0800
@@ -549,10 +549,9 @@ static int acpi_start_single_object(stru
return_VALUE(result);
}
-static int acpi_driver_attach(struct acpi_driver *drv)
+static void acpi_driver_attach(struct acpi_driver *drv)
{
struct list_head *node, *next;
- int count = 0;
ACPI_FUNCTION_TRACE("acpi_driver_attach");
@@ -569,7 +568,6 @@ static int acpi_driver_attach(struct acp
if (!acpi_bus_driver_init(dev, drv)) {
acpi_start_single_object(dev);
atomic_inc(&drv->references);
- count++;
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Found driver [%s] for device [%s]\n",
drv->name, dev->pnp.bus_id));
@@ -578,7 +576,6 @@ static int acpi_driver_attach(struct acp
spin_lock(&acpi_device_lock);
}
spin_unlock(&acpi_device_lock);
- return_VALUE(count);
}
static int acpi_driver_detach(struct acpi_driver *drv)
@@ -611,14 +608,11 @@ static int acpi_driver_detach(struct acp
* @driver: driver being registered
*
* Registers a driver with the ACPI bus. Searches the namespace for all
- * devices that match the driver's criteria and binds. Returns the
- * number of devices that were claimed by the driver, or a negative
- * error status for failure.
+ * devices that match the driver's criteria and binds. Returns zero for
+ * success or a negative error status for failure.
*/
int acpi_bus_register_driver(struct acpi_driver *driver)
{
- int count;
-
ACPI_FUNCTION_TRACE("acpi_bus_register_driver");
if (acpi_disabled)
@@ -630,9 +624,9 @@ int acpi_bus_register_driver(struct acpi
spin_lock(&acpi_device_lock);
list_add_tail(&driver->node, &acpi_bus_drivers);
spin_unlock(&acpi_device_lock);
- count = acpi_driver_attach(driver);
+ acpi_driver_attach(driver);
- return_VALUE(count);
+ return_VALUE(0);
}
EXPORT_SYMBOL(acpi_bus_register_driver);
_
^ permalink raw reply
* [patch 12/23] ACPI: simplify scan.c coding
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
No functional changes; just remove leftover, unused "buffer" and simplify
control flow (no need to remember error values and goto the end, when we can
simply return the value directly).
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/scan.c | 36 +++++++++++++-----------------------
1 files changed, 13 insertions(+), 23 deletions(-)
diff -puN drivers/acpi/scan.c~acpi-simplify-scanc-coding drivers/acpi/scan.c
--- devel/drivers/acpi/scan.c~acpi-simplify-scanc-coding 2006-03-21 22:30:05.000000000 -0800
+++ devel-akpm/drivers/acpi/scan.c 2006-03-21 22:30:05.000000000 -0800
@@ -236,12 +236,9 @@ static int acpi_bus_get_power_flags(stru
int acpi_match_ids(struct acpi_device *device, char *ids)
{
- int error = 0;
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
-
if (device->flags.hardware_id)
if (strstr(ids, device->pnp.hardware_id))
- goto Done;
+ return 0;
if (device->flags.compatible_ids) {
struct acpi_compatible_id_list *cid_list = device->pnp.cid_list;
@@ -250,15 +247,10 @@ int acpi_match_ids(struct acpi_device *d
/* compare multiple _CID entries against driver ids */
for (i = 0; i < cid_list->count; i++) {
if (strstr(ids, cid_list->id[i].value))
- goto Done;
+ return 0;
}
}
- error = -ENOENT;
-
- Done:
- if (buffer.pointer)
- acpi_os_free(buffer.pointer);
- return error;
+ return -ENOENT;
}
static acpi_status
@@ -640,21 +632,19 @@ EXPORT_SYMBOL(acpi_bus_register_driver);
*/
int acpi_bus_unregister_driver(struct acpi_driver *driver)
{
- int error = 0;
-
ACPI_FUNCTION_TRACE("acpi_bus_unregister_driver");
- if (driver) {
- acpi_driver_detach(driver);
+ if (!driver)
+ return_VALUE(-EINVAL);
- if (!atomic_read(&driver->references)) {
- spin_lock(&acpi_device_lock);
- list_del_init(&driver->node);
- spin_unlock(&acpi_device_lock);
- }
- } else
- error = -EINVAL;
- return_VALUE(error);
+ acpi_driver_detach(driver);
+
+ if (!atomic_read(&driver->references)) {
+ spin_lock(&acpi_device_lock);
+ list_del_init(&driver->node);
+ spin_unlock(&acpi_device_lock);
+ }
+ return_VALUE(0);
}
EXPORT_SYMBOL(acpi_bus_unregister_driver);
_
^ permalink raw reply
* [patch 10/23] ACPI: fix sonypi ACPI driver registration
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Remove the assumption that acpi_bus_register_driver() returns the number of
devices claimed. Returning the count is unreliable because devices may be
hot-plugged in the future (admittedly not applicable for this driver).
This also fixes a bug: if sonypi_acpi_driver was registered but found no
devices, sonypi_exit() did not unregister it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/char/sonypi.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff -puN drivers/char/sonypi.c~acpi-fix-sonypi-acpi-driver-registration drivers/char/sonypi.c
--- devel/drivers/char/sonypi.c~acpi-fix-sonypi-acpi-driver-registration 2006-03-21 22:30:05.000000000 -0800
+++ devel-akpm/drivers/char/sonypi.c 2006-03-21 22:30:05.000000000 -0800
@@ -512,7 +512,7 @@ static struct sonypi_device {
#ifdef CONFIG_ACPI
static struct acpi_device *sonypi_acpi_device;
-static int acpi_enabled;
+static int acpi_driver_registered;
#endif
static int sonypi_ec_write(u8 addr, u8 value)
@@ -869,7 +869,7 @@ found:
sonypi_report_input_event(event);
#ifdef CONFIG_ACPI
- if (acpi_enabled)
+ if (sonypi_acpi_device)
acpi_bus_generate_event(sonypi_acpi_device, 1, event);
#endif
@@ -1548,8 +1548,8 @@ static int __init sonypi_init(void)
goto err_free_device;
#ifdef CONFIG_ACPI
- if (acpi_bus_register_driver(&sonypi_acpi_driver) > 0)
- acpi_enabled = 1;
+ if (acpi_bus_register_driver(&sonypi_acpi_driver) >= 0)
+ acpi_driver_registered = 1;
#endif
return 0;
@@ -1564,7 +1564,7 @@ static int __init sonypi_init(void)
static void __exit sonypi_exit(void)
{
#ifdef CONFIG_ACPI
- if (acpi_enabled)
+ if (acpi_driver_registered)
acpi_bus_unregister_driver(&sonypi_acpi_driver);
#endif
platform_device_unregister(sonypi_platform_device);
_
^ permalink raw reply
* [patch 09/23] ACPI: update asus_acpi driver registration
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Remove the assumption that acpi_bus_register_driver() returns the number of
devices claimed. Returning the count is unreliable because devices may be
hot-plugged in the future (admittedly not applicable for this driver).
Since the hardware for this driver is not hot-pluggable, determine whether the
hardware is present by noticing calls to the .add() method. It would be
better to probe the ACPI namespace for the ASUS HIDs, and load the driver only
when we find one, but ACPI doesn't support that yet.
I don't have an ASUS laptop to test on, but on my HP dl360, it does report the
appropriate error when attempting to load the module:
$ sudo insmod drivers/acpi/asus_acpi.ko
insmod: error inserting 'drivers/acpi/asus_acpi.ko': -1 No such device
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/asus_acpi.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletion(-)
diff -puN drivers/acpi/asus_acpi.c~acpi-update-asus_acpi-driver-registration drivers/acpi/asus_acpi.c
--- devel/drivers/acpi/asus_acpi.c~acpi-update-asus_acpi-driver-registration 2006-03-21 22:30:05.000000000 -0800
+++ devel-akpm/drivers/acpi/asus_acpi.c 2006-03-21 22:30:05.000000000 -0800
@@ -1119,6 +1119,8 @@ static int __init asus_hotk_check(void)
return result;
}
+static int asus_hotk_found;
+
static int __init asus_hotk_add(struct acpi_device *device)
{
acpi_status status = AE_OK;
@@ -1180,6 +1182,8 @@ static int __init asus_hotk_add(struct a
}
}
+ asus_hotk_found = 1;
+
end:
if (result) {
kfree(hotk);
@@ -1226,7 +1230,19 @@ static int __init asus_acpi_init(void)
asus_proc_dir->owner = THIS_MODULE;
result = acpi_bus_register_driver(&asus_hotk_driver);
- if (result < 1) {
+ if (result < 0) {
+ remove_proc_entry(PROC_ASUS, acpi_root_dir);
+ return -ENODEV;
+ }
+
+ /*
+ * This is a bit of a kludge. We only want this module loaded
+ * for ASUS systems, but there's currently no way to probe the
+ * ACPI namespace for ASUS HIDs. So we just return failure if
+ * we didn't find one, which will cause the module to be
+ * unloaded.
+ */
+ if (!asus_hotk_found) {
acpi_bus_unregister_driver(&asus_hotk_driver);
remove_proc_entry(PROC_ASUS, acpi_root_dir);
return -ENODEV;
_
^ permalink raw reply
* [patch 02/23] sem2mutex: drivers/acpi/
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, arjan, mingo
From: Arjan van de Ven <arjan@infradead.org>
Semaphore to mutex conversion.
The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/processor_perflib.c | 27 ++++++++++++++-------------
drivers/acpi/scan.c | 3 ++-
2 files changed, 16 insertions(+), 14 deletions(-)
diff -puN drivers/acpi/processor_perflib.c~sem2mutex-drivers-acpi drivers/acpi/processor_perflib.c
--- devel/drivers/acpi/processor_perflib.c~sem2mutex-drivers-acpi 2006-03-21 22:30:03.000000000 -0800
+++ devel-akpm/drivers/acpi/processor_perflib.c 2006-03-21 22:30:03.000000000 -0800
@@ -34,6 +34,7 @@
#ifdef CONFIG_X86_ACPI_CPUFREQ_PROC_INTF
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
+#include <linux/mutex.h>
#include <asm/uaccess.h>
#endif
@@ -48,7 +49,7 @@
#define _COMPONENT ACPI_PROCESSOR_COMPONENT
ACPI_MODULE_NAME("acpi_processor")
-static DECLARE_MUTEX(performance_sem);
+static DEFINE_MUTEX(performance_mutex);
/*
* _PPC support is implemented as a CPUfreq policy notifier:
@@ -72,7 +73,7 @@ static int acpi_processor_ppc_notifier(s
struct acpi_processor *pr;
unsigned int ppc = 0;
- down(&performance_sem);
+ mutex_lock(&performance_mutex);
if (event != CPUFREQ_INCOMPATIBLE)
goto out;
@@ -93,7 +94,7 @@ static int acpi_processor_ppc_notifier(s
core_frequency * 1000);
out:
- up(&performance_sem);
+ mutex_unlock(&performance_mutex);
return 0;
}
@@ -620,7 +621,7 @@ int acpi_processor_preregister_performan
ACPI_FUNCTION_TRACE("acpi_processor_preregister_performance");
- down(&performance_sem);
+ mutex_lock(&performance_mutex);
retval = 0;
@@ -768,7 +769,7 @@ err_ret:
pr->performance = NULL; /* Will be set for real in register */
}
- up(&performance_sem);
+ mutex_unlock(&performance_mutex);
return_VALUE(retval);
}
EXPORT_SYMBOL(acpi_processor_preregister_performance);
@@ -785,16 +786,16 @@ acpi_processor_register_performance(stru
if (!(acpi_processor_ppc_status & PPC_REGISTERED))
return_VALUE(-EINVAL);
- down(&performance_sem);
+ mutex_lock(&performance_mutex);
pr = processors[cpu];
if (!pr) {
- up(&performance_sem);
+ mutex_unlock(&performance_mutex);
return_VALUE(-ENODEV);
}
if (pr->performance) {
- up(&performance_sem);
+ mutex_unlock(&performance_mutex);
return_VALUE(-EBUSY);
}
@@ -802,13 +803,13 @@ acpi_processor_register_performance(stru
if (acpi_processor_get_performance_info(pr)) {
pr->performance = NULL;
- up(&performance_sem);
+ mutex_unlock(&performance_mutex);
return_VALUE(-EIO);
}
acpi_cpufreq_add_file(pr);
- up(&performance_sem);
+ mutex_unlock(&performance_mutex);
return_VALUE(0);
}
@@ -822,11 +823,11 @@ acpi_processor_unregister_performance(st
ACPI_FUNCTION_TRACE("acpi_processor_unregister_performance");
- down(&performance_sem);
+ mutex_lock(&performance_mutex);
pr = processors[cpu];
if (!pr) {
- up(&performance_sem);
+ mutex_unlock(&performance_mutex);
return_VOID;
}
@@ -835,7 +836,7 @@ acpi_processor_unregister_performance(st
acpi_cpufreq_remove_file(pr);
- up(&performance_sem);
+ mutex_unlock(&performance_mutex);
return_VOID;
}
diff -puN drivers/acpi/scan.c~sem2mutex-drivers-acpi drivers/acpi/scan.c
--- devel/drivers/acpi/scan.c~sem2mutex-drivers-acpi 2006-03-21 22:30:03.000000000 -0800
+++ devel-akpm/drivers/acpi/scan.c 2006-03-21 22:30:03.000000000 -0800
@@ -5,6 +5,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/acpi.h>
+#include <linux/mutex.h>
#include <acpi/acpi_drivers.h>
#include <acpi/acinterp.h> /* for acpi_ex_eisa_id_to_string() */
@@ -471,7 +472,7 @@ static int acpi_bus_get_perf_flags(struc
-------------------------------------------------------------------------- */
static LIST_HEAD(acpi_bus_drivers);
-static DECLARE_MUTEX(acpi_bus_drivers_lock);
+static DEFINE_MUTEX(acpi_bus_drivers_lock);
/**
* acpi_bus_match - match device IDs to driver's supported IDs
_
^ permalink raw reply
* [patch 06/23] PNPACPI: whitespace cleanup
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Tidy up whitespace. No functional change.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/pnp/pnpacpi/rsparser.c | 97 +++++++++++++++----------------
1 files changed, 47 insertions(+), 50 deletions(-)
diff -puN drivers/pnp/pnpacpi/rsparser.c~pnpacpi-whitespace-cleanup drivers/pnp/pnpacpi/rsparser.c
--- devel/drivers/pnp/pnpacpi/rsparser.c~pnpacpi-whitespace-cleanup 2006-03-21 22:30:04.000000000 -0800
+++ devel-akpm/drivers/pnp/pnpacpi/rsparser.c 2006-03-21 22:30:04.000000000 -0800
@@ -36,13 +36,13 @@ static int irq_flags(int triggering, int
{
int flag;
if (triggering == ACPI_LEVEL_SENSITIVE) {
- if(polarity == ACPI_ACTIVE_LOW)
+ if (polarity == ACPI_ACTIVE_LOW)
flag = IORESOURCE_IRQ_LOWLEVEL;
else
flag = IORESOURCE_IRQ_HIGHLEVEL;
}
else {
- if(polarity == ACPI_ACTIVE_LOW)
+ if (polarity == ACPI_ACTIVE_LOW)
flag = IORESOURCE_IRQ_LOWEDGE;
else
flag = IORESOURCE_IRQ_HIGHEDGE;
@@ -57,7 +57,7 @@ static void decode_irq_flags(int flag, i
*triggering = ACPI_LEVEL_SENSITIVE;
*polarity = ACPI_ACTIVE_LOW;
break;
- case IORESOURCE_IRQ_HIGHLEVEL:
+ case IORESOURCE_IRQ_HIGHLEVEL:
*triggering = ACPI_LEVEL_SENSITIVE;
*polarity = ACPI_ACTIVE_HIGH;
break;
@@ -73,7 +73,7 @@ static void decode_irq_flags(int flag, i
}
static void
-pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, u32 gsi,
+pnpacpi_parse_allocated_irqresource(struct pnp_resource_table *res, u32 gsi,
int triggering, int polarity)
{
int i = 0;
@@ -101,7 +101,7 @@ pnpacpi_parse_allocated_irqresource(stru
}
static void
-pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, u32 dma)
+pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res, u32 dma)
{
int i = 0;
while (i < PNP_MAX_DMA &&
@@ -119,7 +119,7 @@ pnpacpi_parse_allocated_dmaresource(stru
}
static void
-pnpacpi_parse_allocated_ioresource(struct pnp_resource_table * res,
+pnpacpi_parse_allocated_ioresource(struct pnp_resource_table *res,
u64 io, u64 len)
{
int i = 0;
@@ -138,7 +138,7 @@ pnpacpi_parse_allocated_ioresource(struc
}
static void
-pnpacpi_parse_allocated_memresource(struct pnp_resource_table * res,
+pnpacpi_parse_allocated_memresource(struct pnp_resource_table *res,
u64 mem, u64 len)
{
int i = 0;
@@ -181,7 +181,7 @@ pnpacpi_parse_allocated_address_space(st
static acpi_status pnpacpi_allocated_resource(struct acpi_resource *res,
void *data)
{
- struct pnp_resource_table * res_table = (struct pnp_resource_table *)data;
+ struct pnp_resource_table *res_table = (struct pnp_resource_table *)data;
int i;
switch (res->type) {
@@ -266,11 +266,11 @@ static acpi_status pnpacpi_allocated_res
pnp_warn("PnPACPI: unknown resource type %d", res->type);
return AE_ERROR;
}
-
+
return AE_OK;
}
-acpi_status pnpacpi_parse_allocated_resource(acpi_handle handle, struct pnp_resource_table * res)
+acpi_status pnpacpi_parse_allocated_resource(acpi_handle handle, struct pnp_resource_table *res)
{
/* Blank the resource table values */
pnp_init_resource_table(res);
@@ -328,17 +328,17 @@ static void pnpacpi_parse_dma_option(str
pnp_err("Invalid DMA transfer type");
}
- pnp_register_dma_resource(option,dma);
+ pnp_register_dma_resource(option, dma);
return;
}
-
+
static void pnpacpi_parse_irq_option(struct pnp_option *option,
struct acpi_resource_irq *p)
{
int i;
- struct pnp_irq * irq;
-
+ struct pnp_irq *irq;
+
if (p->interrupt_count == 0)
return;
irq = kcalloc(1, sizeof(struct pnp_irq), GFP_KERNEL);
@@ -358,7 +358,7 @@ static void pnpacpi_parse_ext_irq_option
struct acpi_resource_extended_irq *p)
{
int i;
- struct pnp_irq * irq;
+ struct pnp_irq *irq;
if (p->interrupt_count == 0)
return;
@@ -379,7 +379,7 @@ static void
pnpacpi_parse_port_option(struct pnp_option *option,
struct acpi_resource_io *io)
{
- struct pnp_port * port;
+ struct pnp_port *port;
if (io->address_length == 0)
return;
@@ -392,7 +392,7 @@ pnpacpi_parse_port_option(struct pnp_opt
port->size = io->address_length;
port->flags = ACPI_DECODE_16 == io->io_decode ?
PNP_PORT_FLAG_16BITADDR : 0;
- pnp_register_port_resource(option,port);
+ pnp_register_port_resource(option, port);
return;
}
@@ -400,7 +400,7 @@ static void
pnpacpi_parse_fixed_port_option(struct pnp_option *option,
struct acpi_resource_fixed_io *io)
{
- struct pnp_port * port;
+ struct pnp_port *port;
if (io->address_length == 0)
return;
@@ -411,7 +411,7 @@ pnpacpi_parse_fixed_port_option(struct p
port->size = io->address_length;
port->align = 0;
port->flags = PNP_PORT_FLAG_FIXED;
- pnp_register_port_resource(option,port);
+ pnp_register_port_resource(option, port);
return;
}
@@ -419,7 +419,7 @@ static void
pnpacpi_parse_mem24_option(struct pnp_option *option,
struct acpi_resource_memory24 *p)
{
- struct pnp_mem * mem;
+ struct pnp_mem *mem;
if (p->address_length == 0)
return;
@@ -434,7 +434,7 @@ pnpacpi_parse_mem24_option(struct pnp_op
mem->flags = (ACPI_READ_WRITE_MEMORY == p->write_protect) ?
IORESOURCE_MEM_WRITEABLE : 0;
- pnp_register_mem_resource(option,mem);
+ pnp_register_mem_resource(option, mem);
return;
}
@@ -442,7 +442,7 @@ static void
pnpacpi_parse_mem32_option(struct pnp_option *option,
struct acpi_resource_memory32 *p)
{
- struct pnp_mem * mem;
+ struct pnp_mem *mem;
if (p->address_length == 0)
return;
@@ -457,7 +457,7 @@ pnpacpi_parse_mem32_option(struct pnp_op
mem->flags = (ACPI_READ_WRITE_MEMORY == p->write_protect) ?
IORESOURCE_MEM_WRITEABLE : 0;
- pnp_register_mem_resource(option,mem);
+ pnp_register_mem_resource(option, mem);
return;
}
@@ -465,7 +465,7 @@ static void
pnpacpi_parse_fixed_mem32_option(struct pnp_option *option,
struct acpi_resource_fixed_memory32 *p)
{
- struct pnp_mem * mem;
+ struct pnp_mem *mem;
if (p->address_length == 0)
return;
@@ -479,7 +479,7 @@ pnpacpi_parse_fixed_mem32_option(struct
mem->flags = (ACPI_READ_WRITE_MEMORY == p->write_protect) ?
IORESOURCE_MEM_WRITEABLE : 0;
- pnp_register_mem_resource(option,mem);
+ pnp_register_mem_resource(option, mem);
return;
}
@@ -488,8 +488,8 @@ pnpacpi_parse_address_option(struct pnp_
{
struct acpi_resource_address64 addr, *p = &addr;
acpi_status status;
- struct pnp_mem * mem;
- struct pnp_port * port;
+ struct pnp_mem *mem;
+ struct pnp_port *port;
status = acpi_resource_to_address64(r, p);
if (!ACPI_SUCCESS(status)) {
@@ -509,7 +509,7 @@ pnpacpi_parse_address_option(struct pnp_
mem->align = 0;
mem->flags = (p->info.mem.write_protect ==
ACPI_READ_WRITE_MEMORY) ? IORESOURCE_MEM_WRITEABLE : 0;
- pnp_register_mem_resource(option,mem);
+ pnp_register_mem_resource(option, mem);
} else if (p->resource_type == ACPI_IO_RANGE) {
port = kcalloc(1, sizeof(struct pnp_port), GFP_KERNEL);
if (!port)
@@ -518,7 +518,7 @@ pnpacpi_parse_address_option(struct pnp_
port->size = p->address_length;
port->align = 0;
port->flags = PNP_PORT_FLAG_FIXED;
- pnp_register_port_resource(option,port);
+ pnp_register_port_resource(option, port);
}
}
@@ -542,7 +542,7 @@ static acpi_status pnpacpi_option_resour
break;
case ACPI_RESOURCE_TYPE_DMA:
- pnpacpi_parse_dma_option(option, &res->data.dma);
+ pnpacpi_parse_dma_option(option, &res->data.dma);
break;
case ACPI_RESOURCE_TYPE_START_DEPENDENT:
@@ -550,7 +550,7 @@ static acpi_status pnpacpi_option_resour
case ACPI_GOOD_CONFIGURATION:
priority = PNP_RES_PRIORITY_PREFERRED;
break;
-
+
case ACPI_ACCEPTABLE_CONFIGURATION:
priority = PNP_RES_PRIORITY_ACCEPTABLE;
break;
@@ -566,7 +566,7 @@ static acpi_status pnpacpi_option_resour
option = pnp_register_dependent_option(dev, priority);
if (!option)
return AE_ERROR;
- parse_data->option = option;
+ parse_data->option = option;
break;
case ACPI_RESOURCE_TYPE_END_DEPENDENT:
@@ -626,7 +626,7 @@ static acpi_status pnpacpi_option_resour
pnp_warn("PnPACPI: unknown resource type %d", res->type);
return AE_ERROR;
}
-
+
return AE_OK;
}
@@ -679,10 +679,9 @@ static acpi_status pnpacpi_count_resourc
return AE_OK;
}
-static acpi_status pnpacpi_type_resources(struct acpi_resource *res,
- void *data)
+static acpi_status pnpacpi_type_resources(struct acpi_resource *res, void *data)
{
- struct acpi_resource **resource = (struct acpi_resource **)data;
+ struct acpi_resource **resource = (struct acpi_resource **)data;
if (pnpacpi_supported_resource(res)) {
(*resource)->type = res->type;
@@ -731,9 +730,8 @@ static void pnpacpi_encode_irq(struct ac
struct resource *p)
{
int triggering, polarity;
-
- decode_irq_flags(p->flags & IORESOURCE_BITS, &triggering,
- &polarity);
+
+ decode_irq_flags(p->flags & IORESOURCE_BITS, &triggering, &polarity);
resource->data.irq.triggering = triggering;
resource->data.irq.polarity = polarity;
if (triggering == ACPI_EDGE_SENSITIVE)
@@ -748,9 +746,8 @@ static void pnpacpi_encode_ext_irq(struc
struct resource *p)
{
int triggering, polarity;
-
- decode_irq_flags(p->flags & IORESOURCE_BITS, &triggering,
- &polarity);
+
+ decode_irq_flags(p->flags & IORESOURCE_BITS, &triggering, &polarity);
resource->data.extended_irq.producer_consumer = ACPI_CONSUMER;
resource->data.extended_irq.triggering = triggering;
resource->data.extended_irq.polarity = polarity;
@@ -862,37 +859,37 @@ int pnpacpi_encode_resources(struct pnp_
pnp_dbg("Encode dma");
pnpacpi_encode_dma(resource,
&res_table->dma_resource[dma]);
- dma ++;
+ dma++;
break;
case ACPI_RESOURCE_TYPE_IO:
pnp_dbg("Encode io");
pnpacpi_encode_io(resource,
&res_table->port_resource[port]);
- port ++;
+ port++;
break;
case ACPI_RESOURCE_TYPE_FIXED_IO:
pnp_dbg("Encode fixed io");
pnpacpi_encode_fixed_io(resource,
&res_table->port_resource[port]);
- port ++;
+ port++;
break;
case ACPI_RESOURCE_TYPE_MEMORY24:
pnp_dbg("Encode mem24");
pnpacpi_encode_mem24(resource,
&res_table->mem_resource[mem]);
- mem ++;
+ mem++;
break;
case ACPI_RESOURCE_TYPE_MEMORY32:
pnp_dbg("Encode mem32");
pnpacpi_encode_mem32(resource,
&res_table->mem_resource[mem]);
- mem ++;
+ mem++;
break;
case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
pnp_dbg("Encode fixed mem32");
pnpacpi_encode_fixed_mem32(resource,
&res_table->mem_resource[mem]);
- mem ++;
+ mem++;
break;
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
pnp_dbg("Encode ext irq");
@@ -913,8 +910,8 @@ int pnpacpi_encode_resources(struct pnp_
pnp_warn("unknown resource type %d", resource->type);
return -EINVAL;
}
- resource ++;
- i ++;
+ resource++;
+ i++;
}
return 0;
}
_
^ permalink raw reply
* [patch 05/23] PNPACPI: remove some code duplication
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Factor out the duplicated switch from pnpacpi_count_resources() and
pnpacpi_type_resources(). Remove the unnecessary re-initialization of
resource->type and length from all the encode functions (id and length are
originally set in the pnpacpi_build_resource_template() ->
pnpacpi_type_resources() path).
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/pnp/pnpacpi/rsparser.c | 67 ++++++++-----------------------
1 files changed, 18 insertions(+), 49 deletions(-)
diff -puN drivers/pnp/pnpacpi/rsparser.c~pnpacpi-remove-some-code-duplication drivers/pnp/pnpacpi/rsparser.c
--- devel/drivers/pnp/pnpacpi/rsparser.c~pnpacpi-remove-some-code-duplication 2006-03-21 22:30:04.000000000 -0800
+++ devel-akpm/drivers/pnp/pnpacpi/rsparser.c 2006-03-21 22:30:04.000000000 -0800
@@ -647,13 +647,8 @@ acpi_status pnpacpi_parse_resource_optio
return status;
}
-/*
- * Set resource
- */
-static acpi_status pnpacpi_count_resources(struct acpi_resource *res,
- void *data)
+static int pnpacpi_supported_resource(struct acpi_resource *res)
{
- int *res_cnt = (int *)data;
switch (res->type) {
case ACPI_RESOURCE_TYPE_IRQ:
case ACPI_RESOURCE_TYPE_DMA:
@@ -666,15 +661,21 @@ static acpi_status pnpacpi_count_resourc
case ACPI_RESOURCE_TYPE_ADDRESS32:
case ACPI_RESOURCE_TYPE_ADDRESS64:
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
- (*res_cnt) ++;
- case ACPI_RESOURCE_TYPE_START_DEPENDENT:
- case ACPI_RESOURCE_TYPE_END_DEPENDENT:
- case ACPI_RESOURCE_TYPE_VENDOR:
- case ACPI_RESOURCE_TYPE_END_TAG:
- case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
- default:
- return AE_OK;
+ return 1;
}
+ return 0;
+}
+
+/*
+ * Set resource
+ */
+static acpi_status pnpacpi_count_resources(struct acpi_resource *res,
+ void *data)
+{
+ int *res_cnt = (int *)data;
+
+ if (pnpacpi_supported_resource(res))
+ (*res_cnt)++;
return AE_OK;
}
@@ -682,27 +683,11 @@ static acpi_status pnpacpi_type_resource
void *data)
{
struct acpi_resource **resource = (struct acpi_resource **)data;
- switch (res->type) {
- case ACPI_RESOURCE_TYPE_IRQ:
- case ACPI_RESOURCE_TYPE_DMA:
- case ACPI_RESOURCE_TYPE_IO:
- case ACPI_RESOURCE_TYPE_FIXED_IO:
- case ACPI_RESOURCE_TYPE_MEMORY24:
- case ACPI_RESOURCE_TYPE_MEMORY32:
- case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
- case ACPI_RESOURCE_TYPE_ADDRESS16:
- case ACPI_RESOURCE_TYPE_ADDRESS32:
- case ACPI_RESOURCE_TYPE_ADDRESS64:
- case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+
+ if (pnpacpi_supported_resource(res)) {
(*resource)->type = res->type;
+ (*resource)->length = sizeof(struct acpi_resource);
(*resource)++;
- case ACPI_RESOURCE_TYPE_START_DEPENDENT:
- case ACPI_RESOURCE_TYPE_END_DEPENDENT:
- case ACPI_RESOURCE_TYPE_VENDOR:
- case ACPI_RESOURCE_TYPE_END_TAG:
- case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
- default:
- return AE_OK;
}
return AE_OK;
@@ -749,8 +734,6 @@ static void pnpacpi_encode_irq(struct ac
decode_irq_flags(p->flags & IORESOURCE_BITS, &triggering,
&polarity);
- resource->type = ACPI_RESOURCE_TYPE_IRQ;
- resource->length = sizeof(struct acpi_resource);
resource->data.irq.triggering = triggering;
resource->data.irq.polarity = polarity;
if (triggering == ACPI_EDGE_SENSITIVE)
@@ -768,8 +751,6 @@ static void pnpacpi_encode_ext_irq(struc
decode_irq_flags(p->flags & IORESOURCE_BITS, &triggering,
&polarity);
- resource->type = ACPI_RESOURCE_TYPE_EXTENDED_IRQ;
- resource->length = sizeof(struct acpi_resource);
resource->data.extended_irq.producer_consumer = ACPI_CONSUMER;
resource->data.extended_irq.triggering = triggering;
resource->data.extended_irq.polarity = polarity;
@@ -784,8 +765,6 @@ static void pnpacpi_encode_ext_irq(struc
static void pnpacpi_encode_dma(struct acpi_resource *resource,
struct resource *p)
{
- resource->type = ACPI_RESOURCE_TYPE_DMA;
- resource->length = sizeof(struct acpi_resource);
/* Note: pnp_assign_dma will copy pnp_dma->flags into p->flags */
if (p->flags & IORESOURCE_DMA_COMPATIBLE)
resource->data.dma.type = ACPI_COMPATIBILITY;
@@ -809,8 +788,6 @@ static void pnpacpi_encode_dma(struct ac
static void pnpacpi_encode_io(struct acpi_resource *resource,
struct resource *p)
{
- resource->type = ACPI_RESOURCE_TYPE_IO;
- resource->length = sizeof(struct acpi_resource);
/* Note: pnp_assign_port will copy pnp_port->flags into p->flags */
resource->data.io.io_decode = (p->flags & PNP_PORT_FLAG_16BITADDR)?
ACPI_DECODE_16 : ACPI_DECODE_10;
@@ -823,8 +800,6 @@ static void pnpacpi_encode_io(struct acp
static void pnpacpi_encode_fixed_io(struct acpi_resource *resource,
struct resource *p)
{
- resource->type = ACPI_RESOURCE_TYPE_FIXED_IO;
- resource->length = sizeof(struct acpi_resource);
resource->data.fixed_io.address = p->start;
resource->data.fixed_io.address_length = p->end - p->start + 1;
}
@@ -832,8 +807,6 @@ static void pnpacpi_encode_fixed_io(stru
static void pnpacpi_encode_mem24(struct acpi_resource *resource,
struct resource *p)
{
- resource->type = ACPI_RESOURCE_TYPE_MEMORY24;
- resource->length = sizeof(struct acpi_resource);
/* Note: pnp_assign_mem will copy pnp_mem->flags into p->flags */
resource->data.memory24.write_protect =
(p->flags & IORESOURCE_MEM_WRITEABLE) ?
@@ -847,8 +820,6 @@ static void pnpacpi_encode_mem24(struct
static void pnpacpi_encode_mem32(struct acpi_resource *resource,
struct resource *p)
{
- resource->type = ACPI_RESOURCE_TYPE_MEMORY32;
- resource->length = sizeof(struct acpi_resource);
resource->data.memory32.write_protect =
(p->flags & IORESOURCE_MEM_WRITEABLE) ?
ACPI_READ_WRITE_MEMORY : ACPI_READ_ONLY_MEMORY;
@@ -861,8 +832,6 @@ static void pnpacpi_encode_mem32(struct
static void pnpacpi_encode_fixed_mem32(struct acpi_resource *resource,
struct resource *p)
{
- resource->type = ACPI_RESOURCE_TYPE_FIXED_MEMORY32;
- resource->length = sizeof(struct acpi_resource);
resource->data.fixed_memory32.write_protect =
(p->flags & IORESOURCE_MEM_WRITEABLE) ?
ACPI_READ_WRITE_MEMORY : ACPI_READ_ONLY_MEMORY;
_
^ permalink raw reply
* [patch 04/23] PNPACPI: fix non-memory address space descriptor handling
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, bjorn.helgaas
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Fix resource_type handling for QWORD, DWORD, and WORD Address Space
Descriptors. Previously we ignored the resource_type, so I/O ports and bus
number ranges were incorrectly parsed as memory ranges.
Sample PCI root bridge resources from HP rx2600 before this patch:
# cat /sys/bus/pnp/devices/00:02/resources
state = active
mem 0x0-0x1f
mem 0x0-0x3af
mem 0x3e0-0x1fff
mem 0x80000000-0x8fffffff
With this patch:
# cat /sys/bus/pnp/devices/00:02/resources
state = active
io 0x0-0x3af
io 0x3e0-0x1fff
mem 0x80000000-0x8fffffff
mem 0x80004000000-0x80103fffffe
Changes:
0x0-0x1f PCI bus number range was incorrectly reported as memory, now
not reported at all
0x0-0x3af I/O port range was incorrectly reported as memory
0x3e0-0x1fff I/O port range was incorrectly reported as memory
0x80004000000-0x80103fffffe memory range wasn't reported at all because
we only support PNP_MAX_MEM (4) memory resources
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/pnp/pnpacpi/rsparser.c | 35 ++++++++++++++++++++-----------
1 files changed, 23 insertions(+), 12 deletions(-)
diff -puN drivers/pnp/pnpacpi/rsparser.c~pnpacpi-fix-non-memory-address-space-descriptor-handling drivers/pnp/pnpacpi/rsparser.c
--- devel/drivers/pnp/pnpacpi/rsparser.c~pnpacpi-fix-non-memory-address-space-descriptor-handling 2006-03-21 22:30:04.000000000 -0800
+++ devel-akpm/drivers/pnp/pnpacpi/rsparser.c 2006-03-21 22:30:04.000000000 -0800
@@ -120,7 +120,7 @@ pnpacpi_parse_allocated_dmaresource(stru
static void
pnpacpi_parse_allocated_ioresource(struct pnp_resource_table * res,
- u32 io, u32 len)
+ u64 io, u64 len)
{
int i = 0;
while (!(res->port_resource[i].flags & IORESOURCE_UNSET) &&
@@ -156,6 +156,27 @@ pnpacpi_parse_allocated_memresource(stru
}
}
+static void
+pnpacpi_parse_allocated_address_space(struct pnp_resource_table *res_table,
+ struct acpi_resource *res)
+{
+ struct acpi_resource_address64 addr, *p = &addr;
+ acpi_status status;
+
+ status = acpi_resource_to_address64(res, p);
+ if (!ACPI_SUCCESS(status)) {
+ pnp_warn("PnPACPI: failed to convert resource type %d",
+ res->type);
+ return;
+ }
+
+ if (p->resource_type == ACPI_MEMORY_RANGE)
+ pnpacpi_parse_allocated_memresource(res_table,
+ p->minimum, p->address_length);
+ else if (p->resource_type == ACPI_IO_RANGE)
+ pnpacpi_parse_allocated_ioresource(res_table,
+ p->minimum, p->address_length);
+}
static acpi_status pnpacpi_allocated_resource(struct acpi_resource *res,
void *data)
@@ -221,19 +242,9 @@ static acpi_status pnpacpi_allocated_res
res->data.fixed_memory32.address_length);
break;
case ACPI_RESOURCE_TYPE_ADDRESS16:
- pnpacpi_parse_allocated_memresource(res_table,
- res->data.address16.minimum,
- res->data.address16.address_length);
- break;
case ACPI_RESOURCE_TYPE_ADDRESS32:
- pnpacpi_parse_allocated_memresource(res_table,
- res->data.address32.minimum,
- res->data.address32.address_length);
- break;
case ACPI_RESOURCE_TYPE_ADDRESS64:
- pnpacpi_parse_allocated_memresource(res_table,
- res->data.address64.minimum,
- res->data.address64.address_length);
+ pnpacpi_parse_allocated_address_space(res_table, res);
break;
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
_
^ permalink raw reply
* [patch 03/23] sem2mutex: acpi, acpi_link_lock
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, mingo
From: Ingo Molnar <mingo@elte.hu>
Semaphore to mutex conversion.
The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/pci_link.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff -puN drivers/acpi/pci_link.c~sem2mutex-acpi-acpi_link_lock drivers/acpi/pci_link.c
--- devel/drivers/acpi/pci_link.c~sem2mutex-acpi-acpi_link_lock 2006-03-21 22:30:04.000000000 -0800
+++ devel-akpm/drivers/acpi/pci_link.c 2006-03-21 22:30:04.000000000 -0800
@@ -38,6 +38,7 @@
#include <linux/spinlock.h>
#include <linux/pm.h>
#include <linux/pci.h>
+#include <linux/mutex.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
@@ -91,7 +92,7 @@ static struct {
int count;
struct list_head entries;
} acpi_link;
-DECLARE_MUTEX(acpi_link_lock);
+DEFINE_MUTEX(acpi_link_lock);
/* --------------------------------------------------------------------------
PCI Link Device Management
@@ -634,19 +635,19 @@ acpi_pci_link_allocate_irq(acpi_handle h
return_VALUE(-1);
}
- down(&acpi_link_lock);
+ mutex_lock(&acpi_link_lock);
if (acpi_pci_link_allocate(link)) {
- up(&acpi_link_lock);
+ mutex_unlock(&acpi_link_lock);
return_VALUE(-1);
}
if (!link->irq.active) {
- up(&acpi_link_lock);
+ mutex_unlock(&acpi_link_lock);
ACPI_ERROR((AE_INFO, "Link active IRQ is 0!"));
return_VALUE(-1);
}
link->refcnt++;
- up(&acpi_link_lock);
+ mutex_unlock(&acpi_link_lock);
if (triggering)
*triggering = link->irq.triggering;
@@ -684,9 +685,9 @@ int acpi_pci_link_free_irq(acpi_handle h
return_VALUE(-1);
}
- down(&acpi_link_lock);
+ mutex_lock(&acpi_link_lock);
if (!link->irq.initialized) {
- up(&acpi_link_lock);
+ mutex_unlock(&acpi_link_lock);
ACPI_ERROR((AE_INFO, "Link isn't initialized"));
return_VALUE(-1);
}
@@ -709,7 +710,7 @@ int acpi_pci_link_free_irq(acpi_handle h
if (link->refcnt == 0) {
acpi_ut_evaluate_object(link->handle, "_DIS", 0, NULL);
}
- up(&acpi_link_lock);
+ mutex_unlock(&acpi_link_lock);
return_VALUE(link->irq.active);
}
@@ -740,7 +741,7 @@ static int acpi_pci_link_add(struct acpi
strcpy(acpi_device_class(device), ACPI_PCI_LINK_CLASS);
acpi_driver_data(device) = link;
- down(&acpi_link_lock);
+ mutex_lock(&acpi_link_lock);
result = acpi_pci_link_get_possible(link);
if (result)
goto end;
@@ -775,7 +776,7 @@ static int acpi_pci_link_add(struct acpi
end:
/* disable all links -- to be activated on use */
acpi_ut_evaluate_object(link->handle, "_DIS", 0, NULL);
- up(&acpi_link_lock);
+ mutex_unlock(&acpi_link_lock);
if (result)
kfree(link);
@@ -829,9 +830,9 @@ static int acpi_pci_link_remove(struct a
link = (struct acpi_pci_link *)acpi_driver_data(device);
- down(&acpi_link_lock);
+ mutex_lock(&acpi_link_lock);
list_del(&link->node);
- up(&acpi_link_lock);
+ mutex_unlock(&acpi_link_lock);
kfree(link);
_
^ permalink raw reply
* [patch 01/23] git-acpi: uniprocessor compile fixes
From: akpm @ 2006-03-22 6:30 UTC (permalink / raw)
To: len.brown; +Cc: linux-acpi, akpm, venkatesh.pallipadi
From: Andrew Morton <akpm@osdl.org>,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
cpu_online_map doesn't exist if !CONFIG_SMP.
This path is rather lame and it'd be nice to fix it better.
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c | 4 ++++
arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c | 4 ++++
2 files changed, 8 insertions(+)
diff -puN arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c~git-acpi-up-fix arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
--- devel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c~git-acpi-up-fix 2006-03-21 22:30:03.000000000 -0800
+++ devel-akpm/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-03-21 22:30:03.000000000 -0800
@@ -225,8 +225,12 @@ acpi_cpufreq_target (
freqs.old = data->freq_table[cur_state].frequency;
freqs.new = data->freq_table[next_state].frequency;
+#ifdef CONFIG_HOTPLUG_CPU
/* cpufreq holds the hotplug lock, so we are safe from here on */
cpus_and(online_policy_cpus, cpu_online_map, policy->cpus);
+#else
+ online_policy_cpus = policy->cpus;
+#endif
for_each_cpu_mask(j, online_policy_cpus) {
freqs.cpu = j;
diff -puN arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c~git-acpi-up-fix arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
--- devel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c~git-acpi-up-fix 2006-03-21 22:30:03.000000000 -0800
+++ devel-akpm/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2006-03-21 22:30:03.000000000 -0800
@@ -654,8 +654,12 @@ static int centrino_target (struct cpufr
return -EINVAL;
}
+#ifdef CONFIG_HOTPLUG_CPU
/* cpufreq holds the hotplug lock, so we are safe from here on */
cpus_and(online_policy_cpus, cpu_online_map, policy->cpus);
+#else
+ online_policy_cpus = policy->cpus;
+#endif
saved_mask = current->cpus_allowed;
first_cpu = 1;
_
^ permalink raw reply
* CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: Andrew Morton @ 2006-03-22 6:23 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-acpi
WARNING: "remove_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
WARNING: "add_memory" [drivers/acpi/acpi_memhotplug.ko] undefined!
WARNING: "acpi_os_allocate" [drivers/acpi/acpi_memhotplug.ko] undefined!
Does it actually make sense to load acpi_memhotplug.ko as a module? Will
it all work?
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-22 5:13 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B417DFC@pdsmsx403>
> Please don't give up . :-)
I haven't!
> I need to know which statement in EC0.UPDT that could trigger the
> problem. That is very important to understand the problem
> correctly.
> This is still my assumption that some AML code needed to be avoided
> in suspend/resume, I need data support. So, we need to dig more in
> EC0.UPDT.
You've convinced me!
> If we cannot find out that statement , then, I will dout the testing
> results that guiding us to here.
Yes, the testing is often frustrating and unreliable because the bug
is not 100% reproducible, which is why I think it's more than 1 bug
(one reliable bug, related to THM0, and one or more flakey ones).
>> However, we do have one more piece of data. When it hangs, it hangs in
>> \_SI._SST, because I see that line on successful sleeps (as the last
> I don't know this. I always assume the hang is at _PTS.SMPI
Oh, I think you're right. Robert Moore's comment at the bugzilla
entry agrees with what you say. I was (I don't know why) assuming
that the ACPI system printed "Execute Method ..." after it finished
executing the method. In which case, seeing the PTS but not the SST
made me think that PTS worked but SST failed. However, what you say
is consistent with ACPI printing "Execute Method" as it begins a
method -- in which case seeing the PTS but not the SST means it fails
in PTS (and in PTS.SMPI).
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
http://bugzilla.kernel.org/show_bug.cgi?id=5989
------- Additional Comments From Robert.Moore@intel.com 2006-02-06 14:46
You are stuck in the loop in the method below. I would guess that the
code is
waiting for a response from the SMI bios and it never happens.
Method (SMPI, 1, NotSerialized)
{
Store (S_AX, Local0)
Store (0x81, APMD)
While (LEqual (S_AH, 0xA6))
{
Sleep (0x64)
Store (Local0, S_AX)
Store (0x81, APMD)
}
}
OperationRegion (MNVS, SystemMemory, 0x23FDF000, 0x1000)
Field (MNVS, DWordAcc, NoLock, Preserve)
{
Offset (0xFC0),
S_AX, 16,
OperationRegion (APMC, SystemIO, 0xB2, 0x01)
Field (APMC, ByteAcc, NoLock, Preserve)
{
APMD, 8
Store (Local0, S_AX)
exregion-0182 [29] ex_system_memory_space: system_memory 0 (32 width)
Address=0000000023FDFFC0
Store (0x81, APMD)
exregion-0287 [30] ex_system_io_space_han: system_iO 1 (8 width)
Address=00000000000000B2
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-22 4:58 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>> We can do bisection in EC0.UPDT to find out which statement cause
>> hang?
>
>Yes, though see below for why I don't think it'll help no
>matter what we
>find there.
Please don't give up . :-)
I need to know which statement in EC0.UPDT that could trigger the
problem.
That is very important to understand the problem correctly.
If we cannot find out that statement , then, I will dout the testing
results that guiding us to here.
>
>> My assumption is that since Windows works well, then these BIOS code
>> should have been tested ok. The only possible excuse for BIOS is that
>> Linux is using unnecessary/untested code path for
>Suspend/resume. So,
>> Eventually, we need to disable unnecessary BIOS call for
>> suspend/resume
>
>Maybe we're not collecting the right data in that case. We know that
>commenting out the call to UPDT in THM0.TMP fixes the hang.
>But it does
>not follow that the osl suspend code should avoid running UPDT.
This is still my assumption that some AML code needed to be avoided
in suspend/resume, I need data support. So, we need to dig more in
EC0.UPDT.
>
>The hang may work like this: Between boot and sleep, calling
>UPDT messes
>up something in the ec [which is why it takes >1 sleep to
>cause a hang].
>When the system tries to sleep, that something triggers and the ec
>hangs. But it may hang somewhere else than UPDT, and avoiding UPDT
>during sleep will not fix it.
If BIOS behaviors NOT correctly , then everything can happen.
>
>However, we do have one more piece of data. When it hangs, it hangs in
>\_SI._SST, because I see that line on successful sleeps (as the last
I don't know this. I always assume the hang is at _PTS.SMPI
>method before the beep) but not when it hangs (and then I also don't
>hear a beep). There are lots of calls to EC0.XXX, including to
>EC0.BEEP, within _SST, which isn't surprising if the EC is the problem.
It could be. But there should have something that trigger it.
>So perhaps I should bisect in _SST and put in the debug lines there?
>
>Here's another idea, which is a terrible hack. But there are lots of
>lines in the DSDT like
> If (LOr (SPS, WNTF))
>which I imagine is saying "If something or if WinNT". So,
>what if Linux
>pretends to be WinNT (or W98F -- which is another common
>test), at least
>for the 600x? Maybe those code paths are known to work.
>
Yes, you can try that.
Thanks,
Luming
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-22 4:35 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B417B9D@pdsmsx403>
> We can do bisection in EC0.UPDT to find out which statement cause
> hang?
Yes, though see below for why I don't think it'll help no matter what we
find there.
> My assumption is that since Windows works well, then these BIOS code
> should have been tested ok. The only possible excuse for BIOS is that
> Linux is using unnecessary/untested code path for Suspend/resume. So,
> Eventually, we need to disable unnecessary BIOS call for
> suspend/resume
Maybe we're not collecting the right data in that case. We know that
commenting out the call to UPDT in THM0.TMP fixes the hang. But it does
not follow that the osl suspend code should avoid running UPDT.
The hang may work like this: Between boot and sleep, calling UPDT messes
up something in the ec [which is why it takes >1 sleep to cause a hang].
When the system tries to sleep, that something triggers and the ec
hangs. But it may hang somewhere else than UPDT, and avoiding UPDT
during sleep will not fix it.
However, we do have one more piece of data. When it hangs, it hangs in
\_SI._SST, because I see that line on successful sleeps (as the last
method before the beep) but not when it hangs (and then I also don't
hear a beep). There are lots of calls to EC0.XXX, including to
EC0.BEEP, within _SST, which isn't surprising if the EC is the problem.
So perhaps I should bisect in _SST and put in the debug lines there?
Here's another idea, which is a terrible hack. But there are lots of
lines in the DSDT like
If (LOr (SPS, WNTF))
which I imagine is saying "If something or if WinNT". So, what if Linux
pretends to be WinNT (or W98F -- which is another common test), at least
for the 600x? Maybe those code paths are known to work.
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-22 1:34 UTC (permalink / raw)
To: Yu, Luming, Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>
>Hmm, you seems to prefer depth-first search algorithm?
>I like it too. :-)
>
>
>>
>>One bug is quite repeatable and we know a lot about it. With all zones
>>except THM0 commented out, the system hung. With the EC0.UPDT line in
>>THM0._TMP also commented out, the system didn't hang. So there's a
>>problem related to the EC, even with only THM0. And finding that
>>problem may giveideas for what else may be wrong.
>
>We can do bisection in EC0.UPDT to find out which statement cause hang?
>Hmm, we are going to fix BIOS. :-)
You can insert debug statements in EC0.UPDT to help debug:
Store (IGNR, Debug)
Store (" before relase I2CM", Debug)
Store (HBS7, TMP7)
....
>
>My assumption is that since Windows works well, then these BIOS code
>should have been tested ok. The only possible excuse for BIOS is that
>Linux is using unnecessary/untested code path for Suspend/resume.
>So, Eventually, we need to disable unnecessary BIOS call for
>suspend/resume
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-22 1:30 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>Two more experiments:
>
> With a vanilla kernel, I faked EC0.UPDT() to just return
>0x00, and the
> system hung on the second sleep.
>
> Then, again in the DSDT, I also faked the 4 _TMP methods (one in each
> thermal zone), and the system hung on the second sleep.
>
>I think we've raced too far ahead by trying to debug many thermal zones
>at once. Perhaps there are two bugs. So let's find them one by one.
Hmm, you seems to prefer depth-first search algorithm?
I like it too. :-)
>
>One bug is quite repeatable and we know a lot about it. With all zones
>except THM0 commented out, the system hung. With the EC0.UPDT line in
>THM0._TMP also commented out, the system didn't hang. So there's a
>problem related to the EC, even with only THM0. And finding that
>problem may giveideas for what else may be wrong.
We can do bisection in EC0.UPDT to find out which statement cause hang?
Hmm, we are going to fix BIOS. :-)
My assumption is that since Windows works well, then these BIOS code
should have been tested ok. The only possible excuse for BIOS is that
Linux is using unnecessary/untested code path for Suspend/resume.
So, Eventually, we need to disable unnecessary BIOS call for
suspend/resume
Thanks,
Luming
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-21 22:09 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B417863@pdsmsx403>
Two more experiments:
With a vanilla kernel, I faked EC0.UPDT() to just return 0x00, and the
system hung on the second sleep.
Then, again in the DSDT, I also faked the 4 _TMP methods (one in each
thermal zone), and the system hung on the second sleep.
I think we've raced too far ahead by trying to debug many thermal zones
at once. Perhaps there are two bugs. So let's find them one by one.
One bug is quite repeatable and we know a lot about it. With all zones
except THM0 commented out, the system hung. With the EC0.UPDT line in
THM0._TMP also commented out, the system didn't hang. So there's a
problem related to the EC, even with only THM0. And finding that
problem may giveideas for what else may be wrong.
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-21 20:37 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B417863@pdsmsx403>
The following tests all have acpi_evaluate_integer() hacked to return
_TMP=27C.
>> The kernel panic for the don't-load-THM2 kernel is very strange. I
>> had another kernel panic while doing another set of tests, which I
>> also couldn't explain. The only difference between the no-THM0 and
>> the no-THM2 kernels is:
> Could you just printk device->pnp? it could be null point (due to you
> hack?)
device->pnp is a struct and I couldn't figure out how to printk it, so
I just printk'ed device->pnp.bus_id (most of its other elements aren't
initialized by then anyway):
diff -r ac486e270597 -r 8b088512dd1d drivers/acpi/thermal.c
--- a/drivers/acpi/thermal.c Sat Mar 18 08:35:34 2006 -0500
+++ b/drivers/acpi/thermal.c Tue Mar 21 11:32:31 2006 -0500
@@ -1324,6 +1324,7 @@ static int acpi_thermal_add(struct acpi_
if (!device)
return_VALUE(-EINVAL);
+ printk(KERN_INFO PREFIX "pnp.bus_id=0x%x\n", (u32) device->pnp.bus_id);
tz = kmalloc(sizeof(struct acpi_thermal), GFP_KERNEL);
if (!tz)
It produced nothing surprising:
ACPI: pnp.bus_id=0xe3ed7830
ACPI: pnp.bus_id=0xe3ed7430
ACPI: pnp.bus_id=0xe3ed7030
ACPI: pnp.bus_id=0xe3ed8c30
ACPI: pnp.bus_id=0xe3ed4030
for THM0,2,6,7, and _TZ.
So I still don't know why getting rid of THM2 in the kernel causes the
panic.
But while I had this kernel booted, I tried a few sleep cycles, and it
hung on the second one as expected (it's just the vanilla kernel&DSDT
with acpi_evaluate_integer() hacked to return _TMP=27C).
>> THM6 Hangs (4th cycle)
> Is it still hang at SMPI?
It looked like the usual hang, but I had debug_{layer,level}=0x10. I
increased debug_layer to 0xFFFFFFFF it to see the function traces.
However, the hang didn't occur even after 15 cycles. So I rebooted with
debug_layer=0x10 and still couldn't reproduce the hang even after 12
cycles. But the same kernel hung yesterday after 4 cycles [I save all
the kernels tagged by their revision hash], so I don't know what to
think about THM6.
>> THM2 "kernel panic! attempted to kill init"
> I guess, if you fake DSDT by completely removing THM2 you won't see
> this.
Right, it booted fine when I removed THM2 from the DSDT instead of from
the kernel.
>> So THM6 seems healthy, but THM0 and THM7 (and maybe THM2) interact
>> badly. If I unload THM2, THM6, and THM7, then it's okay (previous
>> experiments with faking _TMP but with only THM0 loaded). But
>> unloading THM6 is not enough.
> Please try to remove THM2 judge if it is JUST the problem of THM0 &&
> THM7.
I tried the kernel with THM2 taken out of the DSDT, and it was fine (so
the total change was that plus _TMP faked in acpi_evaluate_integer()).
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
^ permalink raw reply
* Re: Resume problems on Fujitsu-Siemens AMILO M7440G -- SATA
From: martin schneebacher @ 2006-03-21 16:25 UTC (permalink / raw)
To: Michael Schierl, Mark Lord; +Cc: Shaohua Li, linux-acpi, linux-ide
hi!
> ----- Original Message -----
> From: "Michael Schierl" <schierlm@gmx.de>
> To: "Mark Lord" <liml@rtr.ca>
> Subject: Re: Resume problems on Fujitsu-Siemens AMILO M7440G -- SATA
> Date: Tue, 21 Mar 2006 16:37:03 +0100
> > Randy Dunlop's libata-acpi patch might work for you.
> > http://www.xenotime.net/linux/SATA/
>
> I tried the 2.6.16-rc4 patches on 2.6.16 (one hunk did not apply in
> libata.h, but I think I was able to fix it manually). Before suspend it
> works well, after suspend it does not work. Seems that the timeout is
> longer with the patch, though. I tried it several times; once it seemed
> to have worked, but it was not reproducible (and it did not work any
> longer after the next suspend), so I guess it could be just that I only
> tried files already in cache. (Or alternatively, the patch has a success
> rate of maybe 5%...)
>
> "Just for fun" i tried the 2.6.15 patches on 2.6.15, but it did not even
> boot.
>
> BTW: It is an Intel AHCI controller.
>
> Any other ideas/patches?
have you ever tried the sata_pm patch from http://tpctl.sourceforge.net/tmp/sata_pm.2.6.15-rc6.patch ?
i have a intel SATA ICH6M interface and it works fine with this patch.
bye...masc.
--
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com
Powered by Outblaze
^ permalink raw reply
* Re: Resume problems on Fujitsu-Siemens AMILO M7440G -- SATA
From: Michael Schierl @ 2006-03-21 15:37 UTC (permalink / raw)
To: Mark Lord; +Cc: Shaohua Li, linux-acpi, linux-ide
In-Reply-To: <441F04D6.4070404@rtr.ca>
Mark Lord wrote:
>> I copy all stuff need into tmpfs to ensure that it can restore the video
>> without hard disk access.
>
> OOhh.. clever, wish I'd thought of that,
One should not forget to disable swap first :)
> as all of my (now solved) suspend/resume issues
> were *all* libata related.
So I guess it is a good idea to get SATA working first, isn't it?
>> What to do, what to test?
>
> Randy Dunlop's libata-acpi patch might work for you.
> http://www.xenotime.net/linux/SATA/
I tried the 2.6.16-rc4 patches on 2.6.16 (one hunk did not apply in
libata.h, but I think I was able to fix it manually). Before suspend it
works well, after suspend it does not work. Seems that the timeout is
longer with the patch, though. I tried it several times; once it seemed
to have worked, but it was not reproducible (and it did not work any
longer after the next suspend), so I guess it could be just that I only
tried files already in cache. (Or alternatively, the patch has a success
rate of maybe 5%...)
"Just for fun" i tried the 2.6.15 patches on 2.6.15, but it did not even
boot.
BTW: It is an Intel AHCI controller.
Any other ideas/patches?
Michael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox