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 
be
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:
http://thread.gmane.org/gmane.os.freebsd.current/127860/focus=6373
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:
http://lxr.linux.no/#linux+v3.4.4/drivers/acpi/processor_idle.c#L354
http://lxr.linux.no/#linux+v3.4.4/drivers/acpi/processor_idle.c#L1097
http://fxr.watson.org/fxr/source/i86pc/os/cpupm/cpu_acpi.c?v=OPENSOLARIS#L683
http://fxr.watson.org/fxr/source/i86pc/os/cpupm/cpu_idle.c?v=OPENSOLARIS;im=bigexcerpts#L678

So, now as then I still don't have any preference for either of methods.  But 
the
decision is not straightforward as you might see now, thus we need some 
convincing
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
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to