分类:
2008-12-27 20:16:59
最近在测试solaris电源管理时发现了两片牛人的博客,转载一下
More Power to You
Typically, I wonder if my posts are more small snippits of tidbits (ahhh, Kibbles and Bits!!!!), but here is a bit more.
The Solaris operating environment supports various aspects of power management, including Suspend and Resumve (a.k.a. CheckPoint and Resume, or CPR), and soon, so will Solaris on x86 (much of which will go through the ACPI interfaces). It is, therefore, important that your drivers support the Solaris power management interfaces:
Much on these interfaces can be found at , or on the relevant man pages for the attach(9e), detatch(9e), and power(9d) man pages.
But in a nutshell, DDI_SUSPEND and DDI_RESUME cases should handle the saving and restoring of hardware state before a device is shutdown or restored after a shutdown. And power(9e) is the procedure that Power Management framework functions will call when it wants to manage components that provide power management facilities in the hardware.
the power(9e) entry point also works in conjunction with:
So are you writing a driver, and expect it to work with Solaris Power Management. Well, the first and most important part of this equasion is that you MUST implement the DDI_SUSPEND and DDI_RESUME commands to the attach and detach routines in your driver. And in this section of the code, it is important to take information from the hardware, and save it into kernel memory (maybe a pointer within the driver soft state). On resume, all that is necessary, is to take this saved state, and put it back in the hardware:
xxx_detach() [ switch (cmd) { case DDI_SUSPEND: /* Save hardware state */ if (OK) return (DDI_SUCCESS); else return (DDI_FAILURE); break; case DDI_DETACH: /* Do attach processing */ if (OK) return (DDI_SUCCESS); else return (DDI_FAILURE); break; default: /* Shouldn't be here */ return (DDI_VAILURE); } xxxattach() { case DDI_RESUME: /* Restore hardware state */ /* See the return related information in detach */ break; case DDI_DETACH: /* Do attach processing */ default: /* Shouldn't be here */ return (DDI_FAILURE); }
Of course, the relevent hardware information needed to save and/or restore the driver after a suspend/resume needs to be put inside the DDI_SUSPEND/DDI_RESUME case, and cannot really be presented here. However, if a the driver is written well, it can very well have a drv_suspend() function, (or even a save_state or restore_state function), and the attach/detach routines become very easy to manage.
And should your driver be able to handle various power states, say a laptop framebuffer that allows for the backligh to be at lower intensity, or a disk driver that allows for the drive to spin down, then you must also implement the power(9e) entry point and many of the pm_* routines above (gotta register the components, and let the Solaris power management framework know when they are idle).
But alas, this may be a lot of thinking for a day, so maybe it is time for a California Pale Ale!
OK, there really isn't a category for a California Pale Ale, but one of the classic Pale Ales from California, is the Sierra Nevada Pale Ale. Light and crisp, with a hit of hop fruitiness. A great ale for a fine fall day.
And sometime later, I will add some more details to Power Mangement
Do you have some questions or suggestions, just add a comment, I will happily elaborate more!