Petri, What about this fix? It's similar to to CPU API.
On 11.09.15 13:04, Ivan Khoronzhuk wrote:
It's better to describe by example: cur = 15; start = 15; diff = 2; while (odp_time_cycles_diff(start, cur) < diff) { cur = odp_time_cycles(); } This example has to work. It's possible only when t2 - t1 = 0 if t2 = t1. The validation test on it will be added later. Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org> --- platform/linux-generic/odp_time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform/linux-generic/odp_time.c b/platform/linux-generic/odp_time.c index a08833d..a007d69 100644 --- a/platform/linux-generic/odp_time.c +++ b/platform/linux-generic/odp_time.c @@ -14,7 +14,7 @@ uint64_t odp_time_diff_cycles(uint64_t t1, uint64_t t2) { - if (odp_likely(t2 > t1)) + if (odp_likely(t2 >= t1)) return t2 - t1; return t2 + (UINT64_MAX - t1);
But I have additional proposition. Maybe I'm wrong, but one cycle can be lost here (equal as in CPU api, I'm ready to fix it also) For instance: start = MAX - 2; cur = 1 res = MAX - MAX + 2 + 1 = 3; It's correct. But in real it will be: (MAX - 2) -> 1 cycle (MAX - 1) -> 2 cycle MAX -> 3 cycle 0 -> 4 cycle 1 The function returns 3 cycles difference, but due to 0, physically, timer counts 4 cycles. Not sure, but I should send +1 patch that corrects it to: return t2 + (UINT64_MAX - t1) + 1; due to counter in continuous mode is reset to 0, then continues counting. Can we apply this on cycle counter? (then I need correct CPU API implementation also) Is it reseted to zero or wraps to 1 for all arches? -- Regards, Ivan Khoronzhuk _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp