On 07/02/12 20:30, Sean Bruno wrote:
On Mon, 2012-07-02 at 10:11 -0700, Alexander Motin wrote:
This didn't break anything but led to a display of:
* dev.cpu.0.cx_supported: C1/1 C2/96
Instead of
* dev.cpu.0.cx_supported: C1/1 C3/96
MFC after: 2 weeks
If I remember correctly, ACPI spec directly specifies that there can
be
several C-states with the same type but with different enter method
and
exit latency. I have never seen any system with more then 3 C-states
yet, but technically I think that is possible. Type field defines
enter/exit semantics, respecting cache coherency and other things, so
I
think there can be more then one state with, for example, C3
semantics.
Latest CPUs support states C1, C3 and C5, while ACPI AFAIK defines
only
three types and it may happen that both C3 and C5 have type-3
semantics.
From my read of the current ACPI specs, there isn't anything past C3.
Right. Because that type semantics is already quite strict to not need
deeper. ACPI doesn't bother how CPU implements C3 and C5 and where it
saves context.
However, Intel has definied Mwate Cstates that use the same nomenclature
and confuse what people think Cstates are. Is this what you mean by
"C5"
Yes. ACPI C-states are not equal to CPU C-states and none of them are
equal to ACPI types. I am not sure there is enough information to be
more precise then we are now, unless we will hardcode it based on CPU
IDs. ACPI spec allows BIOS to report how to enter state using MWAIT. In
that case it would be possible to report it. But I haven't seen that used.
--
Alexander Motin
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
