From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (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 42CEC72 for ; Fri, 20 Aug 2021 03:57:20 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 68D4F580B0E; Thu, 19 Aug 2021 23:57:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 19 Aug 2021 23:57:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=U jmLtA+f8OC3+lbFmpzvt1mYLDqKmlXSvR6zMgM6p1A=; b=GxElH6unmVGlWH1XX xSciszONKWEZ4UrBmkA650Mjbaef43UhTvWDM6fag5s0kzUdcdaOQQBHze3VukOA r0wS/L55YW9kyBZONqR4ivtqi4AlelWftqunRuptqVQudIXU+PxZ21dp/95aUxpN yF/XiqXnTHb4XDf1rS0EIaKajm8IUgnSzK1m2VcrwfJRacFeb23/77EKQzDWeViv 5m36/6FibT4sKTFXy+JawD69Sz4++GyS66JRvVPKHEbKLajy3ctVuZ5jC3J40pHp uSzywtbnYnfqYmAEUnccA7Bt6L4FGTnbIzK4wtWxCbOLZl6e5yLgrIo3qtwHGP57 YZhqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=UjmLtA+f8OC3+lbFmpzvt1mYLDqKmlXSvR6zMgM6p 1A=; b=neiht85Bgu9HmSeDxveJQpmMXAaDoAe7lerhbWe5+y4R99ejb6FOtBhHk rIK3nJpQ02VCD9zA9wyFWl6FCjNA1p23eF5GbGWPNk3lHDLYfGJCp3685mdY5a7y 7K1Q7pp/x4OoNu/Ue5gPxQZYm1GqsFimZ5C+cn9E0jBMQ6Y014tIikqw9OEQ41c9 VvL3bFQ4y0eIZXDPKZtN0bS9BlamR1yeOKj+FDLQewLVC0N4x/oG40F5aDGJcGMA g698O+f0xqciOMVhKCgVmtUdwgusMqmB0M3FYVVjBH7fhi2ROBrtqiDcjLf7XhE+ RJ+EXB+Eg/hnqzP1ddyWFukENjmmA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleekgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefurghmuhgv lhcujfholhhlrghnugcuoehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgqeenucggtf frrghtthgvrhhnpeetteffjeefhfegtdduledutdegudffleduueeftddvlefgieffveef hfdukeegvdenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshgrmhhuvghlsehshhholhhlrghn ugdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 19 Aug 2021 23:57:15 -0400 (EDT) Subject: Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string To: Andre Przywara , Maxime Ripard Cc: Chen-Yu Tsai , Jernej Skrabec , Rob Herring , Icenowy Zheng , linux-arm-kernel@lists.infradead.org, linux-sunxi@googlegroups.com, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Ondrej Jirman , devicetree@vger.kernel.org, Alessandro Zummo , Alexandre Belloni , linux-rtc@vger.kernel.org References: <20210723153838.6785-1-andre.przywara@arm.com> <20210723153838.6785-3-andre.przywara@arm.com> <20210726144137.6dauuxdssu7yszox@gilmour> <20210802013938.29fa18ed@slackpad.fritz.box> <20210817073810.7stuzrppyjf4spab@gilmour> <20210818100407.7cf7cfb7@slackpad.fritz.box> From: Samuel Holland Message-ID: <2b0504f6-9e01-88c1-84c9-c7714715dcb7@sholland.org> Date: Thu, 19 Aug 2021 22:57:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20210818100407.7cf7cfb7@slackpad.fritz.box> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 8/18/21 4:04 AM, Andre Przywara wrote: > On Tue, 17 Aug 2021 09:38:10 +0200 > Maxime Ripard wrote: > > Hi Maxime, > >> On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote: >>> On Mon, 26 Jul 2021 16:41:37 +0200 >>> Maxime Ripard wrote: >>> >>>> Hi, >>>> >>>> On Fri, Jul 23, 2021 at 04:38:29PM +0100, 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. >>>>> Also the clock part is quite different, as there is no external 32K LOSC >>>>> oscillator input. >>>>> >>>>> Signed-off-by: Andre Przywara >>>>> >>>>> --- >>>>> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++ >>>>> 1 file changed, 14 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml >>>>> index beeb90e55727..d8a6500e5840 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 >>>>> @@ -104,6 +105,19 @@ allOf: >>>>> minItems: 3 >>>>> maxItems: 3 >>>>> >>>>> + - if: >>>>> + properties: >>>>> + compatible: >>>>> + contains: >>>>> + const: allwinner,sun50i-h616-rtc >>>>> + >>>>> + then: >>>>> + properties: >>>>> + clock-output-names: >>>>> + minItems: 3 >>>>> + maxItems: 3 >>>> >>>> You don't need both of them when they are equal >>>> >>>>> + clocks: false >>>>> + >>>> >>>> It's not entirely clear to me what those clocks are about though. If we >>>> look at the clock output in the user manual, it looks like there's only >>>> two clocks that are actually being output: the 32k "fanout" clock and >>>> the losc. What are the 3 you're talking about?] >>> >>> I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce >>> clock (/32), and the multiplexed PAD. >> >> But the input and debounce clock is only for the RTC itself right? So it >> should be local to the driver and doesn't need to be made available to >> the other drivers > > I understood "debounce" as being the clock used for the pinctrl > debouncer. What would it debounce otherwise? Do you think that this > "debounce circuit" is something internal to the RTC and is totally > irrelevant for us? I'm pretty sure this is the debounce for the NMI and the SoC reset signal, not the pinctrl. The pinctrl debounce clock pretty clearly references 32 kHz. > But in general I looked at how many *different* clocks this diagram > describes, and I count: one unaltered ("SYSTEM"), one "div by > 32" (RTC/debounce), and one multiplexed. My aim was to avoid > DT binding changes when we later discover we do need one of them for > something (as happened in the past). So three seemed to be the safe > choice here, to avoid surprises. In the worst case we just will never > reference one of them. Plus RC16M/IOSC (and depending on how you look at it, DCXO24M/HOSC). >> Either way, what this list is must be documented. > > You mean to overwrite the "description" stanza for clock-output-names? > And can this be done in the per-SoC parts in the later part of the > binding, keeping the existing description? > > Cheers, > Andre > >> >>>> Also, it looks like the 32k fanout clock needs at least the hosc or >>>> pll-periph in input, so we probably don't want to ask for no parent >>>> clock? Do you suggest we fix this for the existing bindings? >>> Well, we never seem to reference the HOSC this way, this was always >>> somewhat explicit. And yes, there is PLL-PERIPH as an input, but we >>> don't support this yet. So I went with 0 input clocks *for now*: the >>> driver can then ignore all clocks, so any clock referenced in the DT >>> later won't cause any harm. This will all be addressed by Samuel's RTC >>> clock patch, which will also touch the H6, IIRC. And it looks like we >>> will need to touch the binding anyway then, but can then just *extend* >>> this. >> >> You mentioned that series several times already and never provided an >> explanation for what it was supposed to be doing except fixing >> everything. What's the general plan for that series? This is my fault for not sending anything yet. Since the initial version of the driver had the RTC providing HOSC, it depended on converting the existing A100, H6, and H616 CCU drivers to use .fw_name for parents, since those drivers hardcode two different global names for HOSC. And I had no opportunit to do that yet. However, I should really send something that 100% matches the current binding for SoCs where that exists (i.e. osc24M is a fixed clock), and doing so is a smaller job. On the other hand, having osc24M as an RTC *output* neatly sidesteps the fact that it has been missing from the input list :) (But on the other-other hand, A50 gets even more fun, as the HOSC crystal may not be 24MHz anymore. So the RTC has to choose one of three possible HOSC->LOSC dividers based on the HOSC frequency. But there is no register for HOSC frequency. So in this case it is convenient to have HOSC as a separate fixed clock input.) The basic idea of my patch is that using the CCU library code lets us cleanly have slightly different clock trees for each of the RTC variants that Allwinner comes up with. The secondary goal is to add support for osc32k calibration. An early version of the patch is here[1], and I will send something as soon as I have made the modifications described above. But I know you were skeptical about moving the clock part out of the RTC driver. So if you NACK that, somebody will have to add all of the variants to the RTC driver. Regards, Samuel [1]: https://github.com/smaeul/linux/commit/9510ca9e95cb.patch 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=-23.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,MENTIONS_GIT_HOSTING,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 C4312C4338F for ; Fri, 20 Aug 2021 03:59:39 +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 81470610CB for ; Fri, 20 Aug 2021 03:59:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 81470610CB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sholland.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=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:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=4TNtMO+kVI9l0uQhjSA8l4Xez7adNB4LG8/X+JwSQIo=; b=jKE20K/FQTL0kfE2IVFtKdVRZv FxHnXHerJyUEWoNoWC4s3b0Z36TigqXBvSxUyDcmuGBThtkmt1kX1o+Rv3yquE9ae9km/LtDEtAzm 7GxSVMXL2dw8DVVkYXSerhJgUAVcImMbSHbSm9SRD20W8SnYk7fKb5JIdsv7Pkdm2WS0JDB38ZOrA NsHL701ZWkIxzs6bm2MTh/I+PYNhd/i9g880ssfg/Jc6VYlsa+5kD5LZnlLLWhLAdGfmCr8T+qkSx lQPWFRbGBb+KEFwuTmRyNgVQf43bZ0ryn+CSPjxqzi+B2kZgZzYhtO2a968BkAcuPG2EeC01NGr54 h1jnsF5g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGver-00A2Cl-Oi; Fri, 20 Aug 2021 03:57:29 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGvel-00A2BQ-3G for linux-arm-kernel@lists.infradead.org; Fri, 20 Aug 2021 03:57:27 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 68D4F580B0E; Thu, 19 Aug 2021 23:57:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 19 Aug 2021 23:57:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=U jmLtA+f8OC3+lbFmpzvt1mYLDqKmlXSvR6zMgM6p1A=; b=GxElH6unmVGlWH1XX xSciszONKWEZ4UrBmkA650Mjbaef43UhTvWDM6fag5s0kzUdcdaOQQBHze3VukOA r0wS/L55YW9kyBZONqR4ivtqi4AlelWftqunRuptqVQudIXU+PxZ21dp/95aUxpN yF/XiqXnTHb4XDf1rS0EIaKajm8IUgnSzK1m2VcrwfJRacFeb23/77EKQzDWeViv 5m36/6FibT4sKTFXy+JawD69Sz4++GyS66JRvVPKHEbKLajy3ctVuZ5jC3J40pHp uSzywtbnYnfqYmAEUnccA7Bt6L4FGTnbIzK4wtWxCbOLZl6e5yLgrIo3qtwHGP57 YZhqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=UjmLtA+f8OC3+lbFmpzvt1mYLDqKmlXSvR6zMgM6p 1A=; b=neiht85Bgu9HmSeDxveJQpmMXAaDoAe7lerhbWe5+y4R99ejb6FOtBhHk rIK3nJpQ02VCD9zA9wyFWl6FCjNA1p23eF5GbGWPNk3lHDLYfGJCp3685mdY5a7y 7K1Q7pp/x4OoNu/Ue5gPxQZYm1GqsFimZ5C+cn9E0jBMQ6Y014tIikqw9OEQ41c9 VvL3bFQ4y0eIZXDPKZtN0bS9BlamR1yeOKj+FDLQewLVC0N4x/oG40F5aDGJcGMA g698O+f0xqciOMVhKCgVmtUdwgusMqmB0M3FYVVjBH7fhi2ROBrtqiDcjLf7XhE+ RJ+EXB+Eg/hnqzP1ddyWFukENjmmA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleekgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefurghmuhgv lhcujfholhhlrghnugcuoehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgqeenucggtf frrghtthgvrhhnpeetteffjeefhfegtdduledutdegudffleduueeftddvlefgieffveef hfdukeegvdenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshgrmhhuvghlsehshhholhhlrghn ugdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 19 Aug 2021 23:57:15 -0400 (EDT) Subject: Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string To: Andre Przywara , Maxime Ripard Cc: Chen-Yu Tsai , Jernej Skrabec , Rob Herring , Icenowy Zheng , linux-arm-kernel@lists.infradead.org, linux-sunxi@googlegroups.com, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Ondrej Jirman , devicetree@vger.kernel.org, Alessandro Zummo , Alexandre Belloni , linux-rtc@vger.kernel.org References: <20210723153838.6785-1-andre.przywara@arm.com> <20210723153838.6785-3-andre.przywara@arm.com> <20210726144137.6dauuxdssu7yszox@gilmour> <20210802013938.29fa18ed@slackpad.fritz.box> <20210817073810.7stuzrppyjf4spab@gilmour> <20210818100407.7cf7cfb7@slackpad.fritz.box> From: Samuel Holland Message-ID: <2b0504f6-9e01-88c1-84c9-c7714715dcb7@sholland.org> Date: Thu, 19 Aug 2021 22:57:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20210818100407.7cf7cfb7@slackpad.fritz.box> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210819_205723_347372_24F6297F X-CRM114-Status: GOOD ( 42.53 ) 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 8/18/21 4:04 AM, Andre Przywara wrote: > On Tue, 17 Aug 2021 09:38:10 +0200 > Maxime Ripard wrote: > > Hi Maxime, > >> On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote: >>> On Mon, 26 Jul 2021 16:41:37 +0200 >>> Maxime Ripard wrote: >>> >>>> Hi, >>>> >>>> On Fri, Jul 23, 2021 at 04:38:29PM +0100, 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. >>>>> Also the clock part is quite different, as there is no external 32K LOSC >>>>> oscillator input. >>>>> >>>>> Signed-off-by: Andre Przywara >>>>> >>>>> --- >>>>> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++ >>>>> 1 file changed, 14 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml >>>>> index beeb90e55727..d8a6500e5840 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 >>>>> @@ -104,6 +105,19 @@ allOf: >>>>> minItems: 3 >>>>> maxItems: 3 >>>>> >>>>> + - if: >>>>> + properties: >>>>> + compatible: >>>>> + contains: >>>>> + const: allwinner,sun50i-h616-rtc >>>>> + >>>>> + then: >>>>> + properties: >>>>> + clock-output-names: >>>>> + minItems: 3 >>>>> + maxItems: 3 >>>> >>>> You don't need both of them when they are equal >>>> >>>>> + clocks: false >>>>> + >>>> >>>> It's not entirely clear to me what those clocks are about though. If we >>>> look at the clock output in the user manual, it looks like there's only >>>> two clocks that are actually being output: the 32k "fanout" clock and >>>> the losc. What are the 3 you're talking about?] >>> >>> I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce >>> clock (/32), and the multiplexed PAD. >> >> But the input and debounce clock is only for the RTC itself right? So it >> should be local to the driver and doesn't need to be made available to >> the other drivers > > I understood "debounce" as being the clock used for the pinctrl > debouncer. What would it debounce otherwise? Do you think that this > "debounce circuit" is something internal to the RTC and is totally > irrelevant for us? I'm pretty sure this is the debounce for the NMI and the SoC reset signal, not the pinctrl. The pinctrl debounce clock pretty clearly references 32 kHz. > But in general I looked at how many *different* clocks this diagram > describes, and I count: one unaltered ("SYSTEM"), one "div by > 32" (RTC/debounce), and one multiplexed. My aim was to avoid > DT binding changes when we later discover we do need one of them for > something (as happened in the past). So three seemed to be the safe > choice here, to avoid surprises. In the worst case we just will never > reference one of them. Plus RC16M/IOSC (and depending on how you look at it, DCXO24M/HOSC). >> Either way, what this list is must be documented. > > You mean to overwrite the "description" stanza for clock-output-names? > And can this be done in the per-SoC parts in the later part of the > binding, keeping the existing description? > > Cheers, > Andre > >> >>>> Also, it looks like the 32k fanout clock needs at least the hosc or >>>> pll-periph in input, so we probably don't want to ask for no parent >>>> clock? Do you suggest we fix this for the existing bindings? >>> Well, we never seem to reference the HOSC this way, this was always >>> somewhat explicit. And yes, there is PLL-PERIPH as an input, but we >>> don't support this yet. So I went with 0 input clocks *for now*: the >>> driver can then ignore all clocks, so any clock referenced in the DT >>> later won't cause any harm. This will all be addressed by Samuel's RTC >>> clock patch, which will also touch the H6, IIRC. And it looks like we >>> will need to touch the binding anyway then, but can then just *extend* >>> this. >> >> You mentioned that series several times already and never provided an >> explanation for what it was supposed to be doing except fixing >> everything. What's the general plan for that series? This is my fault for not sending anything yet. Since the initial version of the driver had the RTC providing HOSC, it depended on converting the existing A100, H6, and H616 CCU drivers to use .fw_name for parents, since those drivers hardcode two different global names for HOSC. And I had no opportunit to do that yet. However, I should really send something that 100% matches the current binding for SoCs where that exists (i.e. osc24M is a fixed clock), and doing so is a smaller job. On the other hand, having osc24M as an RTC *output* neatly sidesteps the fact that it has been missing from the input list :) (But on the other-other hand, A50 gets even more fun, as the HOSC crystal may not be 24MHz anymore. So the RTC has to choose one of three possible HOSC->LOSC dividers based on the HOSC frequency. But there is no register for HOSC frequency. So in this case it is convenient to have HOSC as a separate fixed clock input.) The basic idea of my patch is that using the CCU library code lets us cleanly have slightly different clock trees for each of the RTC variants that Allwinner comes up with. The secondary goal is to add support for osc32k calibration. An early version of the patch is here[1], and I will send something as soon as I have made the modifications described above. But I know you were skeptical about moving the clock part out of the RTC driver. So if you NACK that, somebody will have to add all of the variants to the RTC driver. Regards, Samuel [1]: https://github.com/smaeul/linux/commit/9510ca9e95cb.patch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel