[linux-pm] States we need to represent

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

 



Hi!

> > APM_STANDBY     -- prepare for APM event. Theoretically, drivers do
> > 		not need to do anything. In practice, it is very good
> > 		idea to put devices into low power state.
> 
> No, no low power state, that will break BIOS in most cases.

Ok.

> > APM_SUSPEND	-- same as APM_STANDBY, but it we should probably
> > 		avoid spinning down disks.
> 
> Hrm... I don't fully understand the difference between APM_STANDBY and
> APM_SUSPEND... Can you explain in more details in what circumstances
> those would be called ?

One is apm -s, second is apm -S. I can almost bet that for some broken
bios different action will be needed for one obscure driver. I believe
that apm -S is APM suspend to disk.

> > SYSTEM_HALT     -- nothing is needed except in very rare cases. 
> > SYSTEM_REBOOT   -- nothing is needed except in very rare cases. 
> > SYSTEM_SHUTDOWN -- at least disks need to be spun down, or data is
> > 		lost. On non-broken hardware, nothing is needed.
> 
> Add to that SYSTEM_KEXEC

Ok.

> > SUSPEND_DISK_DOWN -- very similar to SYSTEM_SHUTDOWN, except wake
> > 		may need to be enabled on some devices.
> > SUSPEND_RAM      -- put devices into low power state
> > SUSPEND_DISK_FREEZE -- stop DMA and interrupts. No need to put devices
> > 		into low power mode, but you must be able to
> > 		reinitialize device from scratch in resume method.
> 
> Ok, do we differentiate the FREEZE done for snapshotting the suspend
> image and the one done to the "loader" kernel just before resuming the
> suspend image ? Maybe we should ...
> 
> I'm getting back to my flags or minor/major thing, some drivers will
> want to differenciate, at SUSPEND_DISK_DOWN level, wether it's a real
> shutdown, or an ACPI S4/5 state, though they definitely can't store any
> state that will be kept on resume here.

Agreed.

> > DEV_DETACH      -- deinitialize device; proably same as
> > 		SYSTEM_SHUTDOWN, I do not understand this one too much.
> 
> What is this ? Driver remove() method is all we need here .. no ?

This is some obscure thing... Basically patrick's attempt at runtime
power managment. I do not understand that properly.

> > Now... How to split this? Perhaps we need major code and flags field?
> > If driver does not know major code, it aborts the request, returning
> > error. Unknown flag should be non-fatal.
> > 
> > What are major codes? Probably
> > 
> > ON
> > FREEZE
> > SUSPEND
> > 
> > are needed. Then mapping would be
> > 
> > APM_STANDBY     -- major = SUSPEND, flags = APM_TO_RAM
> 
> no, major = FREEZE

Yes.

> > SYSTEM_HALT     -- major = ON, flags = HALT
> 
> no, FREEZE

Actually, I do not agree here. There's no need to do anything on
halt. FREEZE can not hurt, but hey, it is not neccessary, right?
System is going to be halted, DMAs do not matter, interrupts do not
matter.

> > SUSPEND_RAM      -- major = SUSPEND, flags = SUSPEND_TO_RAM
> > SUSPEND_DISK_FREEZE -- major = FREEZE, flags = ON_SUSPENDING_KERNEL
> > SUSPEND_DISK_FREEZE -- major = FREEZE, flags = ON_RESUMING_KERNEL
> 
> Ok, so you called them the same but with different flags :) Heh, let's
> get rid of the left column name completely. 

Yep.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


[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