public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
  • [parent not found: <20040824142219.GA13607@gamma.logic.tuwien.ac.at>]
  • * RE: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
    @ 2004-08-20 19:00 Pallipadi, Venkatesh
      2004-08-20 19:42 ` [ACPI] " Nathan Bryant
      0 siblings, 1 reply; 14+ messages in thread
    From: Pallipadi, Venkatesh @ 2004-08-20 19:00 UTC (permalink / raw)
      To: stefandoesinger-RbZlAiThDcE, Nathan Bryant
      Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Brown, Len,
    	Linux Kernel list, Li, Shaohua
    
    
    
    
    >-----Original Message-----
    >From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
    >[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
    >Stefan Dösinger
    >Sent: Friday, August 20, 2004 9:36 AM
    >To: Nathan Bryant
    >Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; 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
     
    
    
    -------------------------------------------------------
    SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
    100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
    Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
    http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
    
    ^ permalink raw reply	[flat|nested] 14+ messages in thread
    * RE: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
    @ 2004-08-04  2:36 Li, Shaohua
           [not found] ` <B44D37711ED29844BEA67908EAF36F037BB9C6-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
      0 siblings, 1 reply; 14+ messages in thread
    From: Li, Shaohua @ 2004-08-04  2:36 UTC (permalink / raw)
      To: Nathan Bryant, Brown, Len
      Cc: acpi-devel, Linux Kernel Mailing List, Stefan D?singer
    
    Nathan,
    I agree your patch should be ok for the special case, but it's not
    sufficient. Please note a Link device is just an abstraction of PCI
    router, which possibly is in ICH. If we use pci=noacpi or acpi=noirq, we
    don't use link device but still use the router and may also change the
    sets of the router (look at i386/pci/irq.c) and so still fail after S3.
    Your patch can't handle this situation. This indicates adding
    suspend/resume code in pci_link.c is not a good idea. Generic solution
    should be to provide LPC driver.
    
    Thanks,
    Shaohua
    
    >-----Original Message-----
    >From: Nathan Bryant [mailto:nbryant@optonline.net]
    >Sent: Wednesday, August 04, 2004 9:43 AM
    >To: Brown, Len
    >Cc: acpi-devel@lists.sourceforge.net; Linux Kernel list; Li, Shaohua;
    >Stefan D?singer
    >Subject: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
    >
    >
    >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?
    
    ^ permalink raw reply	[flat|nested] 14+ messages in thread
    * [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
    @ 2004-08-04  1:42 Nathan Bryant
           [not found] ` <41103F22.4090303-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
      2004-08-19 20:24 ` [ACPI] " Stefan Dösinger
      0 siblings, 2 replies; 14+ 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] 14+ messages in thread

    end of thread, other threads:[~2004-08-25 11:19 UTC | newest]
    
    Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
    -- links below jump to the message on this page --
         [not found] <412B2E16.1040904@optonline.net>
         [not found] ` <20040824123913.GD25947@gamma.logic.tuwien.ac.at>
         [not found]   ` <20040824123913.GD25947-DqSSrKF0TaySnEC3TeqHn5dqbFPxfnh/@public.gmane.org>
    2004-08-24 13:23     ` [PATCH][RFC] fix ACPI IRQ routing after S3 suspend Nathan Bryant
         [not found] ` <20040824142219.GA13607@gamma.logic.tuwien.ac.at>
         [not found]   ` <20040824142219.GA13607-DqSSrKF0TaySnEC3TeqHn5dqbFPxfnh/@public.gmane.org>
    2004-08-24 14:32     ` Nathan Bryant
         [not found]       ` <412B516B.8030704-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
    2004-08-25 11:19         ` Norbert Preining
    2004-08-20 19:00 Pallipadi, Venkatesh
    2004-08-20 19:42 ` [ACPI] " Nathan Bryant
         [not found]   ` <41265443.9050800-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
    2004-08-20 20:01     ` Stefan Dösinger
         [not found]       ` <200408202201.54083.stefandoesinger-RbZlAiThDcE@public.gmane.org>
    2004-08-20 20:42         ` Nathan Bryant
         [not found]           ` <4126621B.3090701-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
    2004-08-20 20:43             ` Nathan Bryant
    2004-08-20 20:17     ` Stefan Dösinger
      -- strict thread matches above, loose matches on Subject: below --
    2004-08-04  2:36 Li, Shaohua
         [not found] ` <B44D37711ED29844BEA67908EAF36F037BB9C6-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
    2004-08-04  2:55   ` Len Brown
    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 15:57     ` 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
    

    This is a public inbox, see mirroring instructions
    for how to clone and mirror all data and code used for this inbox