svn commit: r238004 - in head: etc/rc.d sys/dev/acpica

[Alexander Motin]

On 07/02/12 19:57, Sean Bruno wrote:
> Author: sbruno
> Date: Mon Jul  2 16:57:13 2012
> New Revision: 238004
> URL: http://svn.freebsd.org/changeset/base/238004
>
> Log:
>    Cosmetic display change of Cx states via cx_supported sysctl entries.
>
>    Adjust power_profile script to handle the new world order as well.
>
>    Some vendors are opting out of a C2 state and only defining C1 & C3.  This
>    leads the acpi_cpu display to indicate that the machine supports C1 & C2
>    which is caused by the (mis)use of the index of the cx_state array as the
>    ACPI_STATE_CX value.
>
>    e.g. the code was pretending that cx_state[i] would
>    always convert to i by subtracting 1.
>
>    cx_state[2] == ACPI_STATE_C3
>    cx_state[1] == ACPI_STATE_C2
>    cx_state[0] == ACPI_STATE_C1
>
>    however, on certain machines this would lead to
>    cx_state[1] == ACPI_STATE_C3
>    cx_state[0] == ACPI_STATE_C1
>
>    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.

-- 
Alexander Motin