From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 21A6DC27C6E for ; Mon, 17 Jun 2024 07:26:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fSd7U9I5o9yX7iVBpTAQ36n54Po1dEsuSVr47xJjN/8=; b=bpb19BQaWb/+TyugD6PkHgQnR8 BQzpeP4HrBVq59qL8GpdnczGDYOLKatJWs20yOcygd9rR8jD2uGffIFCqTgGwshhzEXu0MPwR13Sq 97IpimPju/5vUnf37XwHBZmQPb9jDZw0t/JnBuVyyn8/R58dDYLkzAVOrkP6NcaxbxJB6VXBHYW/l v+ZIw6zFJhUrrcHW5eDm1oYXhUYXRq7PqDa91c7Qpp93dHOANEr+ZC3xVNnovWur2Gd0NVR2dyQli tHueU3t54Dmarjywdu4YDbU9MLYKIlVMHHKSB/sw8k1HHYrYpuLJ8nRa9cmOPZSqmLxxrpRNnlWy8 5xc0bUyQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJ6kg-00000009dfv-39T4; Mon, 17 Jun 2024 07:26:06 +0000 Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJ6kY-00000009dd0-0xVh for linux-arm-kernel@lists.infradead.org; Mon, 17 Jun 2024 07:26:00 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 196A51C0005; Mon, 17 Jun 2024 07:25:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1718609153; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fSd7U9I5o9yX7iVBpTAQ36n54Po1dEsuSVr47xJjN/8=; b=H7CheRsIqsyTag/HRZuce2JzgPV1thWsTJW24N0t5hr/38A36dolPIH+50mWsWBU5FP4A0 MqrRONanAeQsH4XxplHVid6JXPRYTVhjUF2tHfWE97A/80aje5QYmXKytuEnlFzhzQFhv4 HrVhdWYuL/H/qNwpG1CLoBFgTdQXq1blmbNZEvrFNnkF7mr6om3EP9onII3yg1vVHdVKwn 4xlj4EUQL1YpT//oCGsADw3JBj1mY224nfz3MqVIbV4IfY8sLV+Z3vVTRai61ntJ8ud14R lQKRFBUsRwCLv7qf20Y3E2E6SbF14QsmOFw7x9ITHjBtlJDxW61kWIneKwKA+w== Date: Mon, 17 Jun 2024 09:25:51 +0200 From: Alexandre Belloni To: claudiu beznea Cc: geert+renesas@glider.be, mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, lee@kernel.org, magnus.damm@gmail.com, linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Claudiu Beznea Subject: Re: [PATCH 06/12] rtc: renesas-rtca3: Add driver for RTCA-3 available on Renesas RZ/G3S SoC Message-ID: <20240617072551acf731aa@mail.local> References: <20240614071932.1014067-1-claudiu.beznea.uj@bp.renesas.com> <20240614071932.1014067-7-claudiu.beznea.uj@bp.renesas.com> <2024061409215756e6a10c@mail.local> <4a477079-b4a6-4861-ae24-b3b87adb8ecd@tuxon.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a477079-b4a6-4861-ae24-b3b87adb8ecd@tuxon.dev> X-GND-Sasl: alexandre.belloni@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240617_002558_699859_87EAC5A6 X-CRM114-Status: GOOD ( 37.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 14/06/2024 14:06:38+0300, claudiu beznea wrote: > >> + /* > >> + * Stop the RTC and set to 12 hours mode and calendar count mode. > >> + * RCR2.START initial value is undefined so we need to stop here > >> + * all the time. > >> + */ > > > > Certainly not, if you stop the RTC on probe, you lose the time > > information, this must only be done when the RTC has never been > > initialised. The whole goal of the RTC is the keep time across reboots, > > its lifecycle is longer than the system. > > This was also my first thought when I read the HW manual. > > It has been done like this to follow the HW manual. According to HW manual > [1], chapter 22.3.19 RTC Control Register 2 (RCR2), initial value of START > bit is undefined. > > If it's 1 while probing but it has never been initialized, we can falsely > detect that RTC is started and skip the rest of the initialization steps. > W/o initialization configuration, the RTC will not be able to work. > > Even with this implementation we don't loose the time b/w reboots. Here is > the output on my board [2]. The steps I did were the following: > 1/ remove the power to the board (I don't have a battery for RTC installed > at the moment) > 2/ boot the board and issue hwclock -w > 3/ reboot > 4/ check the systime and rtc time > 5/ poweroff > 6/ poweron > 7/ boot and check systime and RTC time > > As you can see the time is not lost but continue to increment. I presume > the hardware takes into account that time needs to increment when initial > configuration is executed. I don't think so, I guess it stops ticking but the registers are not reset so when ts starts ticking again, you are not too far from the time that it should report. > > [1] > https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg3s-general-purpose-microprocessors-single-core-arm-cortex-a55-11-ghz-cpu-and-dual-core-cortex-m33-250 > [2] https://p.fr33tux.org/585cd6 > > > > > Also, why do you insist on 12H-mode? The proper thing to do is to support > > 12H-mode on read but always use 24H-mode when setting the time. > > OK, I wasn't aware of this. I think I followed this approach as it looked > to me the number of operation to update the hardware registers was lower > for 12h mode. How come, using 12H-mode implies testing for the AM/PM bit and doing and addition while 24H-mode would simply be a read? > >> + priv->rtc_dev->ops = &rtca3_ops; > >> + priv->rtc_dev->max_user_freq = 256; > >> + priv->rtc_dev->range_min = mktime64(1999, 1, 1, 0, 0, 0); > >> + priv->rtc_dev->range_max = mktime64(2098, 12, 31, 23, 59, 59); > > > > This very much looks like the range should be 2000 to 2099, why do you > > want to shift it? > > 2000-2099 was my first option for this but then I saw one of your old > commits on this topic and, since I'm not very familiar with RTC, > I took it as example. I'll adjust as you proposed. > > commit beee05dfbead > Author: Alexandre Belloni > Date: Wed Mar 20 12:30:10 2019 +0100 > > rtc: sh: set range > > The SH RTC is a BCD RTC with some version having 4 digits for the year. > > The range for the RTCs with only 2 digits for the year was unfortunately > shifted to handle 1999 to 2098. > > Reviewed-by: Geert Uytterhoeven > Signed-off-by: Alexandre Belloni This is because the sh driver predated the introduction of the range and was already shifting it. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com