From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4FD0E29CA for ; Mon, 7 Jun 2021 12:59:23 +0000 (UTC) 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 904C712FC; Mon, 7 Jun 2021 05:59:17 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 690443F694; Mon, 7 Jun 2021 05:59:15 -0700 (PDT) Date: Mon, 7 Jun 2021 13:59:10 +0100 From: Andre Przywara To: Samuel Holland Cc: Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec , Rob Herring , Icenowy Zheng , Ondrej Jirman , linux-arm-kernel@lists.infradead.org, linux-sunxi@googlegroups.com, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Alessandro Zummo , Alexandre Belloni , linux-rtc@vger.kernel.org Subject: Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string Message-ID: <20210607135910.63560ffc@slackpad.fritz.box> In-Reply-To: <99a2069b-99e9-9b47-12a6-aae01c7f59dc@sholland.org> References: <20210519104152.21119-1-andre.przywara@arm.com> <20210519104152.21119-4-andre.przywara@arm.com> <99a2069b-99e9-9b47-12a6-aae01c7f59dc@sholland.org> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 20 May 2021 21:37:34 -0500 Samuel Holland wrote: Hi, > On 5/19/21 5:41 AM, Andre Przywara wrote: > > Add the obvious compatible name to the existing RTC binding. > > The actual RTC part of the device uses a different day/month/year > > storage scheme, so it's not compatible with the previous devices. > > > > Signed-off-by: Andre Przywara > > --- > > .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > index b1b0ee769b71..178c955f88bf 100644 > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > @@ -26,6 +26,7 @@ properties: > > - const: allwinner,sun50i-a64-rtc > > - const: allwinner,sun8i-h3-rtc > > - const: allwinner,sun50i-h6-rtc > > + - const: allwinner,sun50i-h616-rtc > > > > reg: > > maxItems: 1 > > @@ -97,7 +98,9 @@ allOf: > > properties: > > compatible: > > contains: > > - const: allwinner,sun50i-h6-rtc > > + enum: > > + - allwinner,sun50i-h6-rtc > > + - allwinner,sun50i-h616-rtc > > > > then: > > properties: > > > > This binding is missing a clock reference for the pll-periph0-2x input > to the 32kHz clock fanout. Right. So do I get this correctly that we don't model the OSC24M input explicitly so far in the DT? I only see one possible input clock, which is for an optional 32K crystal oscillator. And this means we need to change some code also? Because at the moment a clock specified is assumed to be the 32K OSC, and having this clock means we switch to the external 32K OSC. And who would decide which clock source to use? What would be the reason to use PLL_PERIPH(2x) over the RC16M based clock or the divided down 24MHz? So shall we ignore the PLL based input clock for now, put "0 input clocks" in the current binding, then later on extend this to allow choosing the PLL? And have it that way that having the PLL reference means we use it? > It is also missing a clock reference to the RTC register gate (and that > clock is in turn missing from the r_ccu driver). Do you mean a gate bit somewhere in the PRCM? Do you have any pointer/documentation for that? Cheers, Andre 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 X-Spam-Level: X-Spam-Status: No, score=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E63DDC47082 for ; Mon, 7 Jun 2021 13:07:45 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id ADFEB60FDA for ; Mon, 7 Jun 2021 13:07:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ADFEB60FDA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=OWSl4M4sON50qAzuCDrka0UvSuIoVyY4/nDvqF2XyLY=; b=toekV7+9S+CD1z cHDVlJA7FqpZ5cPt3hMESwfn+cM6JBmY3rszjgTO+ghyEGeZHsvP66Tsw450BaHQ56W82zhXTiVtK ksCaMfpN2Qa0QkF1PaniMqeLRcSVPsdHwuaqekTLsF28gk1TBzWEBKqfGM2X+PfefRtrxgDa3LlMb ZZffMn80rO8W+L/Up8P2YnmG/+9zo49ClUHHof9XcNkq/lIU4fy2XdmbC+W0wWVuEGnBsxvBpOpAW f6FnVOmFXD8U67CstTmH28u7F/z5aWJdgUUuJRwUpM8Dtn8shYCIFsYL7t48ln9UnqkmjqlCmFmTg tw+DUy1BLOdM8/BOv3zw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqEwu-003gFV-4x; Mon, 07 Jun 2021 13:05:49 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqEqe-003eU0-My for linux-arm-kernel@lists.infradead.org; Mon, 07 Jun 2021 12:59:23 +0000 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 904C712FC; Mon, 7 Jun 2021 05:59:17 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 690443F694; Mon, 7 Jun 2021 05:59:15 -0700 (PDT) Date: Mon, 7 Jun 2021 13:59:10 +0100 From: Andre Przywara To: Samuel Holland Cc: Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec , Rob Herring , Icenowy Zheng , Ondrej Jirman , linux-arm-kernel@lists.infradead.org, linux-sunxi@googlegroups.com, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Alessandro Zummo , Alexandre Belloni , linux-rtc@vger.kernel.org Subject: Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string Message-ID: <20210607135910.63560ffc@slackpad.fritz.box> In-Reply-To: <99a2069b-99e9-9b47-12a6-aae01c7f59dc@sholland.org> References: <20210519104152.21119-1-andre.przywara@arm.com> <20210519104152.21119-4-andre.przywara@arm.com> <99a2069b-99e9-9b47-12a6-aae01c7f59dc@sholland.org> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210607_055920_912340_B56B7924 X-CRM114-Status: GOOD ( 26.34 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 20 May 2021 21:37:34 -0500 Samuel Holland wrote: Hi, > On 5/19/21 5:41 AM, Andre Przywara wrote: > > Add the obvious compatible name to the existing RTC binding. > > The actual RTC part of the device uses a different day/month/year > > storage scheme, so it's not compatible with the previous devices. > > > > Signed-off-by: Andre Przywara > > --- > > .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > index b1b0ee769b71..178c955f88bf 100644 > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > @@ -26,6 +26,7 @@ properties: > > - const: allwinner,sun50i-a64-rtc > > - const: allwinner,sun8i-h3-rtc > > - const: allwinner,sun50i-h6-rtc > > + - const: allwinner,sun50i-h616-rtc > > > > reg: > > maxItems: 1 > > @@ -97,7 +98,9 @@ allOf: > > properties: > > compatible: > > contains: > > - const: allwinner,sun50i-h6-rtc > > + enum: > > + - allwinner,sun50i-h6-rtc > > + - allwinner,sun50i-h616-rtc > > > > then: > > properties: > > > > This binding is missing a clock reference for the pll-periph0-2x input > to the 32kHz clock fanout. Right. So do I get this correctly that we don't model the OSC24M input explicitly so far in the DT? I only see one possible input clock, which is for an optional 32K crystal oscillator. And this means we need to change some code also? Because at the moment a clock specified is assumed to be the 32K OSC, and having this clock means we switch to the external 32K OSC. And who would decide which clock source to use? What would be the reason to use PLL_PERIPH(2x) over the RC16M based clock or the divided down 24MHz? So shall we ignore the PLL based input clock for now, put "0 input clocks" in the current binding, then later on extend this to allow choosing the PLL? And have it that way that having the PLL reference means we use it? > It is also missing a clock reference to the RTC register gate (and that > clock is in turn missing from the r_ccu driver). Do you mean a gate bit somewhere in the PRCM? Do you have any pointer/documentation for that? Cheers, Andre _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel