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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46236EB64D7 for ; Wed, 28 Jun 2023 18:33:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230496AbjF1Sdn convert rfc822-to-8bit (ORCPT ); Wed, 28 Jun 2023 14:33:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232062AbjF1Sdj (ORCPT ); Wed, 28 Jun 2023 14:33:39 -0400 X-Greylist: delayed 26739 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 28 Jun 2023 11:33:37 PDT Received: from unicorn.mansr.com (unicorn.mansr.com [IPv6:2001:8b0:ca0d:1::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81C1E1FCC; Wed, 28 Jun 2023 11:33:37 -0700 (PDT) Received: from raven.mansr.com (raven.mansr.com [IPv6:2001:8b0:ca0d:1::3]) by unicorn.mansr.com (Postfix) with ESMTPS id 2509F15360; Wed, 28 Jun 2023 19:33:35 +0100 (BST) Received: by raven.mansr.com (Postfix, from userid 51770) id 17DD3219FD1; Wed, 28 Jun 2023 19:33:35 +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 19:33:35 +0100 In-Reply-To: (Maxime Ripard's message of "Wed, 28 Jun 2023 13:41:30 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Maxime Ripard writes: > On Wed, Jun 28, 2023 at 12:07:56PM +0100, Måns Rullgård wrote: >> Maxime Ripard writes: >> >> > On Mon, Jun 26, 2023 at 01:21:33PM +0100, Måns Rullgård wrote: >> >> Samuel Holland writes: >> >> >> >> > The PRCM CCU drivers depend on clocks provided by other CCU drivers. For >> >> > 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 bound. >> >> > 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(-) >> >> >> >> 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. > > Yeah, definitely. > > IIRC, the situation is: > > - A10 has just the "regular", old, timer > - A10s/A13/GR8 has the A10 timer + hstimer > - A20 has the A13 timers + arch timers > > We also default to the hstimer only for the A10s/A13 which aren't > affected by this patch series afaics. > > We also enable the HS timer for the A31, but just like the A20 it > doesn't use it by default, so it's probably been broken there too. > > I guess one way to fix it would be to switch the HS timer driver to a > lower priority than the A10 timer, so we pick that up by default instead > for the A10s/A13, and then convert the HS timer driver to a proper > platform_device driver that will be able to get its clock. > > The downside is that the A13 will lose some precision over its default > timer, but I don't think it's a big deal. The options I see are converting the hstimer to a platform device or reverting the change to the sun4i ccu driver. I don't personally have much of an opinion on this since my systems aren't affected. The only reason I looked at it was that I noticed a new error message in the kernel logs. -- Måns Rullgård 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 D9E34EB64D7 for ; Wed, 28 Jun 2023 18:34:12 +0000 (UTC) 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:Message-ID:In-Reply-To: Date:References:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lT5wIZLXZ5aPJVNtCvO45SFATELS/szsDAjCI7vz3uE=; b=YYb1flkKZi/Q1j ofnMw9CN+P52WyQqVg2ycbbBhb+R9/On67veqCLbNtR0xsmzu2fNj4R2bglrJHB4ThzLLp1AbaUkb iIwp8eW1491tITyzqFI4YDftMHC1HAaISz7a/dZc4ovv+mGQdxTwds7aPc4wSl5mgODtCvJcZg1PC YmLjMbrgZ45AY/8bGAY7dSHcTKm//a/R964czrYQ/D23noSky714gnqapAGvVOCCuq+l4jSlsL+N1 3fNZ/RV8PQUyyFMO95sUo3+X6295+ldC1bQUZZFpHsNzyDRXqvH0pHR0TJlYyhIILtIdwKOtlErGd wji8Pa773Ycfa5H68lkA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qEZz4-00GPCB-2X; Wed, 28 Jun 2023 18:33:42 +0000 Received: from unicorn.mansr.com ([2001:8b0:ca0d:1::2]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qEZz2-00GPBF-0u for linux-arm-kernel@lists.infradead.org; Wed, 28 Jun 2023 18:33:41 +0000 Received: from raven.mansr.com (raven.mansr.com [IPv6:2001:8b0:ca0d:1::3]) by unicorn.mansr.com (Postfix) with ESMTPS id 2509F15360; Wed, 28 Jun 2023 19:33:35 +0100 (BST) Received: by raven.mansr.com (Postfix, from userid 51770) id 17DD3219FD1; Wed, 28 Jun 2023 19:33:35 +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 19:33:35 +0100 In-Reply-To: (Maxime Ripard's message of "Wed, 28 Jun 2023 13:41:30 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230628_113340_472115_B9979D39 X-CRM114-Status: GOOD ( 39.52 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Maxime Ripard writes: > On Wed, Jun 28, 2023 at 12:07:56PM +0100, M=E5ns Rullg=E5rd wrote: >> Maxime Ripard writes: >> = >> > On Mon, Jun 26, 2023 at 01:21:33PM +0100, M=E5ns Rullg=E5rd wrote: >> >> Samuel Holland writes: >> >> = >> >> > The PRCM CCU drivers depend on clocks provided by other CCU drivers= . For >> >> > example, the sun8i-r-ccu driver uses the "pll-periph" clock provide= d 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 th= at >> >> > the consumer clocks will be orphaned until the supplier driver is b= ound. >> >> > 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 c= lock >> >> > 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(-) >> >> = >> >> 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. > > Yeah, definitely. > > IIRC, the situation is: > > - A10 has just the "regular", old, timer > - A10s/A13/GR8 has the A10 timer + hstimer > - A20 has the A13 timers + arch timers > > We also default to the hstimer only for the A10s/A13 which aren't > affected by this patch series afaics. > > We also enable the HS timer for the A31, but just like the A20 it > doesn't use it by default, so it's probably been broken there too. > > I guess one way to fix it would be to switch the HS timer driver to a > lower priority than the A10 timer, so we pick that up by default instead > for the A10s/A13, and then convert the HS timer driver to a proper > platform_device driver that will be able to get its clock. > > The downside is that the A13 will lose some precision over its default > timer, but I don't think it's a big deal. The options I see are converting the hstimer to a platform device or reverting the change to the sun4i ccu driver. I don't personally have much of an opinion on this since my systems aren't affected. The only reason I looked at it was that I noticed a new error message in the kernel logs. -- = M=E5ns Rullg=E5rd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel