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 E85CCC27C77 for ; Mon, 17 Jun 2024 07:32:12 +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:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qi5kSVv+9tuno5ifh0iY5wU3dPT3z2QMr3DXugcnBOU=; b=M1oX5hG81puLshypblCIYJK7b+ Y2kaA7S9Yw3zYgMas1Tz4JfYjbciMOWBbD8yiglrJwsidaBwHhav6Q0GbNF0cGDsode/MTMIXtKwB lSNuF6XJo3AP+FbBQN/Fqyk3v/pdM6hkwXJe69cKqYShdxHpFqXyT+bTCcCj+GlRUCqy6BQIkxUys CDedLBtj6Tk17aVS9cSfMTZi1SMo/Hm2Ax1U//k4FgbdiOI0Qdjjt+Dpke/K8s7MTYlyrbzsvEcCV MMVRIetbPdKY2vquuflPgMNtxPGGve09IjCGTcquAEaRfiHQ9G5lvsfuST0P3jcfOAuE/jlPn3m7i bYqXL93g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJ6qN-00000009fN4-1nRY; Mon, 17 Jun 2024 07:31:59 +0000 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJ6qJ-00000009fMF-3RoZ for linux-arm-kernel@lists.infradead.org; Mon, 17 Jun 2024 07:31:57 +0000 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2ec2f4966a2so4457491fa.0 for ; Mon, 17 Jun 2024 00:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1718609513; x=1719214313; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=qi5kSVv+9tuno5ifh0iY5wU3dPT3z2QMr3DXugcnBOU=; b=LhhIDc/xeqElBZEQsIF5DUx5dnrYkUH7KUx7xWtk5Qjr36JqHj/fVq8pWz6u2zZnou w9QVKK8Qi/zl+Edh/TK5xuqM+7XPFIpvexN1O86W3PpGhPCtKkKGOrfygoqXTod2goFa LjUhkvsSyg2d36LwDjew2/sQurOh+cW9upVbwxWibaiMzEFALi7pGCt1L6q3lh1lUKXv DWXQWxf0P+Phg/05pY8N4wmqXy4GlXl5s6+zufIKFCk/83cyMkhLby3PGXfutsYqlxvV PXXVdQqBFgN/EAcPNimjO0ihyVWPEMlWDP/BiSNhQo5/Gje7pa1easjCY2VrwPZjLRvp ULYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718609513; x=1719214313; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qi5kSVv+9tuno5ifh0iY5wU3dPT3z2QMr3DXugcnBOU=; b=YD6J3KXKg3IHj2NmbbiEshQCGkcggkPEBL5Q+ARIXEc+pOMNtqrgD5dtxSu60aeIdX Ks8hkq1/7RK4JHGmRScxzfpKLsUK7wUjpY7SLS3H8h7d0C0z8Uap2mNgz2gx38yD9lrL jji6u5Gx2AjCDOHkRV8KGA7IAWYC32goP7g02lthlc2cSOcgKMZdUUJ/mG0h6ExBsLU5 U+3Vgxs4uiUbD4ipmANseYMQWwN+tDJtIbNCB/w+TziFQtJmYZgmz36lT3v9Mkm1krsd H2ejaX2DnFcOmc3Qj6Yiel+dVkU7X88W6JivPFSFcbwyemjmuNfb1cCa2NS3Y0e+Qf7g Lg9A== X-Forwarded-Encrypted: i=1; AJvYcCUoX3yScM7NoT1tkgD33RIcXYbs/AGUq38tJBYDjgOcwkyodVXxz4EYriEQZe4T/Yd7Z7cjKVIYIS+giu/chdIuhl/PCNCC7oOAh7WWRagjcUS2jZA= X-Gm-Message-State: AOJu0Yy3ZDPVlMGawZ6WyBxL/M5QpEJTHaYoFCo4ffAbtpBIt/VYUXlR PoiZiFngDpatZ4w3zC2tT1CsTTP8oMXUsPGzeU36KlSq7FcFIEbYgAIo2UvoOJ8qcK+MBWM51LT S X-Google-Smtp-Source: AGHT+IG6NUWe4l16T9e0fiJ0Sljl3qaxM46VXB2+kbWXexuNwB4kN0H3QGjj6j8BQ10yhKbClCkMvg== X-Received: by 2002:a2e:990b:0:b0:2ec:26a9:d5bc with SMTP id 38308e7fff4ca-2ec26a9d704mr28756001fa.18.1718609513397; Mon, 17 Jun 2024 00:31:53 -0700 (PDT) Received: from [192.168.50.4] ([82.78.167.189]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-422870e986asm191491115e9.27.2024.06.17.00.31.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Jun 2024 00:31:52 -0700 (PDT) Message-ID: Date: Mon, 17 Jun 2024 10:31:51 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/12] rtc: renesas-rtca3: Add driver for RTCA-3 available on Renesas RZ/G3S SoC Content-Language: en-US To: Alexandre Belloni 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 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> <20240617072551acf731aa@mail.local> From: claudiu beznea In-Reply-To: <20240617072551acf731aa@mail.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240617_003155_918164_6ECBE486 X-CRM114-Status: GOOD ( 30.98 ) 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 17.06.2024 10:25, Alexandre Belloni wrote: > 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. I'll double check with hardware team on this and return with an answer. Thank you for your review, Claudiu Beznea > >> >> [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. > >