From: Shaohua Li <shaohua.li@intel.com>
To: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
Cc: linux-pm <linux-pm@lists.osdl.org>
Subject: RE: A reference implementation of PCI suspend/resume?
Date: Mon, 16 May 2005 16:55:34 +0800 [thread overview]
Message-ID: <1116233734.7314.7.camel@linux-hp.sh.intel.com> (raw)
In-Reply-To: <9F77D654ED40B74CA79E5A60B97A087B0310DCD4@sd-exchange.sdesigns.com>
[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]
On Fri, 2005-05-13 at 22:06 -0700, Fabrice Gautier wrote:
> > There are still many PCI drivers don't implement their
> > .suspend/.resume
> > methods correctly. I felt it would be quite helpful there is
> > a reference
> > implementation. Here is my thought:
> >
> > [...snip...]
> >
> > Currently many drivers don't call
> > free_irq/request_irq/pci_disable_device, which makes unexpected
> > interrupt occur and even break suspend/resume in some systems.
>
> I don't understand why not calling free_irq would cause unexpected
> interrupts.
>
> The way I understand the PCI spec is: if you suspend a PCI device, its IRQ
> should be disabled. If an IRQ come from this device anyway (in violation of
> the spec) then the driver for this device should handle it so you should NOT
> unregister its irq_handler.
> (How does such a device would handle such a irq is another matter - a device
> specific one I guess)
>
> I'm not understanding where your unexpected interrupt is coming from.
>
> Care to elaborate?
I actually don't know the exact reason but we did notice disabling a
device isn't sufficient (an 'irq nobody card' is reported after a device
is disabled). I think we should not trust device.
Another point is resume is just like boot. At boot time, PIC/IOAPIC/irq
router are disabled by default. They are enabled only when a device
really starts using them. suspend/resume should be the same manner.
Thanks,
Shaohua
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2005-05-16 8:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-14 5:06 A reference implementation of PCI suspend/resume? Fabrice Gautier
2005-05-16 4:53 ` David Brownell
2005-05-16 8:55 ` Shaohua Li [this message]
2005-05-16 20:16 ` Adam Belay
2005-05-16 20:56 ` Rafael J. Wysocki
2005-05-16 21:19 ` Jordan Crouse
2005-05-17 0:26 ` David Brownell
2005-05-17 9:10 ` Rafael J. Wysocki
2005-05-17 18:35 ` David Brownell
2005-05-17 19:28 ` Rafael J. Wysocki
2005-05-18 1:26 ` Adam Belay
2005-05-18 17:40 ` Rafael J. Wysocki
2005-05-18 18:32 ` Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2005-05-16 19:02 Fabrice Gautier
2005-05-16 19:39 ` David Brownell
2005-05-12 1:24 Shaohua Li
2005-05-12 6:21 ` Adam Belay
2005-05-12 7:03 ` Shaohua Li
2005-05-27 6:49 ` Shaohua Li
2005-05-27 7:20 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1116233734.7314.7.camel@linux-hp.sh.intel.com \
--to=shaohua.li@intel.com \
--cc=Fabrice_Gautier@sdesigns.com \
--cc=linux-pm@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.