On Thu, 22 Jan 2015, Olliver Schinagl wrote:Ah, of course, I guess we'd have to use a fixed default, my bad.
From: Olliver Schinagl <oliver@xxxxxxxxxxx>
When using a hrtimer for repeating periodic ticks, hrtimer_forward_now()
is often used. Quite possibly the timer loop is thus probably fully
controlled by hrtimer_forward_now() and we don't really care when the
timer is started. With hrtimer_start() we need to define exactly when a
event has to start. By introducing hrtimer_start_now() we do the same as
what hrtimer_forward_now() does, start as soon as possible and get into
the timer loop.
Signed-off-by: Olliver Schinagl <oliver@xxxxxxxxxxx>What's the mode argument for? How is this supposed to do what you
---
include/linux/hrtimer.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index a036d05..080a5f5 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -353,6 +353,12 @@ static inline void destroy_hrtimer_on_stack(struct hrtimer *timer) { }
/* Basic timer operations: */
extern int hrtimer_start(struct hrtimer *timer, ktime_t tim,
const enum hrtimer_mode mode);
+
+static inline int hrtimer_start_now(struct hrtimer *timer,
+ const enum hrtimer_mode mode)
+{
+ return hrtimer_start(timer, timer->base->get_time(), mode);
+}
want:
hrtimer_start_now(timer, HRTIMER_MODE_REL);
I guess the same could be said for hrtimer_forward_now I suppose. It was just intended as a little helper, with emphasis on helper.
Aside of that, what's wrong with doing:
static const ktime_t ktime_zero = { .tv64 = 0 };
hrtimer_start(timer, ktime_zero, HRTIMER_MODE_REL);
Thanks,
tglx