* [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
@ 2004-08-04 1:42 ` Nathan Bryant
0 siblings, 0 replies; 22+ messages in thread
From: Nathan Bryant @ 2004-08-04 1:42 UTC (permalink / raw)
To: len.brown-ral2JQCrhuEAvxtiuMwx3w
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Linux Kernel list,
Li, Shaohua, Stefan Dösinger
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
This patch should fix multiple user-visible problems with the ACPI IRQ
routing after S3 resume:
"irq x: nobody cared"
"my interrupts are gone"
It probably applies to multiple bugzilla entries and mailing list posts.
Tested on my machine, which is experiencing similar problems. Seems to
work - although I get some non-fatal "nobody cared" messages that might
be caused by the i8042 driver.
Comments?
Stefan, can you test this?
[-- Attachment #2: acpi-fixes.patch --]
[-- Type: text/x-patch, Size: 4840 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/08/03 19:37:56-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# drivers/acpi/pci_link.c: use device_initcall(irqrouter_init_sysfs);
#
# drivers/acpi/pci_link.c
# 2004/08/03 19:37:47-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +13 -3
# use device_initcall(irqrouter_init_sysfs);
#
# ChangeSet
# 2004/08/03 18:09:20-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:09:12-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +1 -1
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# ChangeSet
# 2004/08/03 18:03:39-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:03:31-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +51 -14
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# ChangeSet
# 2004/08/02 20:41:54-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/02 20:41:45-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +23 -0
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# BitKeeper/etc/ignore
# 2004/08/02 20:41:45-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +2 -0
# Added Module.symvers drivers/acpi/pci_link.c~ to the ignore list
#
diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2004-08-03 19:41:29 -04:00
+++ b/drivers/acpi/pci_link.c 2004-08-03 19:41:29 -04:00
@@ -29,6 +29,7 @@
* for IRQ management (e.g. start()->_SRS).
*/
+#include <linux/sysdev.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -84,6 +85,8 @@
struct acpi_pci_link_irq irq;
};
+static int acpi_pci_link_resume (struct acpi_pci_link *link);
+
static struct {
int count;
struct list_head entries;
@@ -695,6 +698,42 @@
static int
+acpi_pci_link_resume (
+ struct acpi_pci_link *link)
+{
+ ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
+
+ if (link->irq.active && link->irq.setonboot)
+ return_VALUE(acpi_pci_link_set(link, link->irq.active));
+ else
+ return_VALUE(0);
+}
+
+
+static int
+irqrouter_resume(
+ struct sys_device *dev)
+{
+ struct list_head *node = NULL;
+ struct acpi_pci_link *link = NULL;
+
+ ACPI_FUNCTION_TRACE("irqrouter_resume");
+
+ list_for_each(node, &acpi_link.entries) {
+
+ link = list_entry(node, struct acpi_pci_link, node);
+ if (!link) {
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
+ continue;
+ }
+
+ acpi_pci_link_resume(link);
+ }
+ return_VALUE(0);
+}
+
+
+static int
acpi_pci_link_remove (
struct acpi_device *device,
int type)
@@ -786,11 +825,42 @@
__setup("acpi_irq_balance", acpi_irq_balance_set);
+static struct sysdev_class irqrouter_sysdev_class = {
+ set_kset_name("irqrouter"),
+ .resume = irqrouter_resume,
+};
+
+
+static struct sys_device device_irqrouter = {
+ .id = 0,
+ .cls = &irqrouter_sysdev_class,
+};
+
+
+static int __init irqrouter_init_sysfs(void)
+{
+ int error;
+
+ ACPI_FUNCTION_TRACE("irqrouter_init_sysfs");
+
+ if (acpi_disabled || acpi_noirq)
+ return_VALUE(0);
+
+ error = sysdev_class_register(&irqrouter_sysdev_class);
+ if (!error)
+ error = sysdev_register(&device_irqrouter);
+
+ return_VALUE(error);
+}
+
+device_initcall(irqrouter_init_sysfs);
+
+
static int __init acpi_pci_link_init (void)
{
ACPI_FUNCTION_TRACE("acpi_pci_link_init");
- if (acpi_pci_disabled)
+ if (acpi_disabled || acpi_noirq)
return_VALUE(0);
acpi_link.count = 0;
@@ -798,7 +868,7 @@
if (acpi_bus_register_driver(&acpi_pci_link_driver) < 0)
return_VALUE(-ENODEV);
-
+
return_VALUE(0);
}
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
@ 2004-08-04 1:42 ` Nathan Bryant
0 siblings, 0 replies; 22+ messages in thread
From: Nathan Bryant @ 2004-08-04 1:42 UTC (permalink / raw)
To: len.brown
Cc: acpi-devel, Linux Kernel list, Li, Shaohua, Stefan Dösinger
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
This patch should fix multiple user-visible problems with the ACPI IRQ
routing after S3 resume:
"irq x: nobody cared"
"my interrupts are gone"
It probably applies to multiple bugzilla entries and mailing list posts.
Tested on my machine, which is experiencing similar problems. Seems to
work - although I get some non-fatal "nobody cared" messages that might
be caused by the i8042 driver.
Comments?
Stefan, can you test this?
[-- Attachment #2: acpi-fixes.patch --]
[-- Type: text/x-patch, Size: 4606 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/08/03 19:37:56-04:00 nbryant@optonline.net
# drivers/acpi/pci_link.c: use device_initcall(irqrouter_init_sysfs);
#
# drivers/acpi/pci_link.c
# 2004/08/03 19:37:47-04:00 nbryant@optonline.net +13 -3
# use device_initcall(irqrouter_init_sysfs);
#
# ChangeSet
# 2004/08/03 18:09:20-04:00 nbryant@optonline.net
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:09:12-04:00 nbryant@optonline.net +1 -1
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# ChangeSet
# 2004/08/03 18:03:39-04:00 nbryant@optonline.net
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:03:31-04:00 nbryant@optonline.net +51 -14
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# ChangeSet
# 2004/08/02 20:41:54-04:00 nbryant@optonline.net
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/02 20:41:45-04:00 nbryant@optonline.net +23 -0
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# BitKeeper/etc/ignore
# 2004/08/02 20:41:45-04:00 nbryant@optonline.net +2 -0
# Added Module.symvers drivers/acpi/pci_link.c~ to the ignore list
#
diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2004-08-03 19:41:29 -04:00
+++ b/drivers/acpi/pci_link.c 2004-08-03 19:41:29 -04:00
@@ -29,6 +29,7 @@
* for IRQ management (e.g. start()->_SRS).
*/
+#include <linux/sysdev.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -84,6 +85,8 @@
struct acpi_pci_link_irq irq;
};
+static int acpi_pci_link_resume (struct acpi_pci_link *link);
+
static struct {
int count;
struct list_head entries;
@@ -695,6 +698,42 @@
static int
+acpi_pci_link_resume (
+ struct acpi_pci_link *link)
+{
+ ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
+
+ if (link->irq.active && link->irq.setonboot)
+ return_VALUE(acpi_pci_link_set(link, link->irq.active));
+ else
+ return_VALUE(0);
+}
+
+
+static int
+irqrouter_resume(
+ struct sys_device *dev)
+{
+ struct list_head *node = NULL;
+ struct acpi_pci_link *link = NULL;
+
+ ACPI_FUNCTION_TRACE("irqrouter_resume");
+
+ list_for_each(node, &acpi_link.entries) {
+
+ link = list_entry(node, struct acpi_pci_link, node);
+ if (!link) {
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
+ continue;
+ }
+
+ acpi_pci_link_resume(link);
+ }
+ return_VALUE(0);
+}
+
+
+static int
acpi_pci_link_remove (
struct acpi_device *device,
int type)
@@ -786,11 +825,42 @@
__setup("acpi_irq_balance", acpi_irq_balance_set);
+static struct sysdev_class irqrouter_sysdev_class = {
+ set_kset_name("irqrouter"),
+ .resume = irqrouter_resume,
+};
+
+
+static struct sys_device device_irqrouter = {
+ .id = 0,
+ .cls = &irqrouter_sysdev_class,
+};
+
+
+static int __init irqrouter_init_sysfs(void)
+{
+ int error;
+
+ ACPI_FUNCTION_TRACE("irqrouter_init_sysfs");
+
+ if (acpi_disabled || acpi_noirq)
+ return_VALUE(0);
+
+ error = sysdev_class_register(&irqrouter_sysdev_class);
+ if (!error)
+ error = sysdev_register(&device_irqrouter);
+
+ return_VALUE(error);
+}
+
+device_initcall(irqrouter_init_sysfs);
+
+
static int __init acpi_pci_link_init (void)
{
ACPI_FUNCTION_TRACE("acpi_pci_link_init");
- if (acpi_pci_disabled)
+ if (acpi_disabled || acpi_noirq)
return_VALUE(0);
acpi_link.count = 0;
@@ -798,7 +868,7 @@
if (acpi_bus_register_driver(&acpi_pci_link_driver) < 0)
return_VALUE(-ENODEV);
-
+
return_VALUE(0);
}
^ permalink raw reply [flat|nested] 22+ messages in thread[parent not found: <41103F22.4090303-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>]
* Re: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
2004-08-04 1:42 ` Nathan Bryant
@ 2004-08-04 2:59 ` Len Brown
-1 siblings, 0 replies; 22+ messages in thread
From: Len Brown @ 2004-08-04 2:59 UTC (permalink / raw)
To: Nathan Bryant
Cc: ACPI Developers, Linux Kernel list, Shaohua Li,
Stefan Dösinger
Well done Nathan!
On Tue, 2004-08-03 at 21:42, Nathan Bryant wrote:
> This patch should fix multiple user-visible problems with the ACPI IRQ
> routing after S3 resume:
>
> "irq x: nobody cared"
> "my interrupts are gone"
I was under the (apparently false) impression that devices would
call eg. pci_enable_device() upon .resume, which would bubble down
to pcibios_enable_irq()/acpi_pci_irq_enable() which would handle this.
But not all do this this, and
for those that do, the link->irq.setonboot test in
acpi_pci_link_allocate would prevent the hardware from being
reprogrammed anyway -- so I guess I hadn't thought this path through.
And so I think we do need this patch for chipsets that clear
the IRQ routers upon suspend. Indeed, it is likely that
we'd have this problem in S4 in addition to S3, yes?
> diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> --- a/drivers/acpi/pci_link.c 2004-08-03 19:41:29 -04:00
> +++ b/drivers/acpi/pci_link.c 2004-08-03 19:41:29 -04:00
> @@ -29,6 +29,7 @@
> * for IRQ management (e.g. start()->_SRS).
> */
>
> +#include <linux/sysdev.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> @@ -84,6 +85,8 @@
> struct acpi_pci_link_irq irq;
> };
>
> +static int acpi_pci_link_resume (struct acpi_pci_link *link);
> +
This declaration isn't necessary b/c the definition (below)
is above where the function is first used, yes?
> static struct {
> int count;
> struct list_head entries;
> @@ -695,6 +698,42 @@
>
>
> static int
> +acpi_pci_link_resume (
> + struct acpi_pci_link *link)
> +{
> + ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
> +
> + if (link->irq.active && link->irq.setonboot)
I think that before this change, irq.setonboot was a NOP
and a candidate for being deleted. However, it does seem
to have a use here, where we want to re-program only those
links that were programmed. ("setonboot" would probably
be better called "initialized" or "programmed").
Since irq.active is set for all links from probe time
whether or not we program them, it isn't sufficient,
as we've found from experience that it is a bad idea
to program links that are not explicitly requested
by actual devices -- so I agree we need setonboot here.
> + return_VALUE(acpi_pci_link_set(link, link->irq.active));
> + else
> + return_VALUE(0);
> +}
> +
> +
> +static int
> +irqrouter_resume(
> + struct sys_device *dev)
> +{
> + struct list_head *node = NULL;
> + struct acpi_pci_link *link = NULL;
> +
> + ACPI_FUNCTION_TRACE("irqrouter_resume");
> +
> + list_for_each(node, &acpi_link.entries) {
> +
> + link = list_entry(node, struct acpi_pci_link, node);
> + if (!link) {
> + ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
> + continue;
> + }
> +
> + acpi_pci_link_resume(link);
> + }
> + return_VALUE(0);
> +}
> +
> +
> +static int
> acpi_pci_link_remove (
> struct acpi_device *device,
> int type)
> @@ -786,11 +825,42 @@
> __setup("acpi_irq_balance", acpi_irq_balance_set);
>
>
> +static struct sysdev_class irqrouter_sysdev_class = {
> + set_kset_name("irqrouter"),
> + .resume = irqrouter_resume,
> +};
> +
> +
> +static struct sys_device device_irqrouter = {
> + .id = 0,
> + .cls = &irqrouter_sysdev_class,
> +};
> +
> +
> +static int __init irqrouter_init_sysfs(void)
> +{
> + int error;
> +
> + ACPI_FUNCTION_TRACE("irqrouter_init_sysfs");
> +
> + if (acpi_disabled || acpi_noirq)
> + return_VALUE(0);
> +
> + error = sysdev_class_register(&irqrouter_sysdev_class);
> + if (!error)
> + error = sysdev_register(&device_irqrouter);
> +
> + return_VALUE(error);
> +}
> +
> +device_initcall(irqrouter_init_sysfs);
> +
> +
> static int __init acpi_pci_link_init (void)
> {
> ACPI_FUNCTION_TRACE("acpi_pci_link_init");
>
> - if (acpi_pci_disabled)
> + if (acpi_disabled || acpi_noirq)
I think that testing acpi_noirq is sufficient here.
> return_VALUE(0);
>
> acpi_link.count = 0;
> @@ -798,7 +868,7 @@
>
> if (acpi_bus_register_driver(&acpi_pci_link_driver) < 0)
> return_VALUE(-ENODEV);
> -
> +
> return_VALUE(0);
> }
>
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
@ 2004-08-04 2:59 ` Len Brown
0 siblings, 0 replies; 22+ messages in thread
From: Len Brown @ 2004-08-04 2:59 UTC (permalink / raw)
To: Nathan Bryant
Cc: ACPI Developers, Linux Kernel list, Shaohua Li,
Stefan Dösinger
Well done Nathan!
On Tue, 2004-08-03 at 21:42, Nathan Bryant wrote:
> This patch should fix multiple user-visible problems with the ACPI IRQ
> routing after S3 resume:
>
> "irq x: nobody cared"
> "my interrupts are gone"
I was under the (apparently false) impression that devices would
call eg. pci_enable_device() upon .resume, which would bubble down
to pcibios_enable_irq()/acpi_pci_irq_enable() which would handle this.
But not all do this this, and
for those that do, the link->irq.setonboot test in
acpi_pci_link_allocate would prevent the hardware from being
reprogrammed anyway -- so I guess I hadn't thought this path through.
And so I think we do need this patch for chipsets that clear
the IRQ routers upon suspend. Indeed, it is likely that
we'd have this problem in S4 in addition to S3, yes?
> diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> --- a/drivers/acpi/pci_link.c 2004-08-03 19:41:29 -04:00
> +++ b/drivers/acpi/pci_link.c 2004-08-03 19:41:29 -04:00
> @@ -29,6 +29,7 @@
> * for IRQ management (e.g. start()->_SRS).
> */
>
> +#include <linux/sysdev.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> @@ -84,6 +85,8 @@
> struct acpi_pci_link_irq irq;
> };
>
> +static int acpi_pci_link_resume (struct acpi_pci_link *link);
> +
This declaration isn't necessary b/c the definition (below)
is above where the function is first used, yes?
> static struct {
> int count;
> struct list_head entries;
> @@ -695,6 +698,42 @@
>
>
> static int
> +acpi_pci_link_resume (
> + struct acpi_pci_link *link)
> +{
> + ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
> +
> + if (link->irq.active && link->irq.setonboot)
I think that before this change, irq.setonboot was a NOP
and a candidate for being deleted. However, it does seem
to have a use here, where we want to re-program only those
links that were programmed. ("setonboot" would probably
be better called "initialized" or "programmed").
Since irq.active is set for all links from probe time
whether or not we program them, it isn't sufficient,
as we've found from experience that it is a bad idea
to program links that are not explicitly requested
by actual devices -- so I agree we need setonboot here.
> + return_VALUE(acpi_pci_link_set(link, link->irq.active));
> + else
> + return_VALUE(0);
> +}
> +
> +
> +static int
> +irqrouter_resume(
> + struct sys_device *dev)
> +{
> + struct list_head *node = NULL;
> + struct acpi_pci_link *link = NULL;
> +
> + ACPI_FUNCTION_TRACE("irqrouter_resume");
> +
> + list_for_each(node, &acpi_link.entries) {
> +
> + link = list_entry(node, struct acpi_pci_link, node);
> + if (!link) {
> + ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
> + continue;
> + }
> +
> + acpi_pci_link_resume(link);
> + }
> + return_VALUE(0);
> +}
> +
> +
> +static int
> acpi_pci_link_remove (
> struct acpi_device *device,
> int type)
> @@ -786,11 +825,42 @@
> __setup("acpi_irq_balance", acpi_irq_balance_set);
>
>
> +static struct sysdev_class irqrouter_sysdev_class = {
> + set_kset_name("irqrouter"),
> + .resume = irqrouter_resume,
> +};
> +
> +
> +static struct sys_device device_irqrouter = {
> + .id = 0,
> + .cls = &irqrouter_sysdev_class,
> +};
> +
> +
> +static int __init irqrouter_init_sysfs(void)
> +{
> + int error;
> +
> + ACPI_FUNCTION_TRACE("irqrouter_init_sysfs");
> +
> + if (acpi_disabled || acpi_noirq)
> + return_VALUE(0);
> +
> + error = sysdev_class_register(&irqrouter_sysdev_class);
> + if (!error)
> + error = sysdev_register(&device_irqrouter);
> +
> + return_VALUE(error);
> +}
> +
> +device_initcall(irqrouter_init_sysfs);
> +
> +
> static int __init acpi_pci_link_init (void)
> {
> ACPI_FUNCTION_TRACE("acpi_pci_link_init");
>
> - if (acpi_pci_disabled)
> + if (acpi_disabled || acpi_noirq)
I think that testing acpi_noirq is sufficient here.
> return_VALUE(0);
>
> acpi_link.count = 0;
> @@ -798,7 +868,7 @@
>
> if (acpi_bus_register_driver(&acpi_pci_link_driver) < 0)
> return_VALUE(-ENODEV);
> -
> +
> return_VALUE(0);
> }
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
2004-08-04 2:59 ` Len Brown
@ 2004-08-04 15:57 ` Nathan Bryant
-1 siblings, 0 replies; 22+ messages in thread
From: Nathan Bryant @ 2004-08-04 15:57 UTC (permalink / raw)
To: Len Brown
Cc: ACPI Developers, Linux Kernel list, Shaohua Li,
Stefan Dösinger
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
Len-
Attached is a respin based on your comments.
Len Brown wrote:
>> static int
>>+acpi_pci_link_resume (
>>+ struct acpi_pci_link *link)
>>+{
>>+ ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
>>+
>>+ if (link->irq.active && link->irq.setonboot)
>>
>>
>
>I think that before this change, irq.setonboot was a NOP
>and a candidate for being deleted. However, it does seem
>to have a use here, where we want to re-program only those
>links that were programmed. ("setonboot" would probably
>be better called "initialized" or "programmed").
>
>
Agree, changed to "initialized"
>> static int __init acpi_pci_link_init (void)
>> {
>> ACPI_FUNCTION_TRACE("acpi_pci_link_init");
>>
>>- if (acpi_pci_disabled)
>>+ if (acpi_disabled || acpi_noirq)
>>
>>
>
>I think that testing acpi_noirq is sufficient here.
>
>
I'll take your word for it. changed.
[-- Attachment #2: acpi-fixes.patch2 --]
[-- Type: text/plain, Size: 5742 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/08/04 11:32:42-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# [ACPI] drivers/acpi/pci_link.c: misc cleanups per suggestions
#
# drivers/acpi/pci_link.c
# 2004/08/04 11:32:33-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +6 -8
# [ACPI] drivers/acpi/pci_link.c: misc cleanups per suggestions
#
# ChangeSet
# 2004/08/04 10:53:42-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# Merge optonline.net:/home/nathan/linux-acpi-test-2.6.8
# into optonline.net:/home/nathan/acpi-fixes
#
# BitKeeper/etc/ignore
# 2004/08/04 10:53:30-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +1 -2
# auto-union
#
# ChangeSet
# 2004/08/03 19:37:56-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# drivers/acpi/pci_link.c: use device_initcall(irqrouter_init_sysfs);
#
# drivers/acpi/pci_link.c
# 2004/08/03 19:37:47-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +13 -3
# use device_initcall(irqrouter_init_sysfs);
#
# ChangeSet
# 2004/08/03 18:09:20-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:09:12-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +1 -1
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# ChangeSet
# 2004/08/03 18:03:39-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:03:31-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +51 -14
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# ChangeSet
# 2004/08/02 20:41:54-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/02 20:41:45-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +23 -0
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# BitKeeper/etc/ignore
# 2004/08/02 20:41:45-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +2 -0
# Added Module.symvers drivers/acpi/pci_link.c~ to the ignore list
#
diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2004-08-04 11:33:50 -04:00
+++ b/drivers/acpi/pci_link.c 2004-08-04 11:33:50 -04:00
@@ -29,6 +29,7 @@
* for IRQ management (e.g. start()->_SRS).
*/
+#include <linux/sysdev.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -71,7 +72,7 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 setonboot;
+ u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
@@ -517,7 +518,7 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
- if (link->irq.setonboot)
+ if (link->irq.initialized)
return_VALUE(0);
/*
@@ -571,7 +572,7 @@
acpi_device_bid(link->device), link->irq.active);
}
- link->irq.setonboot = 1;
+ link->irq.initialized = 1;
return_VALUE(0);
}
@@ -695,6 +696,42 @@
static int
+acpi_pci_link_resume (
+ struct acpi_pci_link *link)
+{
+ ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
+
+ if (link->irq.active && link->irq.initialized)
+ return_VALUE(acpi_pci_link_set(link, link->irq.active));
+ else
+ return_VALUE(0);
+}
+
+
+static int
+irqrouter_resume(
+ struct sys_device *dev)
+{
+ struct list_head *node = NULL;
+ struct acpi_pci_link *link = NULL;
+
+ ACPI_FUNCTION_TRACE("irqrouter_resume");
+
+ list_for_each(node, &acpi_link.entries) {
+
+ link = list_entry(node, struct acpi_pci_link, node);
+ if (!link) {
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
+ continue;
+ }
+
+ acpi_pci_link_resume(link);
+ }
+ return_VALUE(0);
+}
+
+
+static int
acpi_pci_link_remove (
struct acpi_device *device,
int type)
@@ -786,11 +823,42 @@
__setup("acpi_irq_balance", acpi_irq_balance_set);
+static struct sysdev_class irqrouter_sysdev_class = {
+ set_kset_name("irqrouter"),
+ .resume = irqrouter_resume,
+};
+
+
+static struct sys_device device_irqrouter = {
+ .id = 0,
+ .cls = &irqrouter_sysdev_class,
+};
+
+
+static int __init irqrouter_init_sysfs(void)
+{
+ int error;
+
+ ACPI_FUNCTION_TRACE("irqrouter_init_sysfs");
+
+ if (acpi_disabled || acpi_noirq)
+ return_VALUE(0);
+
+ error = sysdev_class_register(&irqrouter_sysdev_class);
+ if (!error)
+ error = sysdev_register(&device_irqrouter);
+
+ return_VALUE(error);
+}
+
+device_initcall(irqrouter_init_sysfs);
+
+
static int __init acpi_pci_link_init (void)
{
ACPI_FUNCTION_TRACE("acpi_pci_link_init");
- if (acpi_pci_disabled)
+ if (acpi_noirq)
return_VALUE(0);
acpi_link.count = 0;
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
@ 2004-08-04 15:57 ` Nathan Bryant
0 siblings, 0 replies; 22+ messages in thread
From: Nathan Bryant @ 2004-08-04 15:57 UTC (permalink / raw)
To: Len Brown
Cc: ACPI Developers, Linux Kernel list, Shaohua Li,
Stefan Dösinger
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
Len-
Attached is a respin based on your comments.
Len Brown wrote:
>> static int
>>+acpi_pci_link_resume (
>>+ struct acpi_pci_link *link)
>>+{
>>+ ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
>>+
>>+ if (link->irq.active && link->irq.setonboot)
>>
>>
>
>I think that before this change, irq.setonboot was a NOP
>and a candidate for being deleted. However, it does seem
>to have a use here, where we want to re-program only those
>links that were programmed. ("setonboot" would probably
>be better called "initialized" or "programmed").
>
>
Agree, changed to "initialized"
>> static int __init acpi_pci_link_init (void)
>> {
>> ACPI_FUNCTION_TRACE("acpi_pci_link_init");
>>
>>- if (acpi_pci_disabled)
>>+ if (acpi_disabled || acpi_noirq)
>>
>>
>
>I think that testing acpi_noirq is sufficient here.
>
>
I'll take your word for it. changed.
[-- Attachment #2: acpi-fixes.patch2 --]
[-- Type: text/plain, Size: 5404 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/08/04 11:32:42-04:00 nbryant@optonline.net
# [ACPI] drivers/acpi/pci_link.c: misc cleanups per suggestions
#
# drivers/acpi/pci_link.c
# 2004/08/04 11:32:33-04:00 nbryant@optonline.net +6 -8
# [ACPI] drivers/acpi/pci_link.c: misc cleanups per suggestions
#
# ChangeSet
# 2004/08/04 10:53:42-04:00 nbryant@optonline.net
# Merge optonline.net:/home/nathan/linux-acpi-test-2.6.8
# into optonline.net:/home/nathan/acpi-fixes
#
# BitKeeper/etc/ignore
# 2004/08/04 10:53:30-04:00 nbryant@optonline.net +1 -2
# auto-union
#
# ChangeSet
# 2004/08/03 19:37:56-04:00 nbryant@optonline.net
# drivers/acpi/pci_link.c: use device_initcall(irqrouter_init_sysfs);
#
# drivers/acpi/pci_link.c
# 2004/08/03 19:37:47-04:00 nbryant@optonline.net +13 -3
# use device_initcall(irqrouter_init_sysfs);
#
# ChangeSet
# 2004/08/03 18:09:20-04:00 nbryant@optonline.net
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:09:12-04:00 nbryant@optonline.net +1 -1
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# ChangeSet
# 2004/08/03 18:03:39-04:00 nbryant@optonline.net
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:03:31-04:00 nbryant@optonline.net +51 -14
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# ChangeSet
# 2004/08/02 20:41:54-04:00 nbryant@optonline.net
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/02 20:41:45-04:00 nbryant@optonline.net +23 -0
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# BitKeeper/etc/ignore
# 2004/08/02 20:41:45-04:00 nbryant@optonline.net +2 -0
# Added Module.symvers drivers/acpi/pci_link.c~ to the ignore list
#
diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2004-08-04 11:33:50 -04:00
+++ b/drivers/acpi/pci_link.c 2004-08-04 11:33:50 -04:00
@@ -29,6 +29,7 @@
* for IRQ management (e.g. start()->_SRS).
*/
+#include <linux/sysdev.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -71,7 +72,7 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 setonboot;
+ u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
@@ -517,7 +518,7 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
- if (link->irq.setonboot)
+ if (link->irq.initialized)
return_VALUE(0);
/*
@@ -571,7 +572,7 @@
acpi_device_bid(link->device), link->irq.active);
}
- link->irq.setonboot = 1;
+ link->irq.initialized = 1;
return_VALUE(0);
}
@@ -695,6 +696,42 @@
static int
+acpi_pci_link_resume (
+ struct acpi_pci_link *link)
+{
+ ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
+
+ if (link->irq.active && link->irq.initialized)
+ return_VALUE(acpi_pci_link_set(link, link->irq.active));
+ else
+ return_VALUE(0);
+}
+
+
+static int
+irqrouter_resume(
+ struct sys_device *dev)
+{
+ struct list_head *node = NULL;
+ struct acpi_pci_link *link = NULL;
+
+ ACPI_FUNCTION_TRACE("irqrouter_resume");
+
+ list_for_each(node, &acpi_link.entries) {
+
+ link = list_entry(node, struct acpi_pci_link, node);
+ if (!link) {
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
+ continue;
+ }
+
+ acpi_pci_link_resume(link);
+ }
+ return_VALUE(0);
+}
+
+
+static int
acpi_pci_link_remove (
struct acpi_device *device,
int type)
@@ -786,11 +823,42 @@
__setup("acpi_irq_balance", acpi_irq_balance_set);
+static struct sysdev_class irqrouter_sysdev_class = {
+ set_kset_name("irqrouter"),
+ .resume = irqrouter_resume,
+};
+
+
+static struct sys_device device_irqrouter = {
+ .id = 0,
+ .cls = &irqrouter_sysdev_class,
+};
+
+
+static int __init irqrouter_init_sysfs(void)
+{
+ int error;
+
+ ACPI_FUNCTION_TRACE("irqrouter_init_sysfs");
+
+ if (acpi_disabled || acpi_noirq)
+ return_VALUE(0);
+
+ error = sysdev_class_register(&irqrouter_sysdev_class);
+ if (!error)
+ error = sysdev_register(&device_irqrouter);
+
+ return_VALUE(error);
+}
+
+device_initcall(irqrouter_init_sysfs);
+
+
static int __init acpi_pci_link_init (void)
{
ACPI_FUNCTION_TRACE("acpi_pci_link_init");
- if (acpi_pci_disabled)
+ if (acpi_noirq)
return_VALUE(0);
acpi_link.count = 0;
^ permalink raw reply [flat|nested] 22+ messages in thread[parent not found: <41110785.4040000-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>]
* Re: Re: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
2004-08-04 15:57 ` Nathan Bryant
@ 2004-08-04 16:10 ` Nathan Bryant
-1 siblings, 0 replies; 22+ messages in thread
From: Nathan Bryant @ 2004-08-04 16:10 UTC (permalink / raw)
To: Len Brown
Cc: ACPI Developers, Linux Kernel list, Shaohua Li,
Stefan Dösinger
[-- Attachment #1: Type: text/plain, Size: 128 bytes --]
Nathan Bryant wrote:
>
> Len-
>
> Attached is a respin based on your comments.
One more respin, this just cleans whitespace.
[-- Attachment #2: acpi-fixes.patch2 --]
[-- Type: text/plain, Size: 6037 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/08/04 12:05:55-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# [ACPI] drivers/acpi/pci_link.c: consistify whitespace
#
# drivers/acpi/pci_link.c
# 2004/08/04 12:05:47-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +4 -4
# [ACPI] drivers/acpi/pci_link.c: consistify whitespace
#
# ChangeSet
# 2004/08/04 11:32:42-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# [ACPI] drivers/acpi/pci_link.c: misc cleanups per suggestions
#
# drivers/acpi/pci_link.c
# 2004/08/04 11:32:33-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +6 -8
# [ACPI] drivers/acpi/pci_link.c: misc cleanups per suggestions
#
# ChangeSet
# 2004/08/04 10:53:42-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# Merge optonline.net:/home/nathan/linux-acpi-test-2.6.8
# into optonline.net:/home/nathan/acpi-fixes
#
# BitKeeper/etc/ignore
# 2004/08/04 10:53:30-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +1 -2
# auto-union
#
# ChangeSet
# 2004/08/03 19:37:56-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# drivers/acpi/pci_link.c: use device_initcall(irqrouter_init_sysfs);
#
# drivers/acpi/pci_link.c
# 2004/08/03 19:37:47-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +13 -3
# use device_initcall(irqrouter_init_sysfs);
#
# ChangeSet
# 2004/08/03 18:09:20-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:09:12-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +1 -1
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# ChangeSet
# 2004/08/03 18:03:39-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:03:31-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +51 -14
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# ChangeSet
# 2004/08/02 20:41:54-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/02 20:41:45-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +23 -0
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# BitKeeper/etc/ignore
# 2004/08/02 20:41:45-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +2 -0
# Added Module.symvers drivers/acpi/pci_link.c~ to the ignore list
#
diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2004-08-04 12:06:33 -04:00
+++ b/drivers/acpi/pci_link.c 2004-08-04 12:06:33 -04:00
@@ -29,6 +29,7 @@
* for IRQ management (e.g. start()->_SRS).
*/
+#include <linux/sysdev.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -71,7 +72,7 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 setonboot;
+ u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
@@ -517,7 +518,7 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
- if (link->irq.setonboot)
+ if (link->irq.initialized)
return_VALUE(0);
/*
@@ -571,7 +572,7 @@
acpi_device_bid(link->device), link->irq.active);
}
- link->irq.setonboot = 1;
+ link->irq.initialized = 1;
return_VALUE(0);
}
@@ -695,6 +696,42 @@
static int
+acpi_pci_link_resume (
+ struct acpi_pci_link *link)
+{
+ ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
+
+ if (link->irq.active && link->irq.initialized)
+ return_VALUE(acpi_pci_link_set(link, link->irq.active));
+ else
+ return_VALUE(0);
+}
+
+
+static int
+irqrouter_resume(
+ struct sys_device *dev)
+{
+ struct list_head *node = NULL;
+ struct acpi_pci_link *link = NULL;
+
+ ACPI_FUNCTION_TRACE("irqrouter_resume");
+
+ list_for_each(node, &acpi_link.entries) {
+
+ link = list_entry(node, struct acpi_pci_link, node);
+ if (!link) {
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
+ continue;
+ }
+
+ acpi_pci_link_resume(link);
+ }
+ return_VALUE(0);
+}
+
+
+static int
acpi_pci_link_remove (
struct acpi_device *device,
int type)
@@ -786,11 +823,42 @@
__setup("acpi_irq_balance", acpi_irq_balance_set);
+static struct sysdev_class irqrouter_sysdev_class = {
+ set_kset_name("irqrouter"),
+ .resume = irqrouter_resume,
+};
+
+
+static struct sys_device device_irqrouter = {
+ .id = 0,
+ .cls = &irqrouter_sysdev_class,
+};
+
+
+static int __init irqrouter_init_sysfs(void)
+{
+ int error;
+
+ ACPI_FUNCTION_TRACE("irqrouter_init_sysfs");
+
+ if (acpi_disabled || acpi_noirq)
+ return_VALUE(0);
+
+ error = sysdev_class_register(&irqrouter_sysdev_class);
+ if (!error)
+ error = sysdev_register(&device_irqrouter);
+
+ return_VALUE(error);
+}
+
+device_initcall(irqrouter_init_sysfs);
+
+
static int __init acpi_pci_link_init (void)
{
ACPI_FUNCTION_TRACE("acpi_pci_link_init");
- if (acpi_pci_disabled)
+ if (acpi_noirq)
return_VALUE(0);
acpi_link.count = 0;
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [ACPI] Re: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
@ 2004-08-04 16:10 ` Nathan Bryant
0 siblings, 0 replies; 22+ messages in thread
From: Nathan Bryant @ 2004-08-04 16:10 UTC (permalink / raw)
To: Len Brown
Cc: ACPI Developers, Linux Kernel list, Shaohua Li,
Stefan Dösinger
[-- Attachment #1: Type: text/plain, Size: 128 bytes --]
Nathan Bryant wrote:
>
> Len-
>
> Attached is a respin based on your comments.
One more respin, this just cleans whitespace.
[-- Attachment #2: acpi-fixes.patch2 --]
[-- Type: text/plain, Size: 5647 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/08/04 12:05:55-04:00 nbryant@optonline.net
# [ACPI] drivers/acpi/pci_link.c: consistify whitespace
#
# drivers/acpi/pci_link.c
# 2004/08/04 12:05:47-04:00 nbryant@optonline.net +4 -4
# [ACPI] drivers/acpi/pci_link.c: consistify whitespace
#
# ChangeSet
# 2004/08/04 11:32:42-04:00 nbryant@optonline.net
# [ACPI] drivers/acpi/pci_link.c: misc cleanups per suggestions
#
# drivers/acpi/pci_link.c
# 2004/08/04 11:32:33-04:00 nbryant@optonline.net +6 -8
# [ACPI] drivers/acpi/pci_link.c: misc cleanups per suggestions
#
# ChangeSet
# 2004/08/04 10:53:42-04:00 nbryant@optonline.net
# Merge optonline.net:/home/nathan/linux-acpi-test-2.6.8
# into optonline.net:/home/nathan/acpi-fixes
#
# BitKeeper/etc/ignore
# 2004/08/04 10:53:30-04:00 nbryant@optonline.net +1 -2
# auto-union
#
# ChangeSet
# 2004/08/03 19:37:56-04:00 nbryant@optonline.net
# drivers/acpi/pci_link.c: use device_initcall(irqrouter_init_sysfs);
#
# drivers/acpi/pci_link.c
# 2004/08/03 19:37:47-04:00 nbryant@optonline.net +13 -3
# use device_initcall(irqrouter_init_sysfs);
#
# ChangeSet
# 2004/08/03 18:09:20-04:00 nbryant@optonline.net
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:09:12-04:00 nbryant@optonline.net +1 -1
# fix ACPI_FUNCTION_TRACE("irqrouter_resume");
#
# ChangeSet
# 2004/08/03 18:03:39-04:00 nbryant@optonline.net
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/03 18:03:31-04:00 nbryant@optonline.net +51 -14
# drivers/acpi/pci_link.c: register us as a sys_device so that we can get
# resume callbacks and restore interrupt state. Fixes interrupt problems
# reported on the mailing lists:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# ChangeSet
# 2004/08/02 20:41:54-04:00 nbryant@optonline.net
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# drivers/acpi/pci_link.c
# 2004/08/02 20:41:45-04:00 nbryant@optonline.net +23 -0
# [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
# called when resuming from a suspend state that needs IRQ routing to be
# restored. This fixes issues reported on the mailing lists, e.g.:
#
# http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
#
# BitKeeper/etc/ignore
# 2004/08/02 20:41:45-04:00 nbryant@optonline.net +2 -0
# Added Module.symvers drivers/acpi/pci_link.c~ to the ignore list
#
diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2004-08-04 12:06:33 -04:00
+++ b/drivers/acpi/pci_link.c 2004-08-04 12:06:33 -04:00
@@ -29,6 +29,7 @@
* for IRQ management (e.g. start()->_SRS).
*/
+#include <linux/sysdev.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -71,7 +72,7 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 setonboot;
+ u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
@@ -517,7 +518,7 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
- if (link->irq.setonboot)
+ if (link->irq.initialized)
return_VALUE(0);
/*
@@ -571,7 +572,7 @@
acpi_device_bid(link->device), link->irq.active);
}
- link->irq.setonboot = 1;
+ link->irq.initialized = 1;
return_VALUE(0);
}
@@ -695,6 +696,42 @@
static int
+acpi_pci_link_resume (
+ struct acpi_pci_link *link)
+{
+ ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
+
+ if (link->irq.active && link->irq.initialized)
+ return_VALUE(acpi_pci_link_set(link, link->irq.active));
+ else
+ return_VALUE(0);
+}
+
+
+static int
+irqrouter_resume(
+ struct sys_device *dev)
+{
+ struct list_head *node = NULL;
+ struct acpi_pci_link *link = NULL;
+
+ ACPI_FUNCTION_TRACE("irqrouter_resume");
+
+ list_for_each(node, &acpi_link.entries) {
+
+ link = list_entry(node, struct acpi_pci_link, node);
+ if (!link) {
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
+ continue;
+ }
+
+ acpi_pci_link_resume(link);
+ }
+ return_VALUE(0);
+}
+
+
+static int
acpi_pci_link_remove (
struct acpi_device *device,
int type)
@@ -786,11 +823,42 @@
__setup("acpi_irq_balance", acpi_irq_balance_set);
+static struct sysdev_class irqrouter_sysdev_class = {
+ set_kset_name("irqrouter"),
+ .resume = irqrouter_resume,
+};
+
+
+static struct sys_device device_irqrouter = {
+ .id = 0,
+ .cls = &irqrouter_sysdev_class,
+};
+
+
+static int __init irqrouter_init_sysfs(void)
+{
+ int error;
+
+ ACPI_FUNCTION_TRACE("irqrouter_init_sysfs");
+
+ if (acpi_disabled || acpi_noirq)
+ return_VALUE(0);
+
+ error = sysdev_class_register(&irqrouter_sysdev_class);
+ if (!error)
+ error = sysdev_register(&device_irqrouter);
+
+ return_VALUE(error);
+}
+
+device_initcall(irqrouter_init_sysfs);
+
+
static int __init acpi_pci_link_init (void)
{
ACPI_FUNCTION_TRACE("acpi_pci_link_init");
- if (acpi_pci_disabled)
+ if (acpi_noirq)
return_VALUE(0);
acpi_link.count = 0;
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
2004-08-04 1:42 ` Nathan Bryant
(?)
(?)
@ 2004-08-19 20:24 ` Stefan Dösinger
[not found] ` <200408192224.08271.stefandoesinger-RbZlAiThDcE@public.gmane.org>
-1 siblings, 1 reply; 22+ messages in thread
From: Stefan Dösinger @ 2004-08-19 20:24 UTC (permalink / raw)
To: acpi-devel; +Cc: len.brown, Linux Kernel list, Li, Shaohua
> This patch should fix multiple user-visible problems with the ACPI IRQ
> routing after S3 resume:
>
> "irq x: nobody cared"
> "my interrupts are gone"
>
> It probably applies to multiple bugzilla entries and mailing list posts.
>
> Tested on my machine, which is experiencing similar problems. Seems to
> work - although I get some non-fatal "nobody cared" messages that might
> be caused by the i8042 driver.
>
> Comments?
> Stefan, can you test this?
Sorry for the very late reply.
I tested with 2.6.8.1(I think your patch it included there) with strange
results.
*It works fine if I unload ipw2100 before suspend and load it later
*In single user mode with ipw2100 loaded while S3, IRQ 11 is disabled on
resume, IRQ is not disabled
*When the system is fully booted up, everything seems to work fine.
I'll test a little bit more and report the results.
Cheers,
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
@ 2004-08-20 19:00 Pallipadi, Venkatesh
2004-08-20 19:42 ` Nathan Bryant
0 siblings, 1 reply; 22+ messages in thread
From: Pallipadi, Venkatesh @ 2004-08-20 19:00 UTC (permalink / raw)
To: stefandoesinger, Nathan Bryant
Cc: acpi-devel, Brown, Len, Linux Kernel list, Li, Shaohua
>-----Original Message-----
>From: acpi-devel-admin@lists.sourceforge.net
>[mailto:acpi-devel-admin@lists.sourceforge.net] On Behalf Of
>Stefan Dösinger
>Sent: Friday, August 20, 2004 9:36 AM
>To: Nathan Bryant
>Cc: acpi-devel@lists.sourceforge.net; Brown, Len; Linux Kernel
>list; Li, Shaohua
>Subject: Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
>
>Am Freitag, 20. August 2004 14:18 schrieb Nathan Bryant:
>> Stefan -
>>
>> Also - did suspend/resume for the ipw2100 ever work under any kernel
>> version?
>Yes, it works with acpi=noirq at least up to 2.6.7(not tested
>with later
>versions, but I'm sure it does)
>It works with 2.6.8-rc2 and 2.6.8-rc4 and 2.6.8.1 with acpi IRQs and a
>modified dsdt which forces LNKE to IRQ 10. I attached a dmesg
>output of a
>successful resume.
>
>Cheers,
>Stefan
This seems to be the same resume order issue, that Shaohua is hitting.
On my system the resume order looks like this:
Resuming System Devices
Resuming type 'cpu':
cpu0
aux driver resume 0xc010e410 (mtrr_restore)
aux driver resume 0xc03365f0 (cpufreq_resume)
Resuming type 'i8259':
i82590
Resuming type 'timer':
timer0
Resuming type 'pit':
pit0
Resuming type 'lapic':
lapic0
Resuming type 'irqrouter':
irqrouter0
Resuming type 'i8042':
i80420
The current theory I have for this issue is we resume pci_link driver
A bit too late, which is causing this problem.
Say a particular device doesn't do anything for suspend and resume.
So, as soon as we resume this particular device can start
generating interrupts. Once we have PIC enabled, it starts sending
interrupts and no one handles that original IRQ. As pci_link that
resumes later is reprogramming the device to different IRQ, where the
driver is handling the device.
That's probably the reason why it works with acpi=noirq or
modified DSDT. Does it make sense?
I think we have to resume pci_link device before PIC.
We should be able to achieve this my changing the makefile orders.
Thanks,
Venki
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
2004-08-20 19:00 Pallipadi, Venkatesh
@ 2004-08-20 19:42 ` Nathan Bryant
2004-08-20 20:01 ` Stefan Dösinger
2004-08-20 20:17 ` Stefan Dösinger
0 siblings, 2 replies; 22+ messages in thread
From: Nathan Bryant @ 2004-08-20 19:42 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: stefandoesinger, acpi-devel, Brown, Len, Linux Kernel list,
Li, Shaohua
Pallipadi, Venkatesh wrote:
> The current theory I have for this issue is we resume pci_link driver
> A bit too late, which is causing this problem.
>
> Say a particular device doesn't do anything for suspend and resume.
> So, as soon as we resume this particular device can start
> generating interrupts. Once we have PIC enabled, it starts sending
> interrupts and no one handles that original IRQ. As pci_link that
> resumes later is reprogramming the device to different IRQ, where the
> driver is handling the device.
>
> That's probably the reason why it works with acpi=noirq or
> modified DSDT. Does it make sense?
Yes. Sometimes acpi=noirq is gentler than ACPI irq mode, because the
ACPI bios may not report the current active IRQ (which was assiged by
the BIOS during boot) as a "possible" IRQ, even though the south bridge
really supports just about any routing.
The result is that the kernel changes the routing when drivers are
initialized during boot, and the kernel chooses one of the IRQ's from
the possible list. However, during resume from S3, the BIOS will put the
routing back the way it was at boot and the kernel has to change the
routing again.
acpi=noirq mode doesn't change the hardware's current routing settings
if an IRQ is already enabled, so there is less opportunity for things to
get out of sync with what the device drivers are expecting.
Something else to watch out for on ICH2 and similar chipsets is that, as
long as the IRQ router is steering a PCI link onto a certain IRQ, LPC
ISA device are blocked from triggering that IRQ via the SERIRQ protocol.
But if we move the all the PCI links elsewhere, the SERIRQ is no longer
blocked, and if some ISA LPC device is holding a high level, which
normally wouldn't trigger IRQ's under ISA, then the IRQ line will get
disabled because the PIC is probably set to level-trigger because it was
PCI at one point. I've seen this happen with IRQ 12 when the BIOS
decided there was no PS/2 mouse present so it could re-use the IRQ. The
real cause is that the i850 has a register that allows IRQ1 and IRQ12
to be disabled on the LPC bus, and this register isn't restored on
resume. This probably doesn't apply to IRQ11 on Stefan's system, though...
>
> I think we have to resume pci_link device before PIC.
That's probably a good idea. If your theory is correct, then waiting
until the PCI device drivers call pci_enable_device() may be too late,
and we might have to do this early in boot. Ideally it wouldn't be a
problem, because device drivers would all disable their devices on
suspend, but there are driverless devices to worry about, and maybe also
badly-behaved hardware that doesn't shut up?
Maybe it's time to look at the suspend/resume callbacks on the ipw2100
driver, anyway.
Nathan
> We should be able to achieve this my changing the makefile orders.
>
> Thanks,
> Venki
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
2004-08-20 19:42 ` Nathan Bryant
@ 2004-08-20 20:01 ` Stefan Dösinger
2004-08-20 20:42 ` Nathan Bryant
2004-08-20 20:17 ` Stefan Dösinger
1 sibling, 1 reply; 22+ messages in thread
From: Stefan Dösinger @ 2004-08-20 20:01 UTC (permalink / raw)
To: acpi-devel
Cc: Pallipadi, Venkatesh, Brown, Len, Linux Kernel list, Li, Shaohua,
Nathan Bryant
> Something else to watch out for on ICH2 and similar chipsets is that, as
> long as the IRQ router is steering a PCI link onto a certain IRQ, LPC
> ISA device are blocked from triggering that IRQ via the SERIRQ protocol.
> But if we move the all the PCI links elsewhere, the SERIRQ is no longer
> blocked, and if some ISA LPC device is holding a high level, which
> normally wouldn't trigger IRQ's under ISA, then the IRQ line will get
> disabled because the PIC is probably set to level-trigger because it was
> PCI at one point. I've seen this happen with IRQ 12 when the BIOS
> decided there was no PS/2 mouse present so it could re-use the IRQ. The
> real cause is that the i850 has a register that allows IRQ1 and IRQ12
> to be disabled on the LPC bus, and this register isn't restored on
> resume. This probably doesn't apply to IRQ11 on Stefan's system, though...
If I re-programm the IRQ to something else than IRQ10, the device doesn't
resume too. So it's not only a problem of IRQ 11.
> Maybe it's time to look at the suspend/resume callbacks on the ipw2100
> driver, anyway.
The ipw2100 driver calls pci_disable_device in it's suspend handler. But I
think the ipw2100 maintainers need help with suspend/resume because James
Ketrenos can't test it on his own system.
I'll change another devices IRQ line to test if it's only an ipw2100 issue.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
2004-08-20 20:01 ` Stefan Dösinger
@ 2004-08-20 20:42 ` Nathan Bryant
2004-08-20 20:43 ` Nathan Bryant
0 siblings, 1 reply; 22+ messages in thread
From: Nathan Bryant @ 2004-08-20 20:42 UTC (permalink / raw)
To: stefandoesinger
Cc: acpi-devel, Pallipadi, Venkatesh, Brown, Len, Linux Kernel list,
Li, Shaohua
Stefan Dösinger wrote:
>If I re-programm the IRQ to something else than IRQ10, the device doesn't
>resume too. So it's not only a problem of IRQ 11.
>
>
Seems like an anything-at-all-other-than-IRQ-10 problem. If the current
thinking is right, your BIOS is assigning IRQ10 during boot, so moving
it anywhere else is what causes problems.
But the current thinking doesn't quite seem right, because it seeems
like we're seeing these problems after the irqrouter is resumed. Can you
verify that with the attached patch? The patch should give us enough
information as long as you've got the proper kernel loglevel set.
Now, I wonder if the only reason it works when you set IRQ 10 is that
some other driver is unconditionally claiming the interrupt...
Nathan
>The ipw2100 driver calls pci_disable_device in it's suspend handler. But I
>think the ipw2100 maintainers need help with suspend/resume because James
>Ketrenos can't test it on his own system.
>
>
pci_disable_device() only turns off bus-mastering, it doesn't unmap the
I/O or disable the slot. Maybe we also need to set power state D3 and do
a device-specific disable-interrupts, but I think D0 gets restored for
us pretty early during resume anyway...
Anyway, something doesn't quite add up...
Nathan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
2004-08-20 20:42 ` Nathan Bryant
@ 2004-08-20 20:43 ` Nathan Bryant
0 siblings, 0 replies; 22+ messages in thread
From: Nathan Bryant @ 2004-08-20 20:43 UTC (permalink / raw)
To: Nathan Bryant
Cc: stefandoesinger, acpi-devel, Pallipadi, Venkatesh, Brown, Len,
Linux Kernel list, Li, Shaohua
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
Oops. Forgot the patch again. See attached.
Nathan Bryant wrote:
> Stefan Dösinger wrote:
>
>> If I re-programm the IRQ to something else than IRQ10, the device
>> doesn't resume too. So it's not only a problem of IRQ 11.
>>
>>
> Seems like an anything-at-all-other-than-IRQ-10 problem. If the
> current thinking is right, your BIOS is assigning IRQ10 during boot,
> so moving it anywhere else is what causes problems.
>
> But the current thinking doesn't quite seem right, because it seeems
> like we're seeing these problems after the irqrouter is resumed. Can
> you verify that with the attached patch? The patch should give us
> enough information as long as you've got the proper kernel loglevel set.
>
> Now, I wonder if the only reason it works when you set IRQ 10 is that
> some other driver is unconditionally claiming the interrupt...
>
> Nathan
>
>> The ipw2100 driver calls pci_disable_device in it's suspend handler.
>> But I think the ipw2100 maintainers need help with suspend/resume
>> because James Ketrenos can't test it on his own system.
>>
>>
> pci_disable_device() only turns off bus-mastering, it doesn't unmap
> the I/O or disable the slot. Maybe we also need to set power state D3
> and do a device-specific disable-interrupts, but I think D0 gets
> restored for us pretty early during resume anyway...
>
> Anyway, something doesn't quite add up...
>
> Nathan
>
[-- Attachment #2: pci_linkdebug.patch --]
[-- Type: text/x-patch, Size: 396 bytes --]
===== drivers/acpi/pci_link.c 1.32 vs edited =====
--- 1.32/drivers/acpi/pci_link.c 2004-08-18 19:26:48 -04:00
+++ edited/drivers/acpi/pci_link.c 2004-08-20 16:28:40 -04:00
@@ -717,6 +717,8 @@
ACPI_FUNCTION_TRACE("irqrouter_resume");
+ printk(KERN_DEBUG "irqrouter_resume: called.\n");
+
list_for_each(node, &acpi_link.entries) {
link = list_entry(node, struct acpi_pci_link, node);
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
2004-08-20 19:42 ` Nathan Bryant
2004-08-20 20:01 ` Stefan Dösinger
@ 2004-08-20 20:17 ` Stefan Dösinger
1 sibling, 0 replies; 22+ messages in thread
From: Stefan Dösinger @ 2004-08-20 20:17 UTC (permalink / raw)
To: acpi-devel
Cc: Nathan Bryant, Pallipadi, Venkatesh, Brown, Len,
Linux Kernel list, Li, Shaohua
> Maybe it's time to look at the suspend/resume callbacks on the ipw2100
> driver, anyway.
I changed LNKD to irq 7. This hit the b44 ethernet and broke S3 resume. Looks
like it's not an ipw2100 problem.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
@ 2004-08-23 5:58 ` Li, Shaohua
0 siblings, 0 replies; 22+ messages in thread
From: Li, Shaohua @ 2004-08-23 5:58 UTC (permalink / raw)
To: Pallipadi, Venkatesh, stefandoesinger, Nathan Bryant
Cc: Brown, Len, acpi-devel, Linux Kernel Mailing List
Right, this looks like the problem I encounter. My current test shows that the problem only occurs if ACPI changed LINK devices' IRQ. If ACPI use default LINK device IRQ, the problem went off.
Currently there are two workarounds:
1. comment one line in pci_link.c:acpi_pci_link_allocate, like below
/*
* forget active IRQ that is not in possible list
*/
if (i == link->irq.possible_count) {
if (acpi_strict)
printk(KERN_WARNING PREFIX "_CRS %d not found"
" in _PRS\n", link->irq.active);
+// link->irq.active = 0;
}
This disables rebalance IRQ, which fixes my problem.
2. change 'device_initcall(i8259A_init_sysfs);' to 'late_initcall(i8259A_init_sysfs);'
It seems that if OS changed BIOS IRQ router setting (like ACPI change Link device setting), IRQ router should resume before PIC. This possibly proves what Venki said.
PS. For the resume order, isn't it strange Local APIC resumes after PIT? I guess it should be the first device to resume.
Thanks,
Shaohua
>-----Original Message-----
>From: Pallipadi, Venkatesh
>Sent: Saturday, August 21, 2004 3:00 AM
>To: stefandoesinger@gmx.at; Nathan Bryant
>Cc: acpi-devel@lists.sourceforge.net; Brown, Len; Linux Kernel list; Li,
>Shaohua
>Subject: RE: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
>
>
>
>
>>-----Original Message-----
>>From: acpi-devel-admin@lists.sourceforge.net
>>[mailto:acpi-devel-admin@lists.sourceforge.net] On Behalf Of
>>Stefan Dösinger
>>Sent: Friday, August 20, 2004 9:36 AM
>>To: Nathan Bryant
>>Cc: acpi-devel@lists.sourceforge.net; Brown, Len; Linux Kernel
>>list; Li, Shaohua
>>Subject: Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
>>
>>Am Freitag, 20. August 2004 14:18 schrieb Nathan Bryant:
>>> Stefan -
>>>
>>> Also - did suspend/resume for the ipw2100 ever work under any kernel
>>> version?
>>Yes, it works with acpi=noirq at least up to 2.6.7(not tested
>>with later
>>versions, but I'm sure it does)
>>It works with 2.6.8-rc2 and 2.6.8-rc4 and 2.6.8.1 with acpi IRQs and a
>>modified dsdt which forces LNKE to IRQ 10. I attached a dmesg
>>output of a
>>successful resume.
>>
>>Cheers,
>>Stefan
>
>This seems to be the same resume order issue, that Shaohua is hitting.
>
>On my system the resume order looks like this:
>Resuming System Devices
>Resuming type 'cpu':
> cpu0
>aux driver resume 0xc010e410 (mtrr_restore)
>aux driver resume 0xc03365f0 (cpufreq_resume)
>Resuming type 'i8259':
> i82590
>Resuming type 'timer':
> timer0
>Resuming type 'pit':
> pit0
>Resuming type 'lapic':
> lapic0
>Resuming type 'irqrouter':
> irqrouter0
>Resuming type 'i8042':
> i80420
>
>The current theory I have for this issue is we resume pci_link driver
>A bit too late, which is causing this problem.
>
>Say a particular device doesn't do anything for suspend and resume.
>So, as soon as we resume this particular device can start
>generating interrupts. Once we have PIC enabled, it starts sending
>interrupts and no one handles that original IRQ. As pci_link that
>resumes later is reprogramming the device to different IRQ, where the
>driver is handling the device.
>
>That's probably the reason why it works with acpi=noirq or
>modified DSDT. Does it make sense?
>
>I think we have to resume pci_link device before PIC.
>We should be able to achieve this my changing the makefile orders.
>
>Thanks,
>Venki
>
^ permalink raw reply [flat|nested] 22+ messages in thread* RE: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
@ 2004-08-23 5:58 ` Li, Shaohua
0 siblings, 0 replies; 22+ messages in thread
From: Li, Shaohua @ 2004-08-23 5:58 UTC (permalink / raw)
To: Pallipadi, Venkatesh, stefandoesinger, Nathan Bryant
Cc: Brown, Len, acpi-devel, Linux Kernel Mailing List
Right, this looks like the problem I encounter. My current test shows that the problem only occurs if ACPI changed LINK devices' IRQ. If ACPI use default LINK device IRQ, the problem went off.
Currently there are two workarounds:
1. comment one line in pci_link.c:acpi_pci_link_allocate, like below
/*
* forget active IRQ that is not in possible list
*/
if (i == link->irq.possible_count) {
if (acpi_strict)
printk(KERN_WARNING PREFIX "_CRS %d not found"
" in _PRS\n", link->irq.active);
+// link->irq.active = 0;
}
This disables rebalance IRQ, which fixes my problem.
2. change 'device_initcall(i8259A_init_sysfs);' to 'late_initcall(i8259A_init_sysfs);'
It seems that if OS changed BIOS IRQ router setting (like ACPI change Link device setting), IRQ router should resume before PIC. This possibly proves what Venki said.
PS. For the resume order, isn't it strange Local APIC resumes after PIT? I guess it should be the first device to resume.
Thanks,
Shaohua
>-----Original Message-----
>From: Pallipadi, Venkatesh
>Sent: Saturday, August 21, 2004 3:00 AM
>To: stefandoesinger@gmx.at; Nathan Bryant
>Cc: acpi-devel@lists.sourceforge.net; Brown, Len; Linux Kernel list; Li,
>Shaohua
>Subject: RE: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
>
>
>
>
>>-----Original Message-----
>>From: acpi-devel-admin@lists.sourceforge.net
>>[mailto:acpi-devel-admin@lists.sourceforge.net] On Behalf Of
>>Stefan Dösinger
>>Sent: Friday, August 20, 2004 9:36 AM
>>To: Nathan Bryant
>>Cc: acpi-devel@lists.sourceforge.net; Brown, Len; Linux Kernel
>>list; Li, Shaohua
>>Subject: Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
>>
>>Am Freitag, 20. August 2004 14:18 schrieb Nathan Bryant:
>>> Stefan -
>>>
>>> Also - did suspend/resume for the ipw2100 ever work under any kernel
>>> version?
>>Yes, it works with acpi=noirq at least up to 2.6.7(not tested
>>with later
>>versions, but I'm sure it does)
>>It works with 2.6.8-rc2 and 2.6.8-rc4 and 2.6.8.1 with acpi IRQs and a
>>modified dsdt which forces LNKE to IRQ 10. I attached a dmesg
>>output of a
>>successful resume.
>>
>>Cheers,
>>Stefan
>
>This seems to be the same resume order issue, that Shaohua is hitting.
>
>On my system the resume order looks like this:
>Resuming System Devices
>Resuming type 'cpu':
> cpu0
>aux driver resume 0xc010e410 (mtrr_restore)
>aux driver resume 0xc03365f0 (cpufreq_resume)
>Resuming type 'i8259':
> i82590
>Resuming type 'timer':
> timer0
>Resuming type 'pit':
> pit0
>Resuming type 'lapic':
> lapic0
>Resuming type 'irqrouter':
> irqrouter0
>Resuming type 'i8042':
> i80420
>
>The current theory I have for this issue is we resume pci_link driver
>A bit too late, which is causing this problem.
>
>Say a particular device doesn't do anything for suspend and resume.
>So, as soon as we resume this particular device can start
>generating interrupts. Once we have PIC enabled, it starts sending
>interrupts and no one handles that original IRQ. As pci_link that
>resumes later is reprogramming the device to different IRQ, where the
>driver is handling the device.
>
>That's probably the reason why it works with acpi=noirq or
>modified DSDT. Does it make sense?
>
>I think we have to resume pci_link device before PIC.
>We should be able to achieve this my changing the makefile orders.
>
>Thanks,
>Venki
>
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-08-23 6:04 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-04 1:42 [PATCH][RFC] fix ACPI IRQ routing after S3 suspend Nathan Bryant
2004-08-04 1:42 ` Nathan Bryant
[not found] ` <41103F22.4090303-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
2004-08-04 2:59 ` Len Brown
2004-08-04 2:59 ` Len Brown
2004-08-04 15:57 ` Nathan Bryant
2004-08-04 15:57 ` Nathan Bryant
[not found] ` <41110785.4040000-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
2004-08-04 16:10 ` Nathan Bryant
2004-08-04 16:10 ` [ACPI] " Nathan Bryant
2004-08-19 20:24 ` [ACPI] " Stefan Dösinger
[not found] ` <200408192224.08271.stefandoesinger-RbZlAiThDcE@public.gmane.org>
2004-08-19 20:54 ` Nathan Bryant
2004-08-19 20:54 ` [ACPI] " Nathan Bryant
2004-08-20 10:50 ` Stefan Dösinger
2004-08-20 12:18 ` Nathan Bryant
2004-08-20 16:36 ` Stefan Dösinger
-- strict thread matches above, loose matches on Subject: below --
2004-08-20 19:00 Pallipadi, Venkatesh
2004-08-20 19:42 ` Nathan Bryant
2004-08-20 20:01 ` Stefan Dösinger
2004-08-20 20:42 ` Nathan Bryant
2004-08-20 20:43 ` Nathan Bryant
2004-08-20 20:17 ` Stefan Dösinger
2004-08-23 5:58 Li, Shaohua
2004-08-23 5:58 ` Li, Shaohua
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.