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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
