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 _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"