[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170804093805.z5y2o6t6wp34ywln@hirez.programming.kicks-ass.net>
Date: Fri, 4 Aug 2017 11:38:05 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Viresh Kumar <viresh.kumar@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
"john.stultz@...aro.org" <john.stultz@...aro.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-snps-arc@...ts.infradead.org"
<linux-snps-arc@...ts.infradead.org>,
Alexey Brodkin <Alexey.Brodkin@...opsys.com>
Subject: Re: update timer frequencies
On Fri, Aug 04, 2017 at 12:28:43PM +0530, Vineet Gupta wrote:
> The hardware is being changed and I had a couple of questions to help do it right:
Awesome ;-)
> 2. I'm not sure if the timer generating interrupts (periodic or oneshot)
> needs to be fed invariant fixed clk or dynamic core clk. Naively it should
> follow the core - but what happens to scheduled timers (say TCP timeouts):
> if this clk changes - they need to be canceled/updated. If it doesn't then
> the notion of timing is broken ? I'm likely not thinking this through
> correctly.
Please keep the timers on the very same clock as your clocksource.
clockevent and clocksource having different (and possibly) drifting
timelines is painful.
Having them on the same clock makes everything so much easier, since you
_know_ what time it is when they fire and won't have to recompute and
possibly rearm the timer.
Powered by blists - more mailing lists