diff options
author | Andre Przywara <andre.przywara@arm.com> | 2016-11-03 00:56:25 +0000 |
---|---|---|
committer | Tom Rini <trini@konsulko.com> | 2016-11-05 07:27:45 -0400 |
commit | 68fd5c136cfdcbe6d96f38d0db29141af953af85 (patch) | |
tree | 530fd51a1ae9381eca5de040906eddee33851a28 /board/qualcomm/dragonboard410c | |
parent | 8add67911d786c5b98fa20179eb4371d18e769ec (diff) | |
download | u-boot-imx-68fd5c136cfdcbe6d96f38d0db29141af953af85.zip u-boot-imx-68fd5c136cfdcbe6d96f38d0db29141af953af85.tar.gz u-boot-imx-68fd5c136cfdcbe6d96f38d0db29141af953af85.tar.bz2 |
armv8: define get_ticks() for the ARMv8 Generic Timer
For 64-bit ARM systems we provide just a timer_read_counter()
implementation and rely on the generic non-uclass get_ticks() function
in lib/time.c to call the former.
However this function is actually not 64-bit safe, as it assumes a
"long" to be 32-bit. Beside the fact that the resulting uint64_t
isn't bigger than "long" on 64-bit architectures and thus combining two
counters makes no sense, we get all kind of weird results when we try
to OR in the high value shifted by _32_ bits.
So let's avoid that function at all and provide a straight forward
get_ticks() implementation for ARMv8, which also is in line with ARMv7.
This fixes occasional immediate time-out expiration issues I see on the
Pine64 board. The root cause of this needs to be investigated, but this
fix looks like the right thing anyway.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Diffstat (limited to 'board/qualcomm/dragonboard410c')
0 files changed, 0 insertions, 0 deletions