There's a lot of places where expiration and running time are
open coded. Allow for those places to be simplified by adding
a stopwatch construct. The stopwatch can have an expiration or
just be used to accumulate time.
BUG=None
TEST=Built and verified API works as expected by using implementation.
Change-Id: Ibd636542b16d8554f1ff4512319a53dce81c97e5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bc623a1b36eb08c5877591c4509cd61131c62617
Original-Change-Id: I53604900fea7d46beeccc17f1dc7900d5f28518b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219492
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8815
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Otherwise there's no good way to create an absolute timer structure without
fiddling with its internal structure or assuming a zero initialized structure
has a value of zero.
Old-Change-Id: Iffe3b6b25ed7963fcfb66f749c531ea445ea4aeb
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65301
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit e2e5c1ef3bb2df95fdf0e33cb2d975a990d07a4a)
exynos: Simplify the monotonic timer implementation.
The previous implementation was overly complicated, and when used in the
timestamp implementation produced some weird and broken results.
Old-Change-Id: I3048028ddea0657b01b0c94f312764b38d1397e4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65302
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 6a3fde9a5b80cdac76d79c65d20d7dd1f1d9e557)
Squashed two closely related commits.
Change-Id: Ifc32d773f4f93d34275a81781001d080357fe8ef
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6406
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The current way to get a simple mono_time difference is:
1. Declare a rela_time struct
2. Assign it the value of mono_time_diff(t1, t2)
3. Get microseconds from it using rela_time_in_microseconds().
This patch adds a simpler method. Now one only needs to call
mono_time_diff_microseconds(t1, t2) to obtain the same value which
is produced from the above three steps.
Change-Id: Ibfc9cd211e48e8e60a0a7703bff09cee3250e88b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3190
Tested-by: build bot (Jenkins)
A timer queue provides the mechanism for calling functions
in the future by way of a callback. It utilizes the MONOTONIC_TIMER
to track time through the boot. The implementation is a min-heap
for keeping track of the next-to-expire callback.
Change-Id: Ia56bab8444cd6177b051752342f53b53d5f6afc1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3158
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The notion of a monotonic timer is introduced. Along with it
are helper functions and other types for comparing times. This
is just the framework where it is the responsibility of the
chipset/board to provide the implementation of timer_monotonic_get().
The reason structs are used instead of native types is to allow
for future changes to the data structure without chaning all the
call sites.
Change-Id: Ie56b9ab9dedb0da69dea86ef87ca744004eb1ae3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3152
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Aaron Durbin