[U-Boot] [RESEND PATCH v2 2/5] Tegra2: Add microsecond timer functions

[Graeme Russ <graeme.russ@gmail.com>]

Hi Simon,

On 10/07/11 16:14, Simon Glass wrote:
> Hi Graeme,

[snip]

> 
>     timer_get_us needs to be u64 (unsigned long long). Also, the new timer API
>     will define this as time_now_us, would be great if you could use this
>     naming convention now to save me doing a mass of replaces later
> 
> 
> Yes will do. 

Thanks

>     > +
>     > +unsigned long timer_get_future_us(u32 delay)
>     > +{
>     > +     return timer_get_us() + delay;
>     > +}
> 
>     C'mon - We've been here before - This is timer API stuff. Where are you
>     going to use this? Why can't the proposed API be used instead?
> 
>     I know you don't like the 'time since' implementation, but this has been
>     discussed to death and it appears to me that the majority decision was to
>     go that route rather than the 'future time' route. It is a completely
>     pointless exercise and a complete waste of my time to re-write the timer
>     API just to have someone that doesn't like a particular aspect go off and
>     write a one-off function.
> 
> 
> Well this code pre-dates this and I haven't revised it. I will take another
> look and sort this out. In fact from memory the return value isn't even used! 

Ah, OK then - Sorry for the tone, I didn't realise the history of this patch

[snip]

> 
>     'likely' meaning it may or may not - no guarantee though. The new timer API
>     is designed specifically designed to resolve this - 'At least x ms/us have
>     passed' or 'at most x ms/us have passed'. No more 'x ms/us _might_ have
>     passed'
> 
> 
> Yes, watch this space.

Maybe you could grab the timer functions for the new API from the patch
series I posted recently and create the micro-second equivalents in Tegra2.
I can the move them into common code later with no other code changes necessary

> 
> BTW I have come across another problem where initialization must be done
> which has long delays in it (LCD display power-up sequence). It's starting
> to feel like we should have a central place for registering a timer which
> calls back when a time has expired. That way we can continue with other
> tings while we wait for the time to elapse. Something like:
> 
> 
> /* Move to the next state */
> static int next_state(void *my_data)
> {
> /* do some things, and then if you want to be called again... */
> timer_register(timer_now_ms() + 40, next_state, my_data)
> }
> 
> void start_lcd_init()
> {
> // do first thing
> ...
> // set a timer to do the next thing later
> timer_register(timer_now_ms() + 200, next_state, my_data)
> }
> 
> ...
> 
> Every now and then code (or a timer wait function) can call
> 
> timer_check()
> 
> which will call any expired timers on the list and remove them. This allows
> LCD init to continue while downloading the kernel, for example.
> 
> 
> I haven't thought too hard about this, but apart from LCD I know that USB
> has some big delays. Obviously we can't make U-Boot multi-threaded but we
> can perhaps do something simple like the above. What do you think?

Well, this is a little beyond the scope of a simple boot loader ;) And
unless we start getting real fancy with task schedulers etc, the callback
will most likely be done in the context of an IRQ handler.

I do agree, however, that in some circumstances, it would be useful to be
able to 'background' some tasks such as doing a flash erase in the
background while calculating the environment CRC or letting a device
initialising itself while U-Boot moves on through the boot sequence. But
this can be done without callbacks anyway in the board init sequence:

	...low level init stuff...,
	start_lcd_init,
	...other stuff...,
	wait_lcd_init_complete,
	...more stuff needing LCD output...,

> Also given that your timer API stuff seems to have a good reception and
> people are very happy, is there any impediment to getting this in sooner
> rather than later?
> 

I hope so, but I'm really wanting feedback from Wolfgang and I fear the
merge window will close before it's ready :(

Regards,

Graeme