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
Description: PGP signature
