This patch adds clock source and clock event for the timer found on the Mediatek SoCs. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Tested-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
This is currently out of order. Sort it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Currently the comments of several APIs (eg: dm_init_and_scan()) say: @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC flag. If false bind all drivers. The 'Pre-Relocation Support' chapter in doc/driver-model/README.txt documents the same that both device tree properties and driver flag are supported. However the implementation only checks these special device tree properties without checking the driver flag at all. This updates lists_bind_fdt() to consider both scenarios. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Squashed in http://patchwork.ozlabs.org/patch/996473/ : Signed-off-by: Simon Glass <sjg@chromium.org>
So far the TSC timer driver supports trying hardware calibration first and using device tree as last resort for its running frequency as the normal timer. However when it is used as the early timer, it only supports hardware calibration and if it fails, the driver just panics. This introduces a new config option to specify the early timer frequency in MHz and it should be equal to the value described in the device tree. Without this patch, the travis-ci testing on QEMU x86_64 target fails each time after it finishes the 'bootefi selftest' as the test.py see an error was emitted on the console like this: TSC frequency is ZERO resetting ... ### ERROR ### Please RESET the board ### It's strange that this error is consistently seen on the travis-ci machine, but only occasionally seen on my local machine (maybe 1 out of 10). Since QEMU x86_64 target enables BOOTSTAGE support which uses early timer, with this fix it should work without any failure. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
In initr_bootstage() we call bootstage_mark_name() which ends up calling timer_get_us(). This call happens before initr_dm(), which inits driver model. On x86 we set gd->timer to NULL in the transition from board_init_f() to board_init_r(). See board_init_f_r() for this assignment. So U-Boot knows there is no timer available in the period immediately after relocation. On x86 the timer_get_us() call is implemented as calls to get_ticks() and get_tbclk(). Both of these call dm_timer_init() to set up the timer, if gd->timer is NULL and the early timer is not available. However dm_timer_init() cannot succeed before initr_dm() is called. So it seems that on x86 if we want to use CONFIG_BOOTSTAGE we must enable CONFIG_TIMER_EARLY. Update the Kconfig to handle this. Note: On most architectures we can rely on the pre-relocation memory still being available, so that gd->timer pointers to a valid timer device and everything works correctly. Admittedly this is not strictly correct since the timer device is set up by pre-relocation U-Boot, but normally this is fine. On x86 the 'CAR' (cache-as-RAM) memory used by pre-relocation U-Boot disappears in board_init_f_r() and any attempt to access it will hang. This is the reason why we must mark the timer as invalid when we get to board_init_f_r(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a timer driver for the MPC83xx architecture. Signed-off-by: Mario Six <mario.six@gdsys.cc>
Makefile entries should be sorted. Signed-off-by: Mario Six <mario.six@gdsys.cc>
timer_pre_probe() tries to populate the clock rate from DT. omap timer driver tries to overwrite this value irrespective of the value populated fro DT. So update this value only when DT doesn't populate the clock rate. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In order to handle counter overflows use 64 bit values for counter. Also load the initial value during probe. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>