* Viresh Kumar viresh.kumar@linaro.org wrote:
On 20 February 2015 at 18:52, Ingo Molnar mingo@kernel.org wrote:
- Viresh Kumar viresh.kumar@linaro.org wrote:
CLOCK_EVT_DEV_MODE_UNUSED = 0,What is 'unused' - not initialized yet?
Unused. Initially all clockevent devices are supposed to be in this mode but later if another device replaces an existing one, the existing one is put into this mode.
I'd suggest to rename it to MODE_INIT - at first glance it gave me the impression that it's some sort of API placeholder - i.e. an unused flag or so.
Also, I'd suggest to rename all 'modes' to true state machine naming: STATE_INITIALIZED, STATE_SHUT_DOWN, STATE_PERIODIC, STATE_RESUMED, etc.: if these are enums for states and not state transition names, see my later questions:
CLOCK_EVT_DEV_MODE_SHUTDOWN,CLOCK_EVT_DEV_MODE_PERIODIC,CLOCK_EVT_DEV_MODE_ONESHOT,CLOCK_EVT_DEV_MODE_RESUME,What is 'resume' mode?
Introduced with: 18de5bc4c1f1 ("clockevents: fix resume logic") and is only called during system resume to resume the clockevent devices before resuming the tick. Only few implementations do meaningful stuff here.
So is it a state that a clockevents device reaches, or a state transition? The two purposes seem to be mixed up in the nomenclature.
CLOCK_EVT_DEV_MODE_ONESHOT_STOPPED, /* This would be the newmode which I will add later */
What does this mode express?
I have added it here to show how things would look like eventually, but it wouldn't be present in the patch which splits the enum into two parts..
Yeah.
Its only important for NOHZ_FULL (IDLE ? Maybe). When we decide that the tick (LOWRES) or hrtimer interrupt (HIGHRES) isn't required for indefinite period of time (i.e. no timers/hrtimers are present to serve), we skip reprogramming the clockevent device. But its already reprogrammed from the tick-handler and so will fire atleast once again.
So this new 'mode' appears to be a true state of the device?
Thanks,
Ingo