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 161DCEEB591 for ; Thu, 12 Sep 2024 11:29:27 +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=Yl+JSpWTogXJCp/SAVK9H1AoP8UonqsBtyzPzlwap5g=; b=1MVb6Q1OJJTKYWhF5mpklUQSkB NT5cPtyZLKyFiQDo5UvvXGmXg8CckJgWIN9yiSolAGEN2DWMeXpm9sF8JBVEEpKHkgEKBH7IJrTL1 WHkJR4n/fmuH9AdZZrdO6tDhMkTvoJz1DGixua34XColRFR79GxZmeWG3NHLp6wkZ5S5SN+xjCQLH 9i62hoFK7mPHW6v27IscyiPN7lRjHNz5LAGUn/VdzF9+L/qDHqHk9EJ2V+NVeLSh63vNq/vRpghqc WjhiAfnNWEkeO5hsLa17l5uOqhLquq+hDbJ1fn2PDkmpa9WPMvpLOUfpRWfvFW/3DlrB1LLT1zynG zIx6Jteg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1soi0g-0000000Cs0R-2r0A; Thu, 12 Sep 2024 11:29:14 +0000 Received: from esa.microchip.iphmx.com ([68.232.153.233]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sohzc-0000000CrmJ-0CD2 for linux-arm-kernel@lists.infradead.org; Thu, 12 Sep 2024 11:28:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1726140488; x=1757676488; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=nDn6unH5tAhXWtRRLOGA+5Nl2pWg7WAtVYRbNLHpai8=; b=0MMyeIV3aSLOm6gutOxnKP/qPPvGUEhSYEcA8xkyM8ZAcajwfj+0ZiFx iojvAcoAMZY4qhbsacg8w887PiOGzBFrR1xoVcaB7xkEGph5Jd10F7VUV rC2meF9NI321Mohg324Px3G1qMVEk5LJ1HDSHC2uYRyHi+SqkeO35wltH +MUS+1GQG6Qb1t4PSHOoLiEP44AKh7X6BO3VTZNrS+N7SsPMxCxQQxik4 oQ84g52p4HKjWlP0d4dYg+xnSWldPD9mlMxYkx5Bg9RPa68JvaT1JEyQr IAUayAAqxWed4zfw0ugM6hg6d/Bl/9ywhOivgBUXewoeJsIcV6F256nZF w==; X-CSE-ConnectionGUID: Ho+Go28UQ22rTQtj8F2tvQ== X-CSE-MsgGUID: 42eUs+DHSTujsgDfYWh4nw== X-IronPort-AV: E=Sophos;i="6.10,222,1719903600"; d="asc'?scan'208";a="262681680" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa5.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 12 Sep 2024 04:28:06 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 12 Sep 2024 04:27:57 -0700 Received: from wendy (10.10.85.11) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Thu, 12 Sep 2024 04:27:55 -0700 Date: Thu, 12 Sep 2024 12:27:22 +0100 From: Conor Dooley To: Ciprian Marian Costea CC: Conor Dooley , Alexandre Belloni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Catalin Marinas , Will Deacon , , , , , NXP S32 Linux Team , Bogdan-Gabriel Roman , Ghennadi Procopciuc Subject: Re: [PATCH 1/4] dt-bindings: rtc: add schema for NXP S32G2/S32G3 SoCs Message-ID: <20240912-immersion-obvious-81a2a0c7a9cb@wendy> References: <20240911070028.127659-1-ciprianmarian.costea@oss.nxp.com> <20240911070028.127659-2-ciprianmarian.costea@oss.nxp.com> <20240911-racism-playmaker-71cb87d1260f@spud> <62ba70ca-429e-476c-bb7b-78f743574a68@oss.nxp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2CwcanIC+v5LIFSS" Content-Disposition: inline In-Reply-To: <62ba70ca-429e-476c-bb7b-78f743574a68@oss.nxp.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240912_042808_121293_33AE6D1F X-CRM114-Status: GOOD ( 32.59 ) 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 --2CwcanIC+v5LIFSS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 12, 2024 at 01:50:25PM +0300, Ciprian Marian Costea wrote: > On 9/11/2024 9:21 PM, Conor Dooley wrote: > > On Wed, Sep 11, 2024 at 10:00:25AM +0300, Ciprian Costea wrote: > > > From: Ciprian Marian Costea > > > + nxp,clksel: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: > > > + Input clock selector. Choose between 0-SIRC and 2-FIRC. > > > + The reason for these IDs not being consecutive is because > > > + they are hardware coupled. > > > + enum: > > > + - 0 # SIRC > > > + - 2 # FIRC > >=20 > > Could you please explain why, given both clocks must be provided by > > the hardware for there to be a choice, why choosing between them is a > > property of the hardware? > >=20 >=20 >=20 > According to RTC module's clocking scheme for S32G2/S32G3 SoCs, it has th= ree > potential clock sources to select between: > 1. FIRC: > - fast clock - ~48 MHz output > - chosen by default because it is proven to be more reliable (e.g: > temperature drift). > 2. SIRC: > - slow clock - ~32 kHz output > - When in Standby mode, SIRC_CLK is the only available clock for RTC. > This is important because RTC module is used as a wakeup source from Susp= end > to RAM on S32G2/S32G3 SoC. Therefore, a temporary switch to SIRC clock is > performed when entering Suspend to RAM. >=20 > 3. EXT_CLK: > - has not been tested/validated for those SoCs within NXP's downstream > Linux. Therefore, I did not treat it, nor mention it, for the moment. >=20 > Now to answer your question, all above clocks are entering a RTCC[CLKSEL] > (RTCC - RTC Control Register) mux. Therefore, a selection can be made, > according to one's needs. Given both clocks must be provided, what is the benefit of using the slow clock outside of standby mode? Why would someone not just always use the fast clock outside of standby and slow in standby? > I will add a shorter version of above information in the bindings > documentation in the V2 of this patchset. >=20 > > > + > > > + nxp,dividers: > > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > > + description: > > > + An array of two u32 elements, the former encoding DIV512, > > > + the latter encoding DIV32. These are dividers that can be enab= led > > > + individually, or cascaded. Use 0 to disable the respective div= ider, > > > + and 1 to enable it. > >=20 > > Please explain to me what makes this a property of the hardware and how > > someone would go about choosing the divider settings for their hardware. > >=20 >=20 > As per hardware RTC module clocking scheme, the output of the clock mux c= an > be optionally divided by a combination of 512 and 32 (via other two input > cascaded muxes) to give various count periods for different clock sources. >=20 > With respect to choosing the divider settings for custom hardware, it What do you mean by "custom" hardware? I assume that you mean on a per board basis? > depends on the clock source being selected and the desired rollover time. > For example, on S32G2 or S32G3 SoC based boards, using FIRC (~48-51 MHz) > with DIV512 enabled results in a rollover time of aprox. 13 hours. So a different user of the same board might want a different rollover time? If so, this doesn't really seem like something that should be controlled from devicetree. Cheers, Conor. --2CwcanIC+v5LIFSS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZuLQGgAKCRB4tDGHoIJi 0tEgAP99+nRC38H0f8hEmTD3u+9C+yaZTnWDwwyh7e4qtBLr+gD9EZom/+kmjZsN 6vIDaHsEjiJnlxxws/NntJUiMyrv6gY= =vCvM -----END PGP SIGNATURE----- --2CwcanIC+v5LIFSS--