Lopes, Alexandre wrote:
> @Lowell: Like Gilles mentioned, there are several timers in the
> Cortex A9. At address PERIPH_BASE_ADDR + 0x200 you have the global timer
> registers and at PERIPH_BASE_ADDR + 0x600 you have the private timer and
> watchdog timer registers (on a per core basis). On the Altera socfpga
> systems
> the base address is, in this case, 0xfffec000. Unfortunately Altera
> didn’t
> register the global timer, at least not on the upstream Kernels.

The Linux mainline code refuses to start the global timer with old
revisions of the cortex A9 core which global timer is not exactly the same
as with newer revisions (there is a difference in what condition triggers
the timer interrupt which make it possible for the old revisions timer to
not receive an interrupt if the programmed delay is too short, whereas it
can not happen with newer versions). So, the SOCs in mainline based on
such old versions do not even bother to declare the global timer registers
in the DT.

The I-pipe clock source does not care about the timer, it only needs the
free running counter, and actually has been using it long before the arm
global timer driver was merged. This free running counter works fine in
both cases (and has an unparalleled resolution and latency, which makes it
interesting for emulating a tsc), so, I have patched up the global timer
code to keep the clocksource even with old revisions and only skip the
clockevent device registration, so that we can add the global timer
register declarations in DT and have the clocksource without the timer.
But this is a hack, really, it means that we have to add the DT data in
the I-pipe patch, and this is going to byte us when mainline decides to
restructure the global timer support.

The proper fix is to submit a patch to mainline that agrees both parties,
namely implement a different clockevent callback for the old revisions
that test for short delays and return -ETIME to let the clockevent system
handle it. Then submit the DT data to make the ARM global timer available
for the SOCs we need, and move all this out of the I-pipe patch.


-- 
                    Gilles.


_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai

Reply via email to