From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 1 May 2015 16:44:28 +0200 From: Gilles Chanteperdrix Message-ID: <20150501144428.GI1993@hermes.click-hack.org> References: <20150430183147.GZ1993@hermes.click-hack.org> <20150430201409.GA1993@hermes.click-hack.org> <20150430212151.GD24389@csclub.uwaterloo.ca> <20150430212749.GB1993@hermes.click-hack.org> <20150501134547.GF24389@csclub.uwaterloo.ca> <20150501135651.GE1993@hermes.click-hack.org> <20150501143631.GH24389@csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150501143631.GH24389@csclub.uwaterloo.ca> Subject: Re: [Xenomai] Ipipe-core patched kernel fails to start when certain platform drivers are enabled List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lennart Sorensen Cc: xenomai@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.