Hi Simon, On Tue, Aug 16, 2011 at 4:30 PM, Simon Glass <s...@chromium.org> wrote: > Hi Graeme, > > On Mon, Aug 15, 2011 at 6:16 PM, Graeme Russ <graeme.r...@gmail.com> wrote: >> Hi Simon >> >> On Tue, Aug 16, 2011 at 10:42 AM, Simon Glass <s...@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 <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
