Hi!

quoted text
> > to answer your question "what happens at boot"...
> > 
> > interrupts are enabled in start_kernel()
> > well before the ACPI interpreter is started
> > up in a subsys_initcall().
> > 
> > The first use of the interpreter indeed allocates memory
> > (as every invocation of acpi_evaluate_object() does)
> > to evaluate _PIC
> > ie. when we print out "ACPI: Using IOAPIC for interrupt routing".
> > 
> > So one would first think we could WARN_ON(irqs_disabled())
> > right at acpi_evaluate_object(), or at any external
> > entry to the AML interpreter.
> > 
> > But _GTS and _BFS are counter-examples --
> > they are ONLY evaluated with interrupts OFF,
> > since they are between the invocation of arch_suspend_disable_irqs()
> > and arch_suspend_enable_irqs().  I believe that they are the
> > ONLY counter-examples, and for those we'd conceivably
> > WARN_ON(!irqs_disabled).
> > 
> > But at resume...
> > irqrouter_resume() is called to restore ACPI PCI Interrupt Link Devices
> > while we still have interrupts disabled.  If we called it after interrupts
> > were enabled, then an incorrectly resumed link could cause a
> > screaming interrupt.
> > 
> > This is different from boot-time.  At boot time
> > we disable all the links b/c we know that the drivers
> > that use them will all request_irq() and we'll set
> > up the links one by one at that time.
> > 
> > Originally we had planned for suspend to be like boot --
> > every driver would free_irq() at .suspend
> > and request_irq() at .resume -- indirectly for pci devices
> > via pci_enable_device()...
> > This would leave the Links disabled at suspend time, like we
> > disable them at boot time -- and then the request_irq()'s would
> > come in from the resumed drivers and the links would be re-programmed.
> > I don't think we succeeded here, and IIR Linus didn't like our
> > suggestion that every driver must do something, rather than do nothing....
> > So the irqrouter_resume safety-net remains.
> > 
> > But restoring a PCI Interrupt Link Device evaluates _CRS, _PRS, _SRS --
> > general methods which are also invoked at other times with
> > interrupts enabled.  So for those we'd not be able to WARN_ON()
> > for either irqs enabled or disabled:-(
> > 
> > I have to think about irqrouter_resume a bit.
> > I don't like it, but I don't see an alternative -- unless we
> > do something like ENFORCE all users of the links have to
> > stop using them at suspend, so we can _DIS them,
> > and they must request their IRQs at resume
> > like they do at boot...
> 
> Well, that was my question to Linus in a recent discussion.
> 
> I see some technical reasons to require drivers to free IRQs during
> suspend.  First, the issue above.  Second, some removable devices may not
> even be present during resume while we may still think they use an IRQ
> (or is that impossible for some reason?).
> 
> Now, _if_ we decide we want devices to free IRQs during suspend, we can make
> the core do that, so that the drivers won't have to worry about it.

How can we make core do that?

I think that would be everyones prefered suggestion:

Linus: happy, because drivers don't have to do anything

me, Len: happy, because interrupts are freed over suspend

...but I don't see how to do that easily&nicely. AFAICT currently
drivers do something like

private_struct->my_interrupt = register_irq()...

If we put my_interrupt in struct device (or somewhere) we could handle
99% devices that have just one interrupt nicely... maybe that's good
enough? (And the rest can free/register them by hand without telling core).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/