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 laterYes 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