On 3/21/07, Terry (Sarito) Whatley <[EMAIL PROTECTED]> wrote:
sunpm.c does not require modification to handle an "off" power state. The pm framework considers a power level of 0 to be off. The us driver doesn't support an off state (doesn't advertise a 0 level in its pm-components property) because on the platforms that it runs on (SPARC workstations), there is no "off" state of the processor (no way to turn off the processor).
Frequency scaling is a power state (it greatly reduces power consumption to reduce the clock frequency). us_drv.c does not handle a 0 power state (off) because the hardware it supports can't do it.
The us driver only deals with the power level (frequency) of a cpu. It was created to allow workstations to meet the EPA's EnergyStar guidelines by reducing their power consumption. It is not involved in adding or removing cpus from the system because no workstations support that functionality (at least in 2000 when it was done--though I'm not aware of any that do now either--the X86 cpus can't be turned off either in the current workstations that I know of, they can only have their frequency and voltage reduced).
Ok, I think I understand. But dynamic reconfiguration on these machines won't work either then, will it? The project I am working on does not have the ultimate goal of using a SPARC processor, we are using it because the simulator has a good model of it and Solaris has a well established code base for it. Since we are using a simulator, I believe it *is* possible in our case, to alter the us driver to allow a processor to get shutdown, if we imagine the simulated processor does have that possibility. This would allow us to verify whether the shutdown strategy we implement does work, and that it does save power. We could estimate the power savings using the appropriate power model. Afterwards, this code could be ported to processor architectures that do support shutdown. We could either alter us_drv so that when trying to go slower than the current slowest possible speed, the processor gets shut down. Or, for research purposes, we could disable frequency scaling, and only support on/off and possible intermediate power states, to be able to verify the impact of the pure states themselves. I believe we then would need to write a complete alternate us_drv. Do you understand the way I think and do you think this is a possible way? Thanks, Thomas _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
