Re: A reference implementation of PCI suspend/resume?

["Rafael J. Wysocki" <rjw@sisk.pl>]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

Hi,

On Tuesday, 17 of May 2005 02:26, David Brownell wrote:
> On Monday 16 May 2005 2:19 pm, Jordan Crouse wrote:
> > On Mon, 16 May 2005 16:16:06 -0400
> > "Adam Belay" <ambx1@neo.rr.com> wrote:
> > 
> > > b.) You're assuming every device has its own interrupt.  This may not
> > > be the case.  Let's say one device was sharing interrupts with a few
> > > other devices...
> > 
> > I ran into this very problem a while back on 2.4. On my platform, the
> > EHCI and OCHI host controllers share an interrupt.  ...
> > 
> > Now, granted that particular scenario is a corner case, and the PCI
> > hardware should have been configured better, but it shows that you
> > can't assume that any given interrupt handler will only be called with
> > active hardware underneath.
> 
> Very true, and that's part of why drivers/usb/core/hcd-pci.c frees
> IRQs during suspend, and reclaims them later.
> 
> AFAICT that code is the most generic PCI suspend/resume code now
> available ... since it's got to work with dozens of different
> implementations of EHCI, OHCI, and UHCI; with widely varying
> BIOS versions and bugs; and where not all controllers support
> the PCI PM extensions.
> 
> Note the wierdnesses there ... cases where the PCI API calls are
> wierdly asymmetric, and where "swsusp" can really bork things
> by entering bizarre "resume" paths.

Could you please have a look at http://bugzilla.kernel.org/show_bug.cgi?id=4416

There seems to be a problem with OHCI and EHCI drivers wrt suspend/resume
(swsusp) in the current -mm on that box.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]