DragonFly-2.3.0.876.g136cd master sys/dev/acpica5 acpi_hpet.c

[Sepherosa Ziehau]

On Tue, May 5, 2009 at 12:05 PM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Tue, May 05, 2009 at 11:32:35AM +0800, Sepherosa Ziehau wrote:
>> On Tue, May 5, 2009 at 10:51 AM, Joerg Sonnenberger
>> <joerg at britannica.bec.de> wrote:
>> > On Sun, May 03, 2009 at 04:35:04AM -0700, Sepherosa Ziehau wrote:
>> >>     hpet: Veto Sx state transition, if hpet is the sys_cputimer, since
>> >>     hpet is not required to function under S1-S5.  Add comment about
>> >>     the reference to the related hpet standard items.
>> >
>> > Huh? Why do you block S3 and S4 as well?
>>
>> Main counter may not be preserved in S3 and S4; I didn't find a good
>> spot on the code path to safely save/restore the main counter, that's
>> also why S1 and S2 are vetoed.  Any insight?
>
> Why do you care about the actual counter value? Like for the i8254, it

No, not the actual count, but we will have to make sure the count is
monotonically increasing.  So something like "not preserved" is not
acceptable.

> has to be reprogrammed after S3/S4 or at least recomputed by the code
> that reads back the RTC value.

Didn't aware how 8254 could be affected, 8254 document mentions
nothing about power management stuffs.  But even if 8254's count is
not maintained at all, it seems to be less affected (+-1/15sec), since
major portion of the time is saved in dram.

If small gitch is acceptable, we could just add sys_cputimer
save/restore functions and call them before and after Sx state
transiton.

-- 
Live Free or Die