Hi Graeme, On Tue, Aug 16, 2011 at 12:11 AM, Graeme Russ <[email protected]> wrote: > Hi Simon, > > On Tue, Aug 16, 2011 at 4:30 PM, Simon Glass <[email protected]> wrote: >> Hi Graeme, >> >> On Mon, Aug 15, 2011 at 6:16 PM, Graeme Russ <[email protected]> wrote: >>> Hi Simon >>> >>> On Tue, Aug 16, 2011 at 10:42 AM, Simon Glass <[email protected]> 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 <[email protected]> >>>> --- >>>> 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: > > 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 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. > > 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 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 > _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
