On Sunday 18 January 2009, Benjamin Herrenschmidt wrote: > On Sun, 2009-01-18 at 01:30 +0100, Rafael J. Wysocki wrote: > > > On PCs we have to restore the config spaces before calling pci_enable_device(), > > because otherwise we have a problem with unconfigured devices being enabled > > during resume. > > > > Recently it's turned out that in fact we need to call pci_restore_state() with > > interrupts off and power up the device using the PCI PM native mechanism or we > > have a problem with shared interrupts. A patch for that was sent yesterday. > > > > At the same time we can't call pci_enable_device() with interrupts off. > > > > If there are systems on which the standard config spaces of PCI devices are not > > accessible during resume, they are broken at the moment and quite frankly I > > don't know what to do to fix them. I haven't seen any reports of this type of > > breakage yet, though. > > Well, it's all a bit fishy... > > Part of the problem is that pci_enable_device() is the only chance the > platform gets to do things like turn power or clocks on for devices that > aren't strictly following PCI D states. That's true and not particularly fortunate. :-) > For PowerMac, we get away with it I think mostly because all devices > that are in this case also have explicit calls to the platform code to > turn things on. > > But I can very well see embedded systems having trouble in that area. > > I suppose when it happens, it would be a matter of having the right arch > hook inside pci_restore_state() itself. Yes, I thought about the same thing. That said, the only platform implementing the PCI PM hooks we have at the moment is ACPI ... > As for the problem with interrupts, maybe the right option here is to > have the PCI core always restore the state early ? Yes, that's what we're going to implement shortly. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
