On Thu, 28 Jun 2012, Zhang, QianFeng wrote: > I am looking through the IO device Runtime PM implementation on Linux (Fedora 16). There are some questions that > need you help to clarify for me, here they are Please tell your email client to wrap lines after 72 columns or so. > 1) For those IO devices that could not be waked up through ACPI GPEs or native PCI Express PME , can Runtime suspend/resume be used ? Yes, it can be used. If the drivers need wakeup support then the devices have to have some other wakeup mechanism, such as an IRQ. If the drivers don't need wakeup support then obviously the device doesn't have to provide it. > 2) In rtl8169's implementation of Runtime suspend/resume, there is a routine rtl8169_check_link_status(), which always invokes > pm_schedule_suspend() if the Link line is dis-connected, pm_request_resume() if the Link line is connected. And rtl8169_check_link_status > itself is called through the transmit time out handler, which invokes rtl8169_reset_task. So rtl8169_check_link_status, as an opportunity point > for Runtime PM for its network interface , does not require any wake-up signaling, right? The only Hardware Level requirement for rtl1869_check_link_status > to work in this way is that the link status register can always be read no matter the network interface is in off or on status. I don't know the answers to these questions. > 3) How should the Block IO adapter devices like the SCSI Controller or FC Adapters should do Runtime PM ? In my understand, these > Devices should be auto-suspended when there is no IO request pending for a predefined duration, and they should be resumed when > a new IO request issued by the block layer. So these devices may use a different wake up method that has no dependency on PCI Express PME or > ACPI GPE. I don't know about FC adapters. SCSI controllers do not need wakeup. Alan Stern
