From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Sat, 28 May 2011 10:32:27 +1000 Subject: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details In-Reply-To: <4DDFC820.80302@comcast.net> References: <4DDE5548.3020906@gmail.com> <4DDE8639.3090909@comcast.net> <4DDEFDBC.7050403@comcast.net> <4DDF2072.5090802@comcast.net> <4DDF45CF.5080401@comcast.net> <4DDFC820.80302@comcast.net> Message-ID: <4DE0429B.5070409@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 28/05/11 01:49, J. William Campbell wrote: > On 5/26/2011 11:54 PM, Graeme Russ wrote: >> On Fri, May 27, 2011 at 4:33 PM, J. William Campbell >> wrote: >>> On 5/26/2011 9:33 PM, Graeme Russ wrote: >>>> Hi Bill, >>>> >>> >> [massive snip] [another big snip] >>>>>> I just realised - the ISR _does not need to call the sync_timebase at >>>>>> all_ >>>>>> The ISR only needs to call get_ticks(), so it will be fast anyway >>>>> The problem is that the way we previously detected wrapping does not work >>>>> if >>>>> the interrupt rate is == to the counter wrap time, which it essentially >>>>> always is. If get_ticks is trying to update the wrap count when an >>>>> interrupt >>>> Is it, always, on every platform? >>> Yes, pretty much. You get a terminal count/counter underflow interrupt and >>> that is it. >> Not on sc520 - The micro/millisecond counter cannot be used to driver an >> interrupt - you need to setup a seperate timer. I think the x86 internal >> performance counters are the same > What is true, as you have stated, is that the micro/millisecond counter on > the sc520 does not interrupt at all. Nor do the x86 performance counters. > The x86 performance counters are a non-problem because they are 64 bits > long. We don't need interrupts for them. Now, if you choose to use the > sc520 micro/millisecond counter, then you need another source of > interrupts. Due to the fact that reading the sc520 counter resets it, we > must accumulate the elapsed time in software. That means the interrupt > routine must do a bit more work, but it also allows reading the counters in I had planned to do _all_ of that in get_ticks(), so all the complicated code is in one spot which is called by sync_ms_timer() which is in turned called by either timer_isr() or get_timer() Of course the problem we have now identified is reentrancy - Looking forward to seeing your solution Regards, Graeme