[U-Boot] [RFC] Review of U-Boot timer API

[Wolfgang Denk]

Dear "J. William Campbell",

In message <4DDBFFF5.1020601 at comcast.net> you wrote:
>
> First, it seems that the get_timer interface is expected to work 
> properly only after relocation and only when bss is available. I say 
> this because the PPC version uses an (initialized) variable, timestamp, 
> to hold the time. If that is the case, there is no need to hold the 
> timer static data in gd, as I have been doing up to  now. Am I correct ?

Yes.

>       Second, udelay is expected to be available before  bss is 
> available, very early in the startup process. There a comments to that 
> effect in several places in the code. Therefore, udelay cannot use 
> global or static variables. Is this true?

Yes.

>      And third, udelay is only expected/required to work correctly for 
> "short", like say 10 seconds. I say this based on comments contained in 
> powerpr/lib/time.c. Please ack or nak this as well.

Depending on CPU type and clock, it may be as low as 1 second, or
less. udelay() is based on wait_ticks(), which receives a u32
argument. Assume we have a tick rate of 1 GHz or so, and be prepared
for faster processors.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"IBM uses what I like to call the 'hole-in-the-ground  technique'  to
destroy  the  competition.....  IBM digs a big HOLE in the ground and
covers it with leaves. It then puts a big POT OF GOLD nearby. Then it
gives the call, 'Hey, look at all this gold, get over here fast.'  As
soon  as  the competitor approaches the pot, he falls into the pit"
                                                     - John C. Dvorak