Attention is currently required from: Yidi Lin.
2 comments:
Commit Message:
Patch Set #11, Line 11: USECS_PER_SEC and hz can be reduced by dividing them by their GCD.
Assuming their GCD is big enough?
Yeah we're kinda assuming that on Arm systems the timer clocks are always in MHz, and for now that seems to match what we have. I guess we could have just written a simple division instead, but using the GCD seems a bit cleaner.
Patch Set #11, Line 15: counter should never be that fast.
On Intel it can be that fast (it's usually the processor base […]
Wouldn't that mean that we'd have broken things with the `assert(UINT32_MAX / 1000 >= lib_sysinfo.cpu_khz);` we're adding here? I don't think we've heard anyone complain yet. Or do only certain (maybe older) Intel CPUs do it that way?
Remember that `udelay()` is implemented with this (at least outside of x86 boards with CONFIG_LP_ENABLE_APIC), so I do think we need to keep the microsecond resolution.
We could do something closer to what `update_clock()` does here, but we really have the same problem in coreboot so it doesn't make much sense to fix it differently here than there. In coreboot, the `timer_monotonic_get()` API doesn't really allow you to access the raw timer value and frequency like that, so you couldn't build a global, generic tick counter thing like that. You'd first have to redesign coreboot's whole platform-specific timer interface to be closer to what libpayload does (which I'd be fine with but it's a bit of a bigger deal, touching a bunch of platforms).
In practice, I think the solution here now should be good enough for the platforms we have (unless we accidentally broke the RDTSC driver here, then we need to fix that).
To view, visit change 78888. To unsubscribe, or for help writing mail filters, visit settings.