From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CC6235E956 for ; Fri, 6 Mar 2026 11:13:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772795621; cv=none; b=hM5ubELO9vTOIFWpXrtrg1Xq2nGf+qyhWVQd1GUSZTv6gKsUquWu8y+J9Oaof1pJ7a3QRQWKygQjwsJUDEs0//2L4AYRsuTHTCbPZn9S/Pyq8LOLNPnboACP5lFqGs5uDfG5BZeuLYtvOEiFGo0hsIzGjg3jxn2UYxzWijYtDUM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772795621; c=relaxed/simple; bh=LIxxnkCVnwmzVwLUuMjpH7s98wmieqmeVyh1MUQKaJg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nfeW4KwmtQSyD7hKmhZ9uZQHbUWjFhawDIROk2c04cZ4ZdCl2wvP3gniFAbviRRZX5yA8fP3iw8U4NHYhqInANcBh5DhgfnahyDmgHsEv2kuxJq/ctabphd4Iepnd5Ze14b792DWXW30ig93BjHVaGvUtX1hLC0Eivxg94KvnsY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=Ol+MiP5p; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="Ol+MiP5p" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 06E6A4E4258A; Fri, 6 Mar 2026 11:13:32 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id BC0525FF92; Fri, 6 Mar 2026 11:13:31 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 1F4BF10369377; Fri, 6 Mar 2026 12:13:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1772795611; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=pCDWa/n78XXMhf61ch4T8hjleXLcBp1wJMK7/c7pOl4=; b=Ol+MiP5pOzc/N49N6/414dKpNQ7PmnF8fGe1Oivksxkuzq/JYtVkaTTH8d1KAA9U1HMHWX UBkrC5Ca10HqOytH+6MYYoKpKf08suS6t4whdFGXtosnLIcl6U3Z8HiMXbrTEMte7mxUmi zfL1SkLstQilEQGsOFhDpdqTKJVREfX2F+L4i4eY5eoxN4MtVxC0FDCHdhVOQa1aUfxjFb mH2Ic6blFC0qsXR89kQEreL5x4w3cP11/ZzfYJUnV2LkMthWiB5vJg5rb5Rs7iwU7lCstG nTNSoHIfWNjo2dKyBdqr+HuHSFrkaow27u5OiodfPyvhrN5RyWWYWZVJBaoSEQ== Date: Fri, 6 Mar 2026 12:13:29 +0100 From: Alexandre Belloni To: Tomas Melin Cc: Takumi Ando , linux-rtc@vger.kernel.org, michal.simek@amd.com, Yasushi SHOJI , kanta tamura Subject: Re: [QUESTION] rtc: zynqmp: CALIB_RD reset behavior differs between ZynqMP and Versal Message-ID: <202603061113298cbba29d@mail.local> References: <9ed6823e-b381-4de5-b1cf-98f5dc54bb7c@vaisala.com> Precedence: bulk X-Mailing-List: linux-rtc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ed6823e-b381-4de5-b1cf-98f5dc54bb7c@vaisala.com> X-Last-TLS-Session-Version: TLSv1.3 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