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 72EDDE99068 for ; Fri, 10 Apr 2026 09:50:19 +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:References:From: Subject:Cc:To:Message-Id:Date:Content-Type:Content-Transfer-Encoding: Mime-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=4UotVkU/wCIPZVHZquY/z63H5AYQdFj3m1KFqxdTFcU=; b=GbnEawVxBkCUqf8XsLxKQKPLfS grOe/TjwSEg7GkFXIFwR+7CuUMroFlGTs8sXJSV5ozCpWNx0VcPqShZ0LXEYFuomKXcz8nsg6cvu2 Ysugu6RWxedO/CdPxs4iiSnZjbskmEcCIaus8THZP5nwza6U56yz+RHsFLf0Q4LdPaXFaIkZHwoY/ 3mRpnkJVvFvl7eCKIgZKHeg0/PgLITUxvX/olemfTx+C03knFEa9Pro5X0BRSgnef5mJIt/+p5uA4 e19DyGTCtpja4Wkymc6yY58UM2ffO5HLSjCo9Ex1gksH7Wkm4O9u2JEgqlHiKSzKhX4uTvmfKdWP5 QEi37U9g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wB8VA-0000000Bwot-2VM5; Fri, 10 Apr 2026 09:50:12 +0000 Received: from sender4-op-o12.zoho.com ([136.143.188.12]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1wB8V7-0000000BwoH-3ncv for linux-arm-kernel@lists.infradead.org; Fri, 10 Apr 2026 09:50:11 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1775814601; cv=none; d=zohomail.com; s=zohoarc; b=ajm8KCOZ3HTSDSoPDZoE9w9U5kzebIqYrtN6aM24IPDwBP+TYeGwp0aaBR/8epFs2/NTYEhCHH6CG2HdePepR0/51RRwdJJLLoI5fYYwVEyXQdZxVQxLnoJ+x3ZBwhhcQAh7LtHQYx0tFdVlapJi3GvNBjDJyCgL6XbP2079oHg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1775814601; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=4UotVkU/wCIPZVHZquY/z63H5AYQdFj3m1KFqxdTFcU=; b=IYAN6kqC9G0aFn3AfYs3yQN8xhF9F6n4oVvHq8uQtDLcgyuqPV/CP+PBAGoXVyWm1bkSwZ5kOi4KRqbd5DMeMdkZsrOdRfFpGzW5ZE+ACZbui78IoKj1aQowRFnKcHCoF33FCWKSuI+j35weNE3IM5e3IUU2qhmN5Lm0MDb3azM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=pigmoral.tech; spf=pass smtp.mailfrom=junhui.liu@pigmoral.tech; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1775814601; s=zmail; d=pigmoral.tech; i=junhui.liu@pigmoral.tech; h=Mime-Version:Content-Transfer-Encoding:Content-Type:Date:Date:Message-Id:Message-Id:To:To:Cc:Cc:Subject:Subject:From:From:References:In-Reply-To:Reply-To; bh=4UotVkU/wCIPZVHZquY/z63H5AYQdFj3m1KFqxdTFcU=; b=AC0lYtKuynwcFp+hCP1+ChfvSQzvoDauSKvDDBVq8N6ciLoj7X4J22S1lLYGpInz NhTXFOg9erWKcx8Msb/+lNLn60PANj2OYboXlrDFu2Kv18aIDl1HREDceAtFV3FACNa OK/X9IZk2rSw6+W7BRHMdJFwXWocQRagvFnv4ACk= Received: by mx.zohomail.com with SMTPS id 1775814599395110.49786561844996; Fri, 10 Apr 2026 02:49:59 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 10 Apr 2026 17:49:49 +0800 Message-Id: To: , "Junhui Liu" Cc: "Michael Turquette" , "Stephen Boyd" , "Jernej Skrabec" , "Samuel Holland" , "Alexandre Belloni" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Maxime Ripard" , , , , , , , =?utf-8?q?Andr=C3=A9_Przywara?= Subject: Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support From: "Junhui Liu" X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260121-a733-rtc-v1-0-d359437f23a7@pigmoral.tech> <20260121-a733-rtc-v1-7-d359437f23a7@pigmoral.tech> In-Reply-To: X-ZohoMailClient: External X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260410_025010_351584_D96F90FB X-CRM114-Status: GOOD ( 30.54 ) 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 Sat Mar 28, 2026 at 10:41 PM CST, Chen-Yu Tsai wrote: > On Wed, Jan 21, 2026 at 7:04=E2=80=AFPM Junhui Liu wrote: >> >> Add support for the internal CCU found in the RTC module of the Allwinne= r >> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatibl= e >> with older SoCs like the sun6i, the A733 introduces several new features= . >> >> The A733 RTC CCU supports choosing one of three external crystal >> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection >> logic to automatically identify the frequency used on the board and >> exports this DCXO signal as the "hosc" clock. >> >> Furthermore, the driver implements logic to derive a 32kHz reference >> from the HOSC. This is achieved through a muxed clock path using fixed >> pre-dividers to normalize the different crystal frequencies to ~32kHz. > > Have you tested whether the actually normalizes the frequency, i.e. > selects a different divider based on the DCXO frequency? Otherwise > we're just lying about the frequency. I only have A733 boards with 26MHz crystals, so I couldn't test all crystal configurations. However, I exported the "hosc_32k" clock (referred to as dcxo24M_div32k_clk in the vendor driver) to a physical pin via the fanout path and measured it with the oscilloscope. Observations: - Normal conditions: The frequency remains stable within the 32.744 kHz to 32.791 kHz range. - Forced condition: I grounded the R24 resistor on radxa A7A board to trick the SoC into detecting a 24MHz crystal while the actual input remained 26MHz. In this case, the frequency became unstable but still stayed around the 32.2 kHz to 33.3 kHz range. Based on these results, it appears the hardware does attempt to normalize the frequency towards 32.768 kHz via some internal logic. > >> This path reuses the same hardware mux registers as the HOSC clock. >> >> Additionally, this CCU provides several gate clocks for specific >> peripherals, including SerDes, HDMI, and UFS. The driver is implemented >> as an auxiliary driver to be bound to the sun6i-rtc driver. >> >> Signed-off-by: Junhui Liu >> --- >> drivers/clk/sunxi-ng/Kconfig | 5 + >> drivers/clk/sunxi-ng/Makefile | 2 + >> drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.c | 204 ++++++++++++++++++++++= +++++++ >> drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.h | 18 +++ >> drivers/clk/sunxi-ng/ccu_rtc.h | 7 + >> 5 files changed, 236 insertions(+) >> [...] >> + >> +static const struct clk_parent_data hosc_parents[] =3D { >> + { .fw_name =3D "osc24M" }, >> + { .fw_name =3D "osc19M" }, >> + { .fw_name =3D "osc26M" }, >> + { .fw_name =3D "osc24M" }, >> +}; > > As mentioned in my reply to the binding, this is wrong. There is only > one input. > > The most you can do is check the rate of the parent clock against the > detected one, and _scream_ that the DT is wrong. And maybe override > the reported frequency. I will add a warning message if the frequency detected by the driver does not match the one in the DT. > > If you want to do the latter, you could add a new fixed rate gated > clock type to our library. You would fill in the rate before the > clocks get registered. I probably wouldn't go that far. We want people > to have correct hardware descriptions. > > Funnily enough Allwinner's BSP actually implements a fixed rate gate > for the next 24M-to-32k divider clock. Yes, I noticed that as well. I agree, and I will model this path as a simple fixed-rate clock (32768Hz) in v2. > >> + >> +struct ccu_mux hosc_clk =3D { >> + .enable =3D DCXO_CTRL_DCXO_EN, >> + .mux =3D _SUNXI_CCU_MUX(14, 2), >> + .common =3D { >> + .reg =3D DCXO_CTRL_REG, >> + .hw.init =3D CLK_HW_INIT_PARENTS_DATA("hosc", >> + hosc_parents, >> + &ccu_mux_ro_o= ps, >> + 0), >> + }, >> +}; > > So this is wrong. > >> + >> +static const struct ccu_mux_fixed_prediv hosc_32k_predivs[] =3D { >> + { .index =3D 0, .div =3D 732 }, > > Why is it 732 instead of 750? As mentioned above, the target frequency is 32.768kHz rather than 32.0kHz. However, since I will drop this prediv array and use a fixed-rate clock instead, I think this will no longer be an issue. --=20 Best regards, Junhui Liu