Hi, On Thursday, September 22, 2011, Alan Stern wrote: > Rafael: > > I just tried testing the wakeup functionality of my OHCI USB > controller, something I haven't done in a long time. It's an add-on > PCI card, and it uses regular PCI PM: > > # lspci -vv -s 1:01.1 > 01:01.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) > Subsystem: NEC Corporation Hama USB 2.0 CardBus > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 32 (250ns min, 10500ns max), Cache Line Size: 32 bytes > Interrupt: pin B routed to IRQ 23 > Region 0: Memory at fe5de000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [40] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Kernel driver in use: ohci_hcd > > The tests were under 3.1-rc4. The device wakes up perfectly well from > runtime suspend, but it doesn't wake the computer from system suspend. > Perhaps something goes wrong when the PME# signal has to be routed > between PCI buses while the system is asleep, perhaps not -- I don't > know how to tell. > > Do you have any ideas for fixing this problem? To start with, I would add debug printk's to acpi_pci_sleep_wake() and acpi_pci_propagate_wakeup_enable() to see if the wakeup settings propagate to the bridge and possibly up. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
