35ca8c97ce
This qemu device is REALLY slow in icount mode. When I run it outside of icount and watch the simulator advance the clock device in real time, it looks to me like it expects the counter to be running at ~125 MHz. But it's set to a 12 MHz clock rate in its config, and trying to use a 1000 Hz tick rate. At those settings (and with the shift=3 argument to icount), I'm measuring about 10k cycles to handle a minimal timer interrupt. But if you do the math, that comes to 12k cycles per tick. The interrupt takes as long as a tick! That would never work, except for the fact that the timer driver on this device cheats and doesn't try to align to ticks (basically ignoring all the lost time). And even that breaks on the scheduler_api test (which does both tick and cycle math and tries to compare them) when it's fixed to properly align itself. One solution might be to set the clock rate to what qemu appears to believe is the correct 125 MHz value. And that causes the test to complete, but all tests now take ~10 minutes of real time because the simulator is so slow! So just make up some clock rates, it's a simulated platform after all. I chose 5 MHz cycle time and 100 Hz tick rate, which on my device is about half of "real" speed and very acceptable. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| arc | ||
| arm | ||
| nios2 | ||
| posix | ||
| riscv | ||
| x86 | ||
| xtensa | ||
| Kconfig | ||