Thanks for bringing this up Aubrey. I've been looking into some of the
reconstruction aspects myself. Specifically, I've been looking at how to
remove the dependency the current implementation has on the Solaris PM
framework. I was thinking that I'd want to do this work in the
tesla-gate. Does it make sense for all of our CPU power management work
to be done in the same repository? I'd favor doing it that way, but am
open to alternatives. I'm also not sure how Eric intended that
repository to be used.
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.
Mark
Li, Aubrey wrote:
> Hi Mark,
>
> As we discussed before, I think it's time to re-consider the
> construction of the current cpu power framework
> before Anup implement T-state driver and I implement C-state driver.
>
> The first thing in my mind is _PDC object. It does not only belong to
> SpeedStep driver.
> I'm thinking:
>
> 1) take cpu_acpi_init() and cpu_acpi_write_pdc() out of speedstep driver
> and place into cpudrv_pm_init_module(),as follows:
> boolean_t
> cpudrv_pm_init_module(cpudrv_devstate_t *cpudsp)
> {
> cpu_acpi_init();
> cpu_acpi_write_pdc();
> walk----cpum_init()
> }
>
> Or 2) take _PDC object as a separate driver, write a simple driver and
> put it into cpudrv_module_ops_table, as follows:
> static struct cpudrv_module_ops *cpudrv_module_ops_table[] = {
> &acpi_pdc_ops,
> &cpu_idle_ops,
> &speedstep_ops,
> &cpu_throttling_ops,
> NULL
> };
>
> And when evaluate _PDC, I still think we should enable all available
> capabilities bits, besides p-state, we need to support c-state and
> t-state.
>
> Any suggestions?
>
> Thanks,
> -Aubrey
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpudrv_intel.c
Type: text/x-csrc
Size: 4026 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20071127/84131d0a/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cpudrv_vendor.h
URL:
<http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20071127/84131d0a/attachment.h>
