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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 670F0C47096 for ; Sun, 6 Jun 2021 05:59:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 467D1613F3 for ; Sun, 6 Jun 2021 05:59:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230099AbhFFGBQ (ORCPT ); Sun, 6 Jun 2021 02:01:16 -0400 Received: from muru.com ([72.249.23.125]:36958 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229504AbhFFGBP (ORCPT ); Sun, 6 Jun 2021 02:01:15 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 6A9FC80E5; Sun, 6 Jun 2021 05:59:31 +0000 (UTC) Date: Sun, 6 Jun 2021 08:59:20 +0300 From: Tony Lindgren To: Sven Peter Cc: Rob Herring , devicetree@vger.kernel.org, linux-clk , linux-arm-kernel , "linux-kernel@vger.kernel.org" , Hector Martin , Michael Turquette , Stephen Boyd , Mark Kettenis , Arnd Bergmann Subject: Re: [PATCH 0/3] Apple M1 clock gate driver Message-ID: References: <20210524182745.22923-1-sven@svenpeter.dev> <9ff6ec26-4b78-4684-9c23-16d5cbfef857@www.fastmail.com> <1ff54382-7137-49d6-841d-318e400e956e@www.fastmail.com> <02176203-7f29-4ff4-933b-70235cf0dd22@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02176203-7f29-4ff4-933b-70235cf0dd22@www.fastmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Sven Peter [210605 12:13]: > Hi Tony, > > On Fri, Jun 4, 2021, at 09:43, Tony Lindgren wrote: > > Hi, > > > > How about the following where you set up the gate clocks as separate > > child nodes: > > > > pmgr0: clock-controller@23b700000 { > > compatible = "apple,foo-clock-controller"; > > #clock-cells = <1>; > > reg = <0x2 0x3b700000 0x0 0x4000>; > > > > clk_uart0: clock@270 { > > compatible = "apple,t8103-gate-clock"; > > #clock-cells = <0>; > > assigned-clock-parents = <&pmgr0 APPLE_CLK_SIO>, > > <&pmgr0 APPLE_CLK_UART_P>; > > // ... > > }; > > > > }; > > > > Keep the clock controller still addressable by offset from base as discussed, > > and additionally have the driver parse and set up the child node clocks. > > Nice, I like that one even better! We can keep the internal clocks "hidden" > inside the parent node and only need to model the actual consumer clocks > as separate nodes. I guess the child nodes could also use just a clocks property above instead of assigned-clock related properties if there are no configurable source clock mux registers. > Are you aware of any clock driver that implements something similar? > I'd like to avoid reinventing the wheel if it's already been done before. I'm only aware of a partial implementation so far :) The "offset from clock controller base" approach has worked well for the TI clkctrl clocks. The clkctrl gate clocks still have the SoC specific source clock data build into the clock driver(s). That's the Documentation/devicetree/bindings/clock/ti-clkctrl.txt binding. For the clkctrl clocks, the SoC specific source clock data is in drivers/clk/ti/clk-*.c files. With the Apple dtb describing the gate clock parents, you might be able to leave out most of the SoC specific built-in driver data sounds like. Regards, Tony 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 50996C47096 for ; Sun, 6 Jun 2021 06:03:52 +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 18C25613DF for ; Sun, 6 Jun 2021 06:03:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18C25613DF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomide.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@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:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=RtfaMSbhhBnxMA5jo8U73a2qKicR34NWjR8c3no6rVU=; b=VBwGMo/Lb3USWw 9HIlsN6u2JV2jT20rhKuAyutfQRjTWykykHSaV/ZO173uSLcujWBsg1MGht99dBeQEfKsocr0PVpI TwG++RVbSdmBYQbj12zZw0khJDfbVKbNc4TJ1vsngWzhCNEdiDLiqwOH9D7x1RiuH+E00hrzW4bys vT2rk46HvZDlb3I9kYEu+rviu9z7wZeSlo9wwLfKV+Sz2v1vN+WsmD7koyz9ewubzLncj3EBkyV+g WWzzhK9KS2dRv1nz31k/rlyAjwEGRpZNW0XZD1u4wZ2XSKN0qCyTrJo3R699cpLzU0dBDBA7NIEN7 QaPcU1PBngGSxflpxKZg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lplop-00HTsK-Jm; Sun, 06 Jun 2021 05:59:31 +0000 Received: from muru.com ([72.249.23.125]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lplom-00HTrV-78 for linux-arm-kernel@lists.infradead.org; Sun, 06 Jun 2021 05:59:29 +0000 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 6A9FC80E5; Sun, 6 Jun 2021 05:59:31 +0000 (UTC) Date: Sun, 6 Jun 2021 08:59:20 +0300 From: Tony Lindgren To: Sven Peter Cc: Rob Herring , devicetree@vger.kernel.org, linux-clk , linux-arm-kernel , "linux-kernel@vger.kernel.org" , Hector Martin , Michael Turquette , Stephen Boyd , Mark Kettenis , Arnd Bergmann Subject: Re: [PATCH 0/3] Apple M1 clock gate driver Message-ID: References: <20210524182745.22923-1-sven@svenpeter.dev> <9ff6ec26-4b78-4684-9c23-16d5cbfef857@www.fastmail.com> <1ff54382-7137-49d6-841d-318e400e956e@www.fastmail.com> <02176203-7f29-4ff4-933b-70235cf0dd22@www.fastmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <02176203-7f29-4ff4-933b-70235cf0dd22@www.fastmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210605_225928_326720_935CCF82 X-CRM114-Status: GOOD ( 18.97 ) 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 * Sven Peter [210605 12:13]: > Hi Tony, > > On Fri, Jun 4, 2021, at 09:43, Tony Lindgren wrote: > > Hi, > > > > How about the following where you set up the gate clocks as separate > > child nodes: > > > > pmgr0: clock-controller@23b700000 { > > compatible = "apple,foo-clock-controller"; > > #clock-cells = <1>; > > reg = <0x2 0x3b700000 0x0 0x4000>; > > > > clk_uart0: clock@270 { > > compatible = "apple,t8103-gate-clock"; > > #clock-cells = <0>; > > assigned-clock-parents = <&pmgr0 APPLE_CLK_SIO>, > > <&pmgr0 APPLE_CLK_UART_P>; > > // ... > > }; > > > > }; > > > > Keep the clock controller still addressable by offset from base as discussed, > > and additionally have the driver parse and set up the child node clocks. > > Nice, I like that one even better! We can keep the internal clocks "hidden" > inside the parent node and only need to model the actual consumer clocks > as separate nodes. I guess the child nodes could also use just a clocks property above instead of assigned-clock related properties if there are no configurable source clock mux registers. > Are you aware of any clock driver that implements something similar? > I'd like to avoid reinventing the wheel if it's already been done before. I'm only aware of a partial implementation so far :) The "offset from clock controller base" approach has worked well for the TI clkctrl clocks. The clkctrl gate clocks still have the SoC specific source clock data build into the clock driver(s). That's the Documentation/devicetree/bindings/clock/ti-clkctrl.txt binding. For the clkctrl clocks, the SoC specific source clock data is in drivers/clk/ti/clk-*.c files. With the Apple dtb describing the gate clock parents, you might be able to leave out most of the SoC specific built-in driver data sounds like. Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel