Library or example for HPET?

[ChocolateLoverRaj]

Is there a Rust library or example for using the HPET? I see HPET in ACPI, but idk how to use it.

INFO : ACPI table header: SdtHeader {
    signature: "HPET",
    length: 56,
    revision: 1,
    checksum: 180,
    oem_id: [
        66,
        79,
        67,
        72,
        83,
        32,
    ],
    oem_table_id: [
        66,
        88,
        80,
        67,
        32,
        32,
        32,
        32,
    ],
    oem_revision: 1,
    creator_id: 1129338946,
    creator_revision: 1,
}

[bjorn3]

No idea if there is a crate for this, but this is what Redox OS does:

Parsing the ACPI table and allowing read/writes to the HPET MMIO: https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/acpi/hpet.rs?ref_type=heads
Initializing the HPET to trigger a timer with a certain interval: https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/x86_shared/device/hpet.rs?ref_type=heads

And the osdev wiki page for HPET in case you didn't see it yet: https://wiki.osdev.org/HPET

[ChocolateLoverRaj]

From the Redox code I'm a little confused about how setting the interrupts works. Do you tell the HPET what the IO APIC interrupt index to send interrupt sto and then set a redirection entry in the IO APIC to actually map to a CPU interrupt index that you set a handler for?

And in the interrupt handler do you have to do anything besides telling the Local APIC end of interrupt?

Also do you still have to get the current time from something like the RTC?

[tsatke]

1. Exactly
2. You only have to be careful to service the right device if you map multiple interrupt indices to the same handler (for example all network cards to a single interrupt).
3. You usually only read the RTC once on boot, then remember that time and only add a HPET "offset" to it. Once you have your network stack running, you can use NTP to get a more accurate time than the one from the RTC, but you still only use the HPET or other clock sources to measure time since that reference time. I'm sure there's more elaborate ways that are better, but this works just fine. Re-sync your reference time every now and then.

[tsatke]

I'm not using the HPET with interrupts, but just as a clock.

https://github.com/tsatke/devos/blob/0c818c24e0312c8dea3bf4541c636433bef65379/kernel/src/driver/hpet.rs
https://github.com/tsatke/devos/blob/0c818c24e0312c8dea3bf4541c636433bef65379/kernel/src/time/mod.rs

[bjorn3]

I don't think you need a lock. At the hardware level every read and write acts like an atomic. Technically our current volatile operations are not atomic, but I don't think there would be any way for the compiler to notice a data race with another thread and by definition it has to allow data races with the device.

[ChocolateLoverRaj]

So is a lock even needed at all for the rest of the HPET MMIO?

[bjorn3]

If you for consistency reasons need to read multiple registers without any intervening write or write multiple registers without any intervening read then you would need a lock. If modelling each register as a separate atomic would work for your purposes, you don't need a lock. For example you may want to put writes to the configuration register and the comparator register behind a single lock so it isn't possible to accidentally have the configuration one thread tried to set, but the comparator value that another thread tried to set.

[ChocolateLoverRaj]

If @tsatke or anyone is interested, I added on to @tsatke's struct and added fields and bitfields for almost every memory mapped thing in the HPET. It is here. I will probably make it a library later.

[tsatke]

At the hardware level every read and write acts like an atomic.

@bjorn3 searching for a source for that, all I could find (for HPET) is that it's "generally considered to be atomic", but not guaranteed - check the documentation for the chip you're using. Also, linux seems to lock (but it's just performance in some weird edge cases?).

Do you have any references for that? I'd love to get rid of a few more locks in my code.