Hi Simon, On 31.08.22 19:44, Simon Glass wrote:
<snip>
It is needed because bootstage is called before driver model is ready. In fact it can be used to time driver model things.I see, makes sense. This brings up my next questions though, why isn't CONFIG_TIMER_EARLY enough in this case? AFAICT it's targeted exactly for this early (pre DM) bootstage. From drivers/timer/Kconfig: config TIMER_EARLY bool "Allow timer to be used early in U-Boot" depends on TIMER # initr_bootstage() requires a timer and is called before initr_dm() # so only the early timer is available default y if X86 && BOOTSTAGE help In some cases the timer must be accessible before driver model is active. Examples include when using CONFIG_TRACE to trace U-Boot's execution before driver model is set up. Enable this option to use an early timer. These functions must be supported by your timer driver: timer_early_get_count() and timer_early_get_rate(). So again, do we really need timer_get_boot_us() or isn't it enough to select TIMER_EARLY when BOOTSTAGE is enabled?The timer is for milliseconds but for bootstage we need microseconds. Perhaps the ultimate solution here is to support a microsecond timer through the TIMER api and use the TIMER_EARLY thing to provide timer_get_boot_us(), perhaps renaming to timer_early_get_us() ?
Yes, sounds like a plan. We should consolidate these implementations. Let me think about it and perhaps do some basic implementations and tests for a while. Thanks, Stefan
