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

[Simon Glass]

Hi Graeme,

On Tue, Aug 16, 2011 at 12:11 AM, Graeme Russ <graeme.russ at gmail.com> wrote:
> 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.

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
>