>>
>> cpu_acpi_idle()
>> {
>> switch(cstate_type) {
>> case CPU_ACPI_C2/C3:
>> tsc_base = read_TSC();
>> apic_base = read_APIC_TIMER();
>> start = read_HPET();
>> /* TSC and ACPI timer lost */
>> enter_deeper_cstate();
>> end = read_HPET();
>> re-initialize_TSC() { TSC= tsc_base + end - start }
>> re-initialize_APIC() { APIC = apic_base + end - start }
>> }
>>
>> Does this make sense?
>>
>>
>Yes. This is close to what we plan to do. :-)
You can probably take it from another CPU that's not in deep-c state (if
there is one?)
Are there any drift/calibaration issues when you consider taking HPET
source to reinit lapic timer/tsc?
>
>>
>Are there systems where CPU_ACPI_C2 does not reset the TSC
>and APIC state on existing hardware? If so we would like to avoid
>needlessly restoring state.
>
You probably want to decouple TSC stopping and LAPIC stopping.
Nehalem tsc doesn't stop indicated by x86_feature bit (new and coming)
But lapic timer still stops in deep c state.
