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.
But, in saying that there are a few things I would like to 'borrow' from the Linux architecture:
1) 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
2) '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
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!)
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)
Regards,
Graeme