Re: A reference implementation of PCI suspend/resume?

["Jordan Crouse" <jordan.crouse@amd.com>]

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

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. We don't want it's interrupt handler to mess up things
> when it tries to read hardware registers from a physically "off"
> device, as it may possibly generate errors.  Almost every interrupt
> handler assumes the device is "on", as it should.  Each interrupt
> handler has to ask its hardware if it generated the interrupt.

I ran into this very problem a while back on 2.4. On my platform, the
EHCI and OCHI host controllers share an interrupt.  I was insmoding the
EHCI module before the OHCI module, but it turned out that the OHCI
controller was first on the bus, so it went down first during suspend,
and up first on resume.  Long story short, it starting firing interrupts
which went to the EHCI driver first (since it was earlier on the
interrupt handler chain), and the device faithfully hung waiting to read
hardware that was still powered off.

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.

So either an "active" bit gets added to each and every driver to be
checked in an interrupt routine, or we bail on the handler all together
- I fancy the second.

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>



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