While testing the real-time ability of my imx287 I came across some problems.
First I created a latency histogram with cyclictest. The histogram I got looked like a comb.
Between 100 and 640us there were vertical lines with a distance of 32us to each other.
Then I tried to use ftrace, to get some more latency values.
I got this result:
function_graph: duration 0.000 or 10000.00us
irqsoff: time 0us or 200000us
sched_event: timestamp xxx0000
The last interesting thing I found out was the result of a simple c-program.
I took two timestamps and calculated the difference:
struct timeval start, stop, diff; gettimeofday(&start,NULL); gettimeofday(&stop, NULL); timersub(&stop, &start, &diff); clock_gettime(CLOCK_MONOTONIC, &start); clock_gettime(CLOCK_MONOTONIC, &stop); diff = time_diff(start, stop);
I run this program on different machines with this result:
TX28(i.mx287): mostly 0ns, sometimes 32250ns
It looks like a 32us resolution to me.
The TX28-Starterkit is simular to the imx28evk.
I use the mainline kernel 3.3 with the tx28 patch.
It seems the patch doesn't change clock/timer code.
Is this phenomenon right for the i.mx28 or is there a bug in the kernel (port)?
Has anybody else recognised this problem using i.mx28?
Maybe someone could try this on the imx28evk.
Where could be the problem?
Original Attachment has been moved to: trace_timer_output.txt.zip