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 10:36:31AM -0400, Lennart Sorensen wrote:
> On Fri, May 01, 2015 at 03:56:51PM +0200, Gilles Chanteperdrix wrote:
> > 6MHz is still not a lot (even omap3 did better than that).
> > 
> > And no, a A 56 bits counter running at 6MHz does not wrap in 2794
> > seconds, it wraps in:
> > 
> > (2^56) / 6000000 = 12009599006 s
> > 
> > That is:
> > 12009599006 / (365 * 24 * 3600) = 380 years
> > 
> > So, you are safe, it can be considered to avoid wrapping for a
> > reasonable amount of time.
> > 
> > Which means really, that I do not understand why the frequency is so
> > low.
> 
> I hava a suspicition that the 6.144MHz was chosen because it is what
> S/PDIF requires to run 48Khz audio.  Some it may have something to do
> with multimedia handling.
> 
> And in low power mode they run it from 32.768 KHz * 375 / 2.
> 
> Sure looks like they could have easily made it faster, although making
> it faster wouldn't necesarily make it any more accurate depending on
> how it is implemented.  After all if it is just taking a 20MHz system
> clock input and incrementing from that, then there isn't much point
> running it faster.  If you can run it from the PLL circuit that runs
> the CPU core on the other hand, that would be interesting.  Of course
> that frequency can scale up and down if cpu frequency scaling is
> enabled.

That is what the cortex A9 did, the twd local timers and the global
timer are derived from the cpu clock. That said, the twd are still
available on A15 I guess, so maybe the global timer is also
available?

> 
> > 56 bits at 1 GHz would wrap in two years using the same computation,
> > that clearly would violate ARM specs. But 60 MHz for instance would
> > wrap in 38 years, that would seem reasonable.
> 
> Does the kernel have a bug then:
> 
> [    0.000000] OMAP clockevent source: timer1 at 32786 Hz
> [    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65536000000000ns
> [    0.000000] OMAP clocksource: 32k_counter at 32768 Hz
> [    0.000335] Architected cp15 timer(s) running at 6.14MHz (phys).
> [    0.000370] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 2794592043008ns
> [    0.000376] Switching to timer-based delay loop
> [    0.100554] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=6147)
> 
> I think 2794592043008ns = 2794.592043008s, and I must admit I assumed
> the kernel knew what it was talking about.  It looks like it does not.

I do not know how that is computed. I do not think I did my
calculations wrong. Maybe the kernel does not use the raw value for
sched_clock, but something transformed with some shifts and
multiplies, and it tells you in how much time that transformed
counter wraps.

-- 
					    Gilles.