On Tuesday 09 September 2008, Rafael J. Wysocki wrote: > > > > Another rather important case is bridges. I observe that with ACPI > > the way PME# is handled for add-in cards _seems_ to be that the bridge > > for that PCI bus segment gets a GPE (presumably matching the PME# > > signal for that bus segment, and maybe for its subsidiaries). That > > suggests the bridge will need to scan its children to find out which > > one(s) issued PME#. You didn't include such code here, where that > > notification will be received... > > AFAICS, the 'original' PCI PME# (as opposed to the PCI Express native PME) > signal is supposed to be routed _around_ bridges and (presumably) the entire > PME# network would share one GPE in that case. To the extent that board designers are expected to follow such rules, but have the power not to do so, we know that relying on such expectations would be ... unwise. ;) Isn't the notion of a GPE pretty much an x86-ism? For non-x86 systems I'd just think "IRQ". And for x86, I regularly wonder if maybe chaining through genirq wouldn't make SCI interrupts, including GPEs, become a lot more robust. :( I suspect folk maintaining non-ACPI platforms with PCI wiill have to help sort out this particular issue. I suspect their board designs will provide at least one PME# indication. ISTR multiple PME# domains were OK, at least in the "one per root bridge" sense, but I've not looked at the relevant spec recently. > Then, we'd actually have to > check all of the PCI devices to see which of them caused the event to happen. That emphasizes my point: that patch #3 needs to include code to handle bridges, scanning wakeup-eligible devices until it finds the relevant one(s). Of course there should be a few ways to speed that scanning: - First, bridges shouldn't need to scan devices for which PME# was not enabled. Make pci_enable_wake() record that state for use in scanning ... look at that handful of devices first. (And possibly the rest later, in case of errors.) - Second, ACPI-specific, is to recognize that the mainboard devices all seem to be associated with private GPEs so they can get direct wake event notifications. So when the PCI device getting this notification/probe isn't a bridge, it won't need to scan other devices. EVERY system I have here seems to have PCI devices, including ones in add-in slots, which will require that scanning ... because they don't show up in the ACPI tables (second case). - Dave -- 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
