Hi Graeme,
On Tue, Aug 16, 2011 at 12:11 AM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Tue, Aug 16, 2011 at 4:30 PM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Mon, Aug 15, 2011 at 6:16 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon
On Tue, Aug 16, 2011 at 10:42 AM, Simon Glass sjg@chromium.org wrote:
These functions provide access to the high resolution microsecond timer and tidy up a global variable in the code.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Remove future time function
Really?
Hmm, perhaps not. But at least it isn't called :-) I will tidy this up when I get a response from the ARM maintainer.
While you are on the line, what is the plan with a general microsecond timer in U-Boot? Is this on the cards, or is it still considered 'code bloat'?
It is still on the cards - I haven't had a chance to have a really in-depth look at the Linux framework, but from what I can see, it is way beyond excessive for U-Boot's requirements.
Yes.
But, in saying that there are a few things I would like to 'borrow' from the Linux architecture:
- nanosecond raw time-base - It is not that difficult to get a
sub-microsecond raw counter on silicon nowdays. Any decently fast CPU with an internal incrementing counter will give you that. I think being consistent with Linux and using nanosecond as the raw time base is a good idea
Fair enough. There is the question of what U-Boot might be doing with a nanosecond timer (even the microsecond timer seemed to attract a great deal of skepticism) but I suppose it just emphasizes the wide range of hardware that U-Boot runs on.
- 'registering' of low-level timer hooks - I know of at least one board
(my eNET) which provides a microsecond clock-source at bootup, but also has a much higher accuracy FPGA microsecond timer available only after the FPGA is loaded. I would like the ability to switch clock sources and automatically handle bumpless transfer from one source to another
Sounds like something the board could implement if needed. Very fancy - would be interesting to see this working when a routine which later reprograms the FPGA needs a time delay... The U-Boot way seems to be to replace a generic function rather than having a real timer driver with function pointers.
I am contemplating another crack at the bootstage patch (microsecond boot timing) and it would help to know the plan on that front.
Yes, I want this as well - I will have to respin the new timer framework proposal. My initial cleanup work which got rid of reset_timer() and removed the base offset from read_timer() is in, so thats one small step for U-Boot, one giant leap...(Oh please, stop me now!)
Yes it was a giant leap for U-Bootkind.
I'll send out another proposal 'soon'(tm)
I think the biggest sticking point right now is the argument over the size of the timer counter - A lot of people seem to balk at the idea of forcing 64-bit throughout (and at the millisecond level, I tend to agree)
My use for microsecond timing is for booting, which doesn't last for more than a few seconds. I understand the idea of using it for time delays, but again I don't see that 64-bits is actually needed (2000 seconds is a long time) . For nanosecond it is a different story though. So if you go that way it will have to be 64-bit.
Regards, Simon
Regards,
Graeme