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

[Alexander Motin]

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