]> asedeno.scripts.mit.edu Git - linux.git/commit
clocksource/drivers/dw_apb_timer_of: Implement ARM delay timer
authorJisheng Zhang <jszhang@marvell.com>
Thu, 5 Nov 2015 02:32:06 +0000 (10:32 +0800)
committerDaniel Lezcano <daniel.lezcano@linaro.org>
Tue, 15 Dec 2015 08:42:00 +0000 (09:42 +0100)
commit9115df89d12c2cf6db080a7ee57cd076f8416e4a
treecfd86473d7034ace8133978e0f747d201b7125eb
parent0901f18432db704b7622c969a09fba9846e4cfcd
clocksource/drivers/dw_apb_timer_of: Implement ARM delay timer

Implement an ARM delay timer to be used for udelay(). This allows us to
skip the delay loop calibration at boot on Marvell BG2, BG2Q, BG2CD
platforms. And after this patch, udelay() will be unaffected by CPU
frequency changes.

Note: Although in case there are several possible delay timers, we may
not select the "best" delay timer. Take one Marvell Berlin platform for
example: we have arch timer and dw-apb timer. The arch timer freq is
25MHZ while the dw-apb timer freq is 100MHZ, current selection would
choose the dw-apb timer. But the dw apb timer is on the APB bus while
arch timer sits in CPU, the cost of accessing the apb timer is higher
than the arch timer. We could introduce "rating" concept to delay
timer, but this approach "brings a lot of complexity and workarounds
in the code for a small benefit" as pointed out by Daniel.

Later, Arnd pointed out "However, we could argue that this actually
doesn't matter at all, because the entire point of the ndelay()/
udelay()/mdelay() functions is to waste CPU cycles doing not much at
all, so we can just as well waste them reading the timer register
than spinning on the CPU reading the arch timer more often.", so we
just simply register the dw apb base delay timer.

Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
drivers/clocksource/dw_apb_timer_of.c