From: Sodagudi Prasad <psodagud@codeaurora.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: mingo@kernel.org, viresh.kumar@linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Clockevents: Always call clockevents_program_event
Date: Tue, 24 Oct 2017 02:21:26 -0700 [thread overview]
Message-ID: <d5f08a2df403acaabf8fbe5a79e33806@codeaurora.org> (raw)
In-Reply-To: <alpine.DEB.2.20.1710241034350.2369@nanos>
On 2017-10-24 01:37, Thomas Gleixner wrote:
> On Tue, 24 Oct 2017, Prasad Sodagudi wrote:
>
>> Currently tick_program_event function is not calling
>> clockevents_program_event when 'expires == KTIME_MAX',
>> it is just updating clockevent state to
>> CLOCK_EVT_STATE_ONESHOT_STOPPED.
>> clockevents_program_event function updates clockevent
>> device next_event by checking clockevent device state,
>> so always call clockevents_program_event() from tick_program_event.
>
> No. This is fundmentally wrong. If the clockevent is in oneshot stopped
> mode then you cannot call clockevents_program_event(). There is even a
> warning in that code which will trigger.
<Prasad> Yes. There is warning and I overlooked at that part of the code
and thought
it would return from the clockevents_program_event function after
next_event update.
dev->next_event = expires;
if (clockevent_state_shutdown(dev))
return 0;
Thanks tglx for reviewing patch.
How to clean next next_event from clockevent device in the
ONESHOT_STOPPED state from tick_program_event()?
Shall I update the next patch set with following condition? Or Any
other suggestions to fix this path?
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 4237e07..21104b6 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -317,7 +317,8 @@ int clockevents_program_event(struct
clock_event_device *dev, ktime_t expires,
dev->next_event = expires;
- if (clockevent_state_shutdown(dev))
+ if (clockevent_state_shutdown(dev) ||
+ clockevent_state_oneshot_stopped(dev))
return 0;
>
> Thanks,
>
> tglx
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
next prev parent reply other threads:[~2017-10-24 9:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 4:33 clock event device’s next_event Sodagudi Prasad
2017-10-24 7:23 ` Thomas Gleixner
2017-10-24 7:56 ` Sodagudi Prasad
2017-10-24 8:06 ` [PATCH] Clockevents: Always call clockevents_program_event Prasad Sodagudi
2017-10-24 8:37 ` Thomas Gleixner
2017-10-24 9:21 ` Sodagudi Prasad [this message]
2017-10-24 10:13 ` Thomas Gleixner
2017-10-26 18:37 ` [PATCH] clockevents: Update clockevents device next_event Prasad Sodagudi
2017-11-01 17:25 ` [tip:timers/core] clockevents: Update clockevents device next_event on stop tip-bot for Prasad Sodagudi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d5f08a2df403acaabf8fbe5a79e33806@codeaurora.org \
--to=psodagud@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.