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

[J. William Campbell]

On 5/27/2011 12:28 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4DDEFDBC.7050403 at comcast.net>  you wrote:
>> I really STRONGLY disagree with this statement. If you actually needed
>> 64 bit variables, fine use them. But as I have already shown, you do not
>> need them in general.  We are computing a 32 bit result. There is some
>> entropy argument that says you shouldn't need 64 bits to do so. Another
>> way to look at it is that converting the top 32 bit word and the bottom
>> 32 bit word to ms separately can be easier than doing them both together
>> at once.  However, as we will see below, I do agree we need two 32 bit
>> words to make this process go smoothly. I just don't agree that they
>> should/will constitute a 64 bit binary word. See below.
> And I disagree with this.
>
Hi Wolfgang,
     OK, I hear you.
>> Yes, that is the problem. I have come to the view that  two 32 bit words
>> are the best approach. Note that the lsb may actually not fill the full
>> 32 bits. The top 32 bits are the rollover count and the bottom 32 bits
>> are the current counter. If the counter is a full 32 bits, so much the
>> better. Again, one could put them together inside the interrupt routine
>> , but it is easier to check for a changed value if you don't do this.
> It's even easier if you use a single 64 bit variable, because then you
> can simply use ==.
>

     In general, no you can't, or at least you probably don't want to. . 
If you are reading a 64 bit performance counter, it is quite likely that 
you cannot read it twice without the "clock" having "ticked". If the CPU 
executes 1 instruction (or fewer(if an SPR/memory reference  is 
involved?) per performance counter tick, which is the goal of the 
performance counter, == is an infinite loop!!!! A similar condition 
exists if you are combining a software counter with a fairly fast 
hardware counter. It might require flipping the hardware counter (if it 
is a down counter) and a 64 bit multiply add, which must be done in 
software/a subroutine if the cpu has no 64 by 64 multiply. By the time 
that is done, the timer LSB may have ticked. Consider the m68K case.
>> Otherwise, you have to check both words. It also makes the isr faster.
> Drop any thoughts about "make FOO faster" for now, please.  Especially
> at this stage it is much more important to have a simple and clean
> design.  If split in two variables, even a simple read access will
> turn into code like
>
> 	do {
> 		upper  = timebase_upper;
> 		lower  = timebase_lower;
> 	} while (upper != timebase_upper);
>
> This is not exactly as simple as you claimed.

     True, but if you look at a lot of 64 bit performance counters, that 
is EXACTLY what the handbook book recommends on how to read them. There 
is no atomic way to read them both at once, and reading one half doesn't 
freeze the other half. This code is also required if timebase_upper is 
altered in the interrupt routine.  YMMV, but in a lot, dare I say most, 
cases this is required anyway.  And while the code is more complex than 
a simple assignment statement, it is not very complex.

Best Regards,
Bill Campbell

> Best regards,
>
> Wolfgang Denk
>