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>
35ca8c97ce