Received: by 2002:a05:6520:4211:b029:f4:110d:56bc with SMTP id o17csp1548529lkv; Wed, 19 May 2021 12:30:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwlSQ0zxVJoDM9Jdqfh/SCBbHn2UvT57FcFDjkRtpICqs9iPZMD9NIUYp2pFACZPavZCOoW X-Received: by 2002:a05:6e02:104b:: with SMTP id p11mr639456ilj.275.1621452512544; Wed, 19 May 2021 12:28:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621452512; cv=none; d=google.com; s=arc-20160816; b=BPyxf8awlNGG+XvJSRWrCGFjUy6lHDsRZjjpSKoKgSMlZOwGLny8Zm14cpnYZhFa93 c53N1jsL9qG6Wtmxgoc8ryBD9jnPIptgC7VewgRfYdftxhidu7ZCBGXxgxO7DlTMORBJ yGYd5RF/gBBB8lW4l2VlcSbd903Cx8t97Lqkawb5gVF4iX5xdSXqE/3J6HmbHFmTWob2 jAzV03aIVhfdfY4VGR/66pGZhnTuLBHhRTgAnTqtVniE6GGf3R9KLhX4atiFRGx+JzYU r5iahw+2KVum6GBIcSiJBp+yGfya5WJcAtzTPGznPGEZKVijB7zIhIsVIxDZMA/0oEuC Y5RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=PvfyG3hfKbnBbSFdMDecTOohUcuGOTnhPaocPK96+3s=; b=jzBU5M6qJ1z6XjNe5r85CEpVWyGDXlHsPC/5l6H4P8sc60DG4v2F9oNThfaPUrFZVu mg8paSB8VDY2EJoqocuDslbjOtrgcUiZb6yc06VBzrHSzZEn9CXnzGVyXshAYrAIFk9x H8RcQ00cl7swx9+c8QoLGh0/euNa9aQ0ij0pEfAayvTzKLaCxzZXZ5nzz7QRkqwzTvBy CVNtClr0Y+Ubb73aP3zf5KFnxjpmh1DNLJVRPo5jcXZW/lOrKTmjupEbgz+KVvy8MKUJ WJK6RLDSMF9ZRItCpL4vLlOnVH5lUD185ckSwSo77miWlJXEE/zdRiMmqtRQesQGWHlH q3zQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n10si664180ilk.92.2021.05.19.12.28.20; Wed, 19 May 2021 12:28:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348591AbhESKno (ORCPT + 99 others); Wed, 19 May 2021 06:43:44 -0400 Received: from foss.arm.com ([217.140.110.172]:58890 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348367AbhESKng (ORCPT ); Wed, 19 May 2021 06:43:36 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4809314BF; Wed, 19 May 2021 03:42:17 -0700 (PDT) Received: from localhost.localdomain (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2CABC3F792; Wed, 19 May 2021 03:42:15 -0700 (PDT) From: Andre Przywara To: Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec Cc: Rob Herring , Icenowy Zheng , Samuel Holland , Ondrej Jirman , linux-arm-kernel@lists.infradead.org, linux-sunxi@googlegroups.com, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Alessandro Zummo , Alexandre Belloni , linux-rtc@vger.kernel.org Subject: [PATCH v6 04/17] rtc: sun6i: Add support for linear day storage Date: Wed, 19 May 2021 11:41:39 +0100 Message-Id: <20210519104152.21119-5-andre.przywara@arm.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20210519104152.21119-1-andre.przywara@arm.com> References: <20210519104152.21119-1-andre.przywara@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Newer versions of the Allwinner RTC, as for instance found in the H616 SoC, no longer store a broken-down day/month/year representation in the RTC_DAY_REG, but just a linear day number. The user manual does not give any indication about the expected epoch time of this day count, but the BSP kernel uses the UNIX epoch, which allows easy support due to existing conversion functions in the kernel. Allow tagging a compatible string with a flag, and use that to mark those new RTCs. Then convert between a UNIX day number (converted into seconds) and the broken-down day representation using mktime64() and time64_to_tm() in the set_time/get_time functions. That enables support for the RTC in those new chips. Reviewed-by: Andre Przywara --- drivers/rtc/rtc-sun6i.c | 58 +++++++++++++++++++++++++++++------------ 1 file changed, 41 insertions(+), 17 deletions(-) diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c index adec1b14a8de..0228e9dfd969 100644 --- a/drivers/rtc/rtc-sun6i.c +++ b/drivers/rtc/rtc-sun6i.c @@ -133,12 +133,15 @@ struct sun6i_rtc_clk_data { unsigned int has_auto_swt : 1; }; +#define RTC_LINEAR_DAY BIT(0) + struct sun6i_rtc_dev { struct rtc_device *rtc; const struct sun6i_rtc_clk_data *data; void __iomem *base; int irq; unsigned long alarm; + unsigned long flags; struct clk_hw hw; struct clk_hw *int_osc; @@ -471,17 +474,30 @@ static int sun6i_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm) rtc_tm->tm_min = SUN6I_TIME_GET_MIN_VALUE(time); rtc_tm->tm_hour = SUN6I_TIME_GET_HOUR_VALUE(time); - rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date); - rtc_tm->tm_mon = SUN6I_DATE_GET_MON_VALUE(date); - rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date); - - rtc_tm->tm_mon -= 1; - - /* - * switch from (data_year->min)-relative offset to - * a (1900)-relative one - */ - rtc_tm->tm_year += SUN6I_YEAR_OFF; + if (chip->flags & RTC_LINEAR_DAY) { + struct tm tm; + + /* + * Newer chips store a linear day number, the manual + * does not mandate any epoch base. The BSP driver uses + * the UNIX epoch, let's just copy that, as it's the + * easiest anyway. + */ + time64_to_tm((date & 0xffff) * 3600ULL * 24, 0, &tm); + rtc_tm->tm_mday = tm.tm_mday; + rtc_tm->tm_mon = tm.tm_mon; + rtc_tm->tm_year = tm.tm_year; + } else { + rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date); + rtc_tm->tm_mon = SUN6I_DATE_GET_MON_VALUE(date) - 1; + rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date); + + /* + * switch from (data_year->min)-relative offset to + * a (1900)-relative one + */ + rtc_tm->tm_year += SUN6I_YEAR_OFF; + } return 0; } @@ -571,15 +587,21 @@ static int sun6i_rtc_settime(struct device *dev, struct rtc_time *rtc_tm) u32 date = 0; u32 time = 0; - rtc_tm->tm_year -= SUN6I_YEAR_OFF; rtc_tm->tm_mon += 1; - date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) | - SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon) | - SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year); + if (chip->flags & RTC_LINEAR_DAY) { + date = mktime64(rtc_tm->tm_year + 1900, rtc_tm->tm_mon, + rtc_tm->tm_mday, 0, 0, 0) / (3600ULL * 24); + } else { + rtc_tm->tm_year -= SUN6I_YEAR_OFF; + + date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) | + SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon) | + SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year); - if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN)) - date |= SUN6I_LEAP_SET_VALUE(1); + if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN)) + date |= SUN6I_LEAP_SET_VALUE(1); + } time = SUN6I_TIME_SET_SEC_VALUE(rtc_tm->tm_sec) | SUN6I_TIME_SET_MIN_VALUE(rtc_tm->tm_min) | @@ -678,6 +700,8 @@ static int sun6i_rtc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, chip); + chip->flags = (unsigned long)of_device_get_match_data(&pdev->dev); + chip->irq = platform_get_irq(pdev, 0); if (chip->irq < 0) return chip->irq; -- 2.17.5