Re: [Xenomai] Ipipe-core patched kernel fails to start when certain platform drivers are enabled

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Fri, May 01, 2015 at 11:11:53AM -0400, Lennart Sorensen wrote:
> On Fri, May 01, 2015 at 04:30:45PM +0200, Gilles Chanteperdrix wrote:
> > The point is: the cortex A9 global timer runs at half the processor
> > frequency, that is 500 MHz for a 1GHz processor: that gives a much
> > better resolution than a timer with a frequency lower than 10 MHz
> > you get with a cortex A15. So since the cortex A15 is newer than the
> > cortex A9, it could be expected to do better or at least be
> > equivalent, rather than do much worse.
> 
> Did any of the A9 designs allow changing the speed on the fly the way
> the A15 and others do?
> 
> I certainly like the idea of a 500MHz timer.
> 
> > > Now they do have lots of other timers in the chip that can be programmed.
> > > I wonder if that could be used to make something much better.
> > > 
> > > I am pretty sure the omap5432 uses 6.144 MHz just like the am572x was
> > > supposed to (if it wasn't for the errata that makes it 6.147541
> > > MHz instead).
> > 
> > Yes, 5MHZ, 6 MHZ, that is the same bad order of magnitude.
> > 
> > > Looking at the manual for the am572x it looks like the general purpose
> > > timers are only 32 bit and can run at either 32.768 KHz or system clock
> > > (usually 20 MHz).  That's not much help.
> > 
> > Once again: Xenomai extends 32 bits counter to 64 bits in software.
> > So, a 32 bits counter running at 20 MHz is still better than the
> > architected timer running at 6MHz. 6 MHz is so low that by reading
> > twice the counter in less than 166ns (which is really really doable
> > on these processors), you could get twice the same value. On cortex
> > A9, I could read the counter twice in userspace in 22ns, and get
> > different values. On cortex A9, anything lower than 50 MHz would
> > not have been sufficient for user-space.
> 
> Yep, that makes sense.  160 ns is a long time on a 1GHz CPU.
> 
> It looks like one of the clock sources for the timers is
> ./sys_clkin2/abe_dpll_sys_clk_mux/abe_dpll_clk_mux/dpll_abe_ck/dpll_abe_x2_ck/dpll_abe_m2x2_ck/abe_clk/aess_fclk/abe_giclk_div/clk_rate
> which is 361267200 Hz (at least right now it is), so that might actually
> be able to be used to make a nice counter.  All the other sources are
> either external clock input pins, or sysclk1 (20 MHz usually) or sysclk2
> (22.5792 MHz).  The 361267200 is 16 * sysclk2.
> 
> I wonder how to create a clocksource from a general purpose timer.

OMAP3 uses a GP timer as clocksource, and OMAP4 does when running
only one core. So, if these IPs have not changed, the code is there
to be used. Note however that last time I tried changing the GP
timer used on OMAP4, the timer I used would not start, so a write to
a register to start a clock was probably missing, or not writing to
the right register. Since nobody ever uses another GP timer, this
code is largely untested.

-- 
					    Gilles.