On 02.09.15 12:42, Nicolas Morey-Chaisemartin wrote:
On 08/26/2015 05:47 PM, Ivan Khoronzhuk wrote:
On 26.08.15 18:22, Stuart Haslam wrote:
On Wed, Aug 26, 2015 at 06:11:13PM +0300, Ivan Khoronzhuk wrote:
It's needed because time resolution can be a little more than 1ns
and in this case odp_schedule_wait_time(1) returns 0, and test
generates warn w/o reason. So increase scheduler wait time check
from 1ns to 100ns.
It's hard to imagine time source with resolution more than 100ns,
so every implementation can return positive value from
odp_schedule_wait_time(). In case if resolution is more than 100ns
it's normal to warn about it at validation stage,
The wait parameter is documented as the *minimum* time to wait for an
event so the existing check looks OK to me. Implementations with a lower
resolution should round up.
It defined as "minimum" time to wait for odp_schedule and others,
for odp_schedule_wait_time() it's not defined as minimum, it's simple
convert function.
Not shure, but any of the functions I saw in linux-generic doesn't round ticks
up.
It seems that it was decided to allow application to do it, if needed.
But if so, we have much more to change ).
In case if you are right, linux-generic implementation should be corrected,
as it doesn't round it up.
Thanks.
I ran into this issue with our port as our clock are < 1GHz.
So 1 ns is < 1 cycle which tends to break a few things on the linux generic
port.
I fix this particular issue like this:
uint64_t odp_schedule_wait_time(uint64_t ns)
{
uint64_t cycle = odp_time_ns_to_cycles(ns);
if(cycle == 0)
cycle = 1;
return cycle;
}
Not the nicest patch but it works.
The test should probably be changed to if(ns && !cycle) so ns=0 returns 0;
Yes.
As said Stuart it may cause collisions with ODP_SCHED_WAIT (0)
and ODP_SCHED_NO_WAIT (1)
I will correct it a little later.
--
Regards,
Ivan Khoronzhuk
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
