Re: [QUESTION] rtc: zynqmp: CALIB_RD reset behavior differs between ZynqMP and Versal

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 14/04/2026 18:08:03+0900, Takumi Ando wrote:
> Hi Harini,
> 
> Thank you for your reply.
> 
> So, if I understand correctly, calibration should be performed periodically
> from userspace via /sys/class/rtc/rtcX/offset.
> 
> In that case, would it be correct to say that, in the current driver,
> programming
> the CALIB_WRITE register from the DTB during probe is not only ineffective,
> but may actually be inappropriate, since the initial value is
> undefined and there
> is no reliable way to determine whether it has already been initialized?

This is correct.

> 
> Best regards,
> 
> 2026年4月9日(木) 20:11 T, Harini <harini.t@amd.com>:
> 
> >
> > Hi,
> >
> > On 3/11/2026 12:22 PM, Takumi Ando wrote:
> > > [You don't often get email from takumi@spacecubics.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > Hi Tomas,
> > >
> > > Thanks for the clarification.
> > >
> > > My understanding is that the fractional correction (fract_data) should
> > > indeed be managed from userspace since it represents oscillator drift
> > > and may change over time.
> > >
> > > However, the Max_Tick field seems to have a different role: it defines
> > > the number of RTC oscillator cycles corresponding to one second.
> > > For example, with a 32.768 kHz oscillator the value should be 32768-1.
> > >
> > > This is how I interpreted the documentation as well.
> > > In the AM012, the description of Max_Tick says that the
> > > register value multiplied by the oscillator period should equal one
> > > second, and it explicitly states that for a 32.768 kHz oscillator the
> > > value will be 0x7FFF.
> > >
> > > Because of this, it appears that Max_Tick depends only on the oscillator
> > > frequency and should not change dynamically like the fractional
> > > correction.
> > >
> > > Did I misunderstand the purpose of the Max_Tick field?
> >
> > Your understanding of the Max_Tick field is correct. However, in the
> > driver's set_offset() implementation, the ppb offset is decomposed into
> > a whole-tick adjustment (which modifies the Max_Tick) and a
> > fractional-tick adjustment (fract_data).
> > Both fields are written together to the calibration register in a single
> > operation. This is what Tomas was referring to when he said both may change.
> >
> > Since the crystal is never exactly 32.678 kHz and its frequency varies
> > with temperature and aging, userspace must always compute and apply
> > correct offset. When it does so via /sys/class/rtc/rtcX/offset, the
> > entire calibration register including Max_Tick is programmed to the
> > appropriate value.
> >
> > Additionally writing Max_Tick unconditionally during probe would destroy
> > a valid calibration value that may have been preserved across a warm
> > reboot on a battery-backed RTC.
> >
> > Thanks,
> > Harini T
> >
> > >
> > > Best regards,
> > >
> > > 2026年3月11日(水) 14:23 Tomas Melin <tomas.melin@vaisala.com>:
> > >>
> > >> Hi,
> > >>
> > >> On 11/03/2026 05:19, Takumi Ando wrote:
> > >>> [You don't often get email from takumi@spacecubics.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >>>
> > >>> Hi Tomas, Alexandre,
> > >>>
> > >>> Thank you for the explanations.
> > >>>
> > >>> So if I understand correctly, both on Zynq UltraScale+ and Versal,
> > >>> CALIB_RD may return a non-zero (or otherwise undefined) value after
> > >>> reset, meaning that it cannot reliably be used to determine whether
> > >>> the calibration register has already been initialized.
> > >>>
> > >>> While the fractional calibration should indeed be handled from
> > >>> userspace (e.g. via the RTC offset interface), it seems that the
> > >>> Max_Tick field should still always be programmed according to the
> > >>> value provided in Device Tree, since it depends only on the RTC
> > >>> oscillator frequency.
> > >>
> > >> Both max_tick and fract_data might change, it depends on how big
> > >>
> > >> the calibrator drift/offset is and if it is negative/positive.
> > >>
> > >>>
> > >>> Would it make sense for the driver to always program Max_Tick from the
> > >>> Device Tree "calibration" property while preserving the fractional
> > >>> calibration bits currently stored in hardware?
> > >>
> > >> As Alexandre mentioned, user space needs to ensure calibration is what
> > >> it should be.
> > >>
> > >>
> > >> thanks,
> > >>
> > >> Tomas
> > >>
> > >>
> > >>>
> > >>> If this approach sounds reasonable, I would like to prepare a patch
> > >>> for upstream.
> > >>>
> > >>> Best regards,
> > >>>
> > >>> 2026年3月6日(金) 20:13 Alexandre Belloni <alexandre.belloni@bootlin.com>:
> > >>>> On 06/03/2026 12:09:40+0200, Tomas Melin wrote:
> > >>>>>> On Zynq UltraScale+ Devices Register Reference (UG1087) [2],
> > >>>>>> CALIB_RD resets to 0, so the current logic works correctly there.
> > >>>>>> However, this assumption does not appear to hold for Versal.
> > >>>>> For Ultrascale+ the calibration register also gives random values after
> > >>>>> reset, perhaps you have noticed this:
> > >>>>> https://adaptivesupport.amd.com/s/article/000036886?language=en_US. Maybe
> > >>>>> the same can occur also on Versal.
> > >>>>>
> > >>>>> AFAIK there is no way of knowing if the value is correct or not after reset,
> > >>>>> so user space helpers might be needed to maintain the calibration value at a
> > >>>>> desired value.
> > >>>>>
> > >>>> Userspace is always needed to put the proper calibration, there is no
> > >>>> way for the kernel to know what value to put there. In the support case
> > >>>> above, the crystal will never be exactly 32768Hz and this value will
> > >>>> change over time and also depends on the temperature. The value always
> > >>>> needs to be computed, if your device can do NTP, chrony will provide the
> > >>>> proper offsets. If you don't have a way to measure the deviation, then
> > >>>> userspace can always forcefully set /sys/class/rtc/rtcX/offset if it
> > >>>> doesn't hold the correct value.
> > >>>> There is no need for devmem here.
> > >>>>
> > >>>> --
> > >>>> Alexandre Belloni, co-owner and COO, Bootlin
> > >>>> Embedded Linux and Kernel engineering
> > >>>> https://bootlin.com/
> > >>>
> > >>>
> > >>> --
> > >>> Takumi Ando
> > >>> Space Cubics Inc.
> > >
> > >
> > >
> > > --
> > > Takumi Ando
> > > Space Cubics Inc.
> > >
> >
> 
> 
> --
> Takumi Ando
> Space Cubics Inc.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com