Raj, Ashok wrote:
>>> 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.
>>
I was told TSC will stop in deeper c-state. But I tried the CPU_ACPI_C2
code path I wrote, the system works fine in C2. So, this is really a
good
question. I'll try to see if I can find some docs about this issue.
>
> You probably want to decouple TSC stopping and LAPIC stopping.
Yeah, my system in C3 hangs. And the first place I find is
tod_validate() broken.
I think we should merge Eric's tree - **elimination of lbolt clock()
dependency** first.
Any thoughts?
Thanks,
-Aubrey
