[GSoC - x86_64] Clock driver - which hardware source to support primarily?
amaan.cheval at gmail.com
Tue Jul 17 17:18:37 UTC 2018
Now that I'm working on the clock driver, we need to pick what we
support first. Our options in brief are:
- rdtsc; will need calibration through the PIT or one of the other options
- PIT; likely not given how legacy it is, but it may be quite simple
- APIC timer; better for long-term as it's independent of multiple
core time sync problems in general, and it also has multiple modes,
including having the timer generate deadline interrupts instead of the
"polled" ticking method. It'll need better interrupt support and ACPI
- HPET (high-precision event timer); may be the "best" option -
it's fairly modern, highly accurate. Only downside is it needing ACPI
to detect and use (as opposed to usually CPUID for the others)
- RTC; legacy real-time clock - not really a good option in my
understanding because it's often too slow for real use-cases needing
the high precision
I suspect using rdtsc+pit (option 1) is likely the best for now in
providing us with speed (rdtsc is much faster than the PIT, I've read)
and ease-of-development (for the port, that is).
Using the APIC timer may work well as well since basic ACPI and
interrupt support are likely important for this port (for eg.
currently, the port doesn't know how to reset the system at all, until
we look into ACPI more). This will likely take a while but help the
port be much more well-rounded for future growth.
The HPET option is great if the high-precision is important - from
other ports, it doesn't look like we need _such_ high precision, but
let me know if that's wrong (especially given that most other BSPs are
not usually as beefy as x86_64 systems may be too).
For now, I'm probably working on setting the PIT up regardless since
it'll likely be useful as a fallback no matter what (and it can be
used for some of the other methods too).
More information about the devel