* Viresh Kumar <[email protected]> wrote:
> On 20 February 2015 at 18:52, Ingo Molnar <[email protected]> wrote:
> >
> > * Viresh Kumar <[email protected]> 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 new
> >> mode 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
