Re: irqs_disabled() vs ACPI interpreter vs suspend

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

On Thursday, 18 of December 2008, Pavel Machek wrote:
> Hi!
> 
> > > 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).

Well, for PCI devices we have pdev->irq, so that would be easy.

Thanks,
Rafael