[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

[Graeme Russ]

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
>> <jwilliamcampbell at comcast.net>  wrote:
>>> On 5/26/2011 9:33 PM, Graeme Russ wrote:
>>>> Hi Bill,
>>>>
>>> <snip>
>> [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