> -----Original Message-----
> From: Thomas Gleixner <t...@linutronix.de>
> Sent: Tuesday, March 30, 2021 5:18 AM
> To: J.d. Yue <jindong....@nxp.com>
> Cc: linux-kernel@vger.kernel.org; fweis...@gmail.com; mi...@kernel.org
> Subject: [EXT] Re: [PATCH] tick/broadcast: Allow later probed device enter
> oneshot mode
>
> Caution: EXT Email
>
> On Mon, Mar 29 2021 at 13:25, Jindong Yue wrote:
>
> > /*
> > * Debugging: see timer_list.c
> > @@ -115,8 +116,20 @@ void tick_install_broadcast_device(struct
> clock_event_device *dev)
> > * notification the systems stays stuck in periodic mode
> > * forever.
> > */
> > - if (dev->features & CLOCK_EVT_FEAT_ONESHOT)
> > + if (dev->features & CLOCK_EVT_FEAT_ONESHOT) {
> > tick_clock_notify();
>
> If the kernel runs in oneshot mode already, then calling
> tick_clock_notify() does not make sense.
Yes, there should be more check before tick_clock_notify().
>
> > + /*
> > + * If new broadcast device is installed after high resolution
> > + * timers enabled, it can not switch to oneshot mode
> anymore.
>
> This is not restricted to high resolution timers. The point is that the mode
> is
> ONESHOT which might be either HIGHRES or NOHZ or both.
Got it, after kernel enters ONESHOT mode, new registered broadcast device can't
be switched to ONESHOT mode.
>
> > + */
> > + if (tick_broadcast_oneshot_active() &&
> > + dev->event_handler != tick_handle_oneshot_broadcast)
> > + {
>
> How would that condition ever be false for a newly installed device?
Okay, will remove this condition.
>
> > + tick_broadcast_switch_to_oneshot();
> > + }
>
> So what you really want is:
>
> if (!(dev->features & CLOCK_EVT_FEAT_ONESHOT))
> return;
>
> if (tick_broadcast_oneshot_active()) {
> tick_broadcast_switch_to_oneshot();
> return;
> }
>
> tick_clock_notify();
>
> Thanks,
>
> tglx
Thanks for your quick review and advice. I will test this code locally and send
V2 patch later.
Jindong
