Re: [PATCH 16/26] hw/rtc: Add PolarFire SoC RTC model
Bin Meng <[email protected]> Thu, 23 Jul 2026 23:55:03 +0800
| Newsgroups | org.nongnu.qemu-riscv,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <CAEUhbmVYdwUbp_y8TKZggoz7oNRWo7+sfe1Q+vbqApawp7jEmg@mail.gmail.com> |
On Thu, Jul 23, 2026 at 11:29 PM Conor Dooley <[email protected]> wrote: > > On Thu, Jul 23, 2026 at 11:18:43PM +0800, Bin Meng wrote: > > The PolarFire SoC exposes an RTC with binary and calendar modes, > > programmable prescaling, alarms, and wakeup and match interrupts. > > > > Add a standalone device model with explicit MMIO handling for time, > > commands, alarms, interrupt state, reset, and migration. Add its > > Kconfig and Meson entries and list it under the PolarFire SoC > > maintainer section. > > > > Signed-off-by: Bin Meng <[email protected]> > > + > > +#define RTC_REG(offset) ((offset) / sizeof(uint32_t)) > > + > > +static uint64_t mchp_pfsoc_rtc_get_count(MchpPfSoCRtcState *s) > > +{ > > + if (!s->running) { > > + return s->frozen_count; > > + } > > + > > + return s->tick_offset + > > + qemu_clock_get_ns(rtc_clock) / NANOSECONDS_PER_SECOND; > > +} > > Just to be sure, this is done to match the hardware's behaviour of > resetting the count when the device is power cycled? > Yes, the rtc_clock + tick_offset scheme is commonly used by other QEMU RTC models, such as PL031, etc. It is not specifically intended to model the counter being reset on a power cycle. Instead, it maps QEMU's clock source to the guest-programmable RTC counter value. Regards, Bin