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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
