[U-Boot] [RESEND PATCH v3 1/4] Tegra2: Add microsecond timer function

[Graeme Russ]

Hi Simon,

On Tue, Aug 16, 2011 at 4:30 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Graeme,
>
> On Mon, Aug 15, 2011 at 6:16 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>> Hi Simon
>>
>> On Tue, Aug 16, 2011 at 10:42 AM, Simon Glass <sjg at 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 at 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