target/arm: Prepare generic timer for per-platform CNTFRQ
commit96eec6b2b389215f43d7f07e823cb196f9185052
authorAndrew Jeffery <andrew@aj.id.au>
Fri, 20 Dec 2019 14:02:59 +0000 (20 14:02 +0000)
committerPeter Maydell <peter.maydell@linaro.org>
Fri, 20 Dec 2019 14:02:59 +0000 (20 14:02 +0000)
tree9355eacda60d6f845cfed75b7070e4e67600382b
parent7def87548272f6f3831c7ae5ba713c5ccbd5d547
target/arm: Prepare generic timer for per-platform CNTFRQ

The ASPEED AST2600 clocks the generic timer at the rate of HPLL. On
recent firmwares this is at 1125MHz, which is considerably quicker than
the assumed 62.5MHz of the current generic timer implementation. The
delta between the value as read from CNTFRQ and the true rate of the
underlying QEMUTimer leads to sticky behaviour in AST2600 guests.

Add a feature-gated property exposing CNTFRQ for ARM CPUs providing the
generic timer. This allows platforms to configure CNTFRQ (and the
associated QEMUTimer) to the appropriate frequency prior to starting the
guest.

As the platform can now determine the rate of CNTFRQ we're exposed to
limitations of QEMUTimer that didn't previously materialise: In the
course of emulation we need to arbitrarily and accurately convert
between guest ticks and time, but we're constrained by QEMUTimer's use
of an integer scaling factor. The effect is QEMUTimer cannot exactly
capture the period of frequencies that do not cleanly divide
NANOSECONDS_PER_SECOND for scaling ticks to time. As such, provide an
equally inaccurate scaling factor for scaling time to ticks so at least
a self-consistent inverse relationship holds.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: a22db9325f96e39f76e3c2baddcb712149f46bf2.1576215453.git-series.andrew@aj.id.au
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
target/arm/cpu.c
target/arm/helper.c