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 <[email protected]>
---
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
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
