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

["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.
>