mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-24 13:13:57 +08:00
24e1df664f
When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> |
||
|---|---|---|
| .. | ||
| Makefile | ||
| malta-amon.c | ||
| malta-display.c | ||
| malta-dt.c | ||
| malta-dtshim.c | ||
| malta-init.c | ||
| malta-int.c | ||
| malta-memory.c | ||
| malta-platform.c | ||
| malta-pm.c | ||
| malta-reset.c | ||
| malta-setup.c | ||
| malta-time.c | ||
| Platform | ||