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