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().
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. And the policy, they have the different behavior, don't they? Thanks, -Aubrey
