Re: [PATCH 16/26] hw/rtc: Add PolarFire SoC RTC model

Conor Dooley <[email protected]> Thu, 23 Jul 2026 16:58:26 +0100

Newsgroups	org.nongnu.qemu-riscv,org.nongnu.qemu-devel
Message-ID	<20260723-sliding-plural-bf980dc1e567@spud>

On Thu, Jul 23, 2026 at 11:55:03PM +0800, Bin Meng wrote:
> 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

You say "yes" here, but the rest of the sentence is addressing something
I did not ask so it is not clear if you actually mean that this matches
the hardware's behaviour.
Could you clarify please?

> 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
>

signature.asc (application/pgp-signature, 228 B)