From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from unicorn.mansr.com (unicorn.mansr.com [81.2.72.234]) (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 517ECA23 for ; Wed, 28 Jun 2023 11:08:05 +0000 (UTC) Received: from raven.mansr.com (raven.mansr.com [81.2.72.235]) by unicorn.mansr.com (Postfix) with ESMTPS id 0B96E15360; Wed, 28 Jun 2023 12:07:57 +0100 (BST) Received: by raven.mansr.com (Postfix, from userid 51770) id 81069219FD1; Wed, 28 Jun 2023 12:07:56 +0100 (BST) From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Maxime Ripard Cc: Samuel Holland , Chen-Yu Tsai , Jernej Skrabec , linux-sunxi@lists.linux.dev, Michael Turquette , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Stephen Boyd , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 3/4] clk: sunxi-ng: Convert early providers to platform drivers References: <20211119033338.25486-1-samuel@sholland.org> <20211119033338.25486-4-samuel@sholland.org> Date: Wed, 28 Jun 2023 12:07:56 +0100 In-Reply-To: (Maxime Ripard's message of "Wed, 28 Jun 2023 09:44:18 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Maxime Ripard writes: > On Mon, Jun 26, 2023 at 01:21:33PM +0100, M=E5ns Rullg=E5rd wrote: >> Samuel Holland writes: >>=20 >> > The PRCM CCU drivers depend on clocks provided by other CCU drivers. F= or >> > example, the sun8i-r-ccu driver uses the "pll-periph" clock provided by >> > the SoC's main CCU. >> > >> > However, sun8i-r-ccu is an early OF clock provider, and many of the >> > main CCUs (e.g. sun50i-a64-ccu) use platform drivers. This means that >> > the consumer clocks will be orphaned until the supplier driver is boun= d. >> > This can be avoided by converting the remaining CCUs to use platform >> > drivers. Then fw_devlink will ensure the drivers are bound in the >> > optimal order. >> > >> > The sun5i CCU is the only one which actually needs to be an early clock >> > provider, because it provides the clock for the system timer. That one >> > is left alone. >> > >> > Signed-off-by: Samuel Holland >> > --- >> > >> > (no changes since v1) >> > >> > drivers/clk/sunxi-ng/Kconfig | 20 ++++---- >> > drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 58 +++++++++++++-------- >> > drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 56 ++++++++++++-------- >> > drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 33 ++++++++---- >> > drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 40 +++++++++++---- >> > drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 35 +++++++++---- >> > drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 40 +++++++++++---- >> > drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 62 ++++++++++++++-------- >> > drivers/clk/sunxi-ng/ccu-sun8i-r.c | 65 ++++++++++++++---------- >> > drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 57 +++++++++++++-------- >> > drivers/clk/sunxi-ng/ccu-suniv-f1c100s.c | 38 ++++++++++---- >> > 11 files changed, 332 insertions(+), 172 deletions(-) >>=20 >> This broke the hstimer clocksource on A20 since it requires a clock >> provided by the sun4i ccu driver. > > The A10 is probably broken by this, but the A20 should be able to use > the arch timers just like all the other Cortex-A7-based SoCs. > > Do you have a dmesg log that could help debug why it's not working? The A20 works as such since, as you say, it has other clocksources. However, the hstimer has become unusable. If anyone was using, for whatever reason, it won't be working for them now. Before this change, the kernel log used include this line: clocksource: hstimer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:= 6370868154 ns Now there is only a cryptic "Can't get timer clock" in its place. As it is now, the hstimer driver is nothing but a waste of space. I figure it ought to be fixed one way or another. --=20 M=E5ns Rullg=E5rd