I created the repository that we can use for the CPU power management rework. You can clone it:
$ hg clone ssh://your-login at hg.opensolaris.org/hg/tesla/cpupm-gate It's based off of onnv_77. So if you want to build it, you'll need the closedbin files for build 77. I've attached a changeset patch that I'm considering pushing. But before I push it, I wanted to give you a chance to look it over and make sure it looks like it's headed the right direction. I believe that in the end, we'll basically be rewriting the CPU driver and it will support P-states, C-states and T-states. The attached patch is nothing more than a very minor restructure of the initialization code. I've already begun rewriting the CPU driver code and might have something that can be pushed later this week (maybe next). I expect that the initial changes might even result in disabling SpeedStep support for a short time, but maybe not. I'll update the Tesla project page with the necessary cpupm-gate information. I have some comments in-line below ... Li, Aubrey wrote: > On Wednesday, November 28, 2007 5:32 AM, Mark.Haywood at Sun.COM wrote: > > >> As for the _PDC, I hadn't given it much thought yet, other than >> realizing structurally it should be independent of the p-state >> management code. From a design point of view, it was our >> intent that the >> x64 CPU driver would be responsible for driving the different >> aspects of >> x64 CPU power management. To me that means p-state, t-state >> and c-state >> support. >> >> Since we will not support all three of those (at least not at >> the same >> level) on all processors, I think we need to have an initial function >> that figures out which of those (if any) are supported, to what degree >> they are supported and caches that information in a local >> structure. The >> _PDC can be written at the end of the function or directly after >> returning from the function. This will require some restructuring and >> redefinition of some of the existing structures in >> cpudrv_plat.c. >> >> To give you an idea of what I'm talking about you can take a >> look at the >> attached files. They are rough and haven't been compiled and there are >> obvious other changes that would need to be made, but I think >> you might >> get an idea of what I have in mind. The walk in >> cpudrv_pm_init_module() >> would now walk a cpudrv_vendor_ops module. >> >> Assuming this seems reasonable and if we get our repository set, I can >> get this restructuring in place. >> >> > The attached framework looks good to me, ;-) > We can discuss more details later, like speedstep feature, it's taken as > a platform feature, > not a processor feature, so it's not necessary to check it in the > intel_cpupm_init(). > I'm not really sure what you are saying here. Take a look at the patch and see if what I've done makes sense in this regard. Remember that we are not supporting SpeedStep on all processors (not even all Intel processors). > Besides the initialization funtion, cpudrv_power()(and structure > cpudrv_pm) is another point need to be considered. > Currently it only care about speed, C-state and T-state should be > included as well. > Yes, I expect to be pulling the CPU driver apart. It's currently common code with the SPARC CPU driver. Given where we are headed, I don't think this makes sense. So, the cpudrv_pm structure (if it continues to be called that) will change significantly. You believe that cpudrv_power (maybe this function needs to be renamed) should care about T-states and C-states? Currently, this function just handles P-state transitions. I'm not sure that it should care about T-states and C-states. > And the policy, they have the different behavior, don't they? Sorry, which policies are you talking about? We currently only have one P-state policy (autopm behavior). We'll be adding more policies as part of this project though (e.g., ability to set CPUs to specific frequency). Are these the policies that you are referring to? If so, yes, I'm sure we'll be caching policy information in the driver structure somehow. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: restruct.patch.gz Type: application/x-tar Size: 4563 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20071203/87915b25/attachment.tar>
