On Fri, May 20, 2011 at 11:48 AM, Simon Glass <s...@chromium.org> wrote:
> On Thu, May 19, 2011 at 1:36 AM, Detlev Zundel <d...@denx.de> wrote:
>> Hi Simon,
>>
>> [...]
>>
>>> I believe I have covered this ground very thoroughly and would like
>>> advice please on what to do next. The options I can see are:
>>
>> As Graeme points out, you got enough positive feedback that I encourage
>> you to continue and address the comments.
>
> OK, it would be nice to have a note from Wolfgang since without his OK
> it won't make it in, right?
>
>>
>>> - change the code to use a fallback when a microsecond timer is not
>>> available
>>
>> Excuse me for not diving into that too deep, but from my top-level
>> overview, it would seem like a good idea that if an architecture _has_ a
>> microsecond timer, it could use generic code to massage that into the
>> HZ=1000 API that we currently use with the addition of offering the
>> extended precision. Your code then would need such a fallback and could
>> work with the best precision offered by the architecture. New
>> architectures with microsecond timers would need to only implement the
>> new microsecond timer infrastructure and be done with it.
>
> Yes I suggested that a few emails ago but didn't get a response.
Is it just me or are get_timer(), set_timer() and reset_timer() in U-Boot
a little bit braindead? get_timer() returns microseconds since last
reset_timer() plus an optional offset, set_timer() allows the current
microseconds to an arbitrary value and reset_timer() is essentially
set_timer(0)
A random look at at91 is interesting though:
void set_timer(ulong t)
{
gd->tbl = t;
}
void reset_timer(void)
{
reset_timer_masked();
}
void reset_timer_masked(void)
{
/* reset time */
at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
gd->lastinc = readl(&tc->tc[0].cv) & 0x0000ffff;
gd->tbl = 0;
}
So set_timer(0) != reset_timer() in a rather big way!
Now some arches (imx for example) do not implement set_timer() which makes
using it a 'Bad Idea'(tm)
And why do we need reset_timer() - Anything that uses it can just do:
ulong start_time = get_timer(0);
while (get_timer(start_time) < SOME_TIMEOUT) {
...do stuff..
}
NOTE: May not be the 'safest' way to do that - I recall there being a LOT
of discussion about this with regards to wrap-around and safe ways of
doing the above
Anyway, my point is, if the timer API wasa fixed, all the boot logging API
needs to do is call get_timer() and your done - instant millisecond
timestamp - No fallbacks - Each arch just needs to implement get_timer()
correctly
>>> - integrate with boot progress
>>
>> The current boot progress to me seems pretty ugly and could do with a
>> make-over. So if it is possible to merge those two logical functions,
>> we would have a win-win situation.
Sounds like a two-patch approach - Fix up boot progress and then slap
logging on top
>
> OK fair enough. I will do this if there is agreement that this type of
> boot timing is worth having.
I could have a look at this if you like Simon
Regards,
Graeme
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
