on 03/07/2012 00:17 Sean Bruno said the following:
> Agreed.  We shall have to discuss further and see where this leads us.
> Its starting to look like some amount of further overhaul may be
> required.

[Just replying to a high-level thing here.]
Or maybe no overhaul at all?.. :-)

Our current approach of using C-state indexes as C-state identifiers/names may 
not so bad after all if we remove confusion by properly documenting the meaning
(index vs "type").
Here is a link to a past discussion on this topic:
I think that messages in a sub-thread starting at the highlighted message may
provide some useful information.
Here are couple of links to the code in Linux and OpenSolaris:

So, now as then I still don't have any preference for either of methods.  But 
decision is not straightforward as you might see now, thus we need some 
that any change is needed actually :-)

For more information about each C-state I would go a way of creating a sysctl
forest with a tree at each C-state under each CPU (for potential asymmetric
C-state support), which would describe all available parameters of each C-state
(power, latency, ACPI (or HW-specific[*]) type, I/O-vs-MWAIT-vs-etc type of
entrance, etc).

[*] E.g. for intel_idle it could be C-state numbers from Intel specs.
Andriy Gapon

freebsd-acpi@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to