[linux-pm] [PATCH 2/2] Fix console handling during suspend/resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 26 Jun 2006, Linus Torvalds wrote:

> 
> 
> On Tue, 27 Jun 2006, Adam Belay wrote:
> > 
> > Yes, and pci_set_power_state() can require msleep().
> 
> Actually, I was looking at that, and it's a problem right now.
> 
> For all the silly (and wrong) reasons.
> 
> The msleep() shouldn't actually be in pci_set_power_state(), but in the 
> infrastructure that calls it. In particular, when actually powering down, 
> there's no point in doing a msleep() between each device - we'll be 
> sleeping a lot longer than 10ms after we've gone down.
> 
> The fact that D3hot won't necessarily take effect until 10 ms after we've 
> done the "go to sleep" thing obviously doesn't really mean that we should 
> actually sleep 10 msec _there_.

What about other occasions when pci_set_power_state() is called?  For 
instance, a selective suspend.  Where's the appropriate place to delay in 
that case?

What happens if the system sleep is aborted (some later driver is unable 
to suspend) and everything gets resumed immediately?  Where should the 10 
ms delay occur then?

Alan Stern



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux