[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d5f08a2df403acaabf8fbe5a79e33806@codeaurora.org>
Date: Tue, 24 Oct 2017 02:21:26 -0700
From: Sodagudi Prasad <psodagud@...eaurora.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: mingo@...nel.org, viresh.kumar@...aro.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Clockevents: Always call clockevents_program_event
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
Powered by blists - more mailing lists