Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1815605pxj; Sun, 30 May 2021 04:21:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzHewEEC4H6zfymp4KE3qhJysqpKebvqDC3pehdaMIQ6Mo7QMp4uf5Juph8JE6CLPjYpWiH X-Received: by 2002:aa7:d659:: with SMTP id v25mr20149210edr.271.1622373668889; Sun, 30 May 2021 04:21:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622373668; cv=none; d=google.com; s=arc-20160816; b=r5n9PoEm1O4PkQbdLLsWqhsdSIxWhzJ6Ll4komabrp+FjvvkZAeSxYKzZTMwhaIxQn bSvdCVMEXNRdGZ6F8PXhquK7UGhBOrdApNTuxecol8avDJD3UnfLkJSdjWmTPQm4Hnq4 InYuHsLn1XO98mMC/IJQU6eUB0uw5ylgXRVGTwcajQSupmHq0lBj6cdCIMa6rTZR4cSR e0fASgEpF45X9RxRfKUX2OhckBjvVT6O3OJxDH4eDRNRDNp4RJA31T8/s/r0HHQKqMMo WwOfmmfRozjZoifmmddBVss8TgoqMCQzs7glphQrQeZP61tlorxh1HhS+ZBVHCfmEMOu fxTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:cc:to:from:date:references:in-reply-to :message-id:mime-version:user-agent:dkim-signature:dkim-signature; bh=R8+AejtaKpmskYAJ9j9jx3ntGN+1fRarmXNGE36e9s0=; b=ht2Ojjed0+cHl1Q0D1OF9WzXY3xFIFpjE7QXrqfWr3AcbBtVrfnsvOtycLY4bXN9R/ t4QnwXxclM/PsGH1xAKjR8km00/xgCCabgOArHMfEwEH89FduamcdalI204NSq1w3ka/ pc9qoLJWW/hom/Vbfa9yNDMJMXSTJ7RSPHXH7B/dVAs1JLfTXT/rwdgrNoieVwtwVWgD +0tJ3UAbh8U5Mg+9XrrBHESNJ4Gb+wYguGMsvh9yDq8ECt7toM+JuE4UAXYdUD6cKJTO V9c82dw34g7+zh3RFfVGsWZOB1JjCjUwi6gyyda44vrETCQPikKAUkfNcTxNSyZrGUuP edmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@svenpeter.dev header.s=fm1 header.b=McgHRYtS; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=kLD+rNDG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=svenpeter.dev Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b6si11616937edu.115.2021.05.30.04.20.43; Sun, 30 May 2021 04:21:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@svenpeter.dev header.s=fm1 header.b=McgHRYtS; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=kLD+rNDG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=svenpeter.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229640AbhE3LTW (ORCPT + 99 others); Sun, 30 May 2021 07:19:22 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:49181 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229500AbhE3LTV (ORCPT ); Sun, 30 May 2021 07:19:21 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A8A6A5C011C; Sun, 30 May 2021 07:17:43 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute3.internal (MEProxy); Sun, 30 May 2021 07:17:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=svenpeter.dev; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=R8+AejtaKpmskYAJ9j9jx3ntGN+1 fRarmXNGE36e9s0=; b=McgHRYtSoGaCebrDcTgADWbVWoQLHu4AOiRnNYMltVdr /56mYHgP7QWA+h1W8QvcE1VXmMSRkA5UOeo7+NMR7TzIf4cNFkZoHpVYTWwAw/JB wy0jmVQJzyUcJNbR47clhgRmqLqz2JVfRHr1xiFwCEq/vgCOFmR9bzxSgY+WScll 0inhJ0IK8TF8gvc9Vj+KmEsaz6adgSmQKvzusYuOgW94kyUH5ttWADEPc9otC9Jy sUjD/+vhpGXno1nU0yI0FQ0ySAJll9KED9quG77pZG3bz8HcL75TQY1YwKv1uyBG KUvOiTiAWMlBBC0TcwKyGxSwLwXEr13dUDKNb7XvSA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=R8+Aej taKpmskYAJ9j9jx3ntGN+1fRarmXNGE36e9s0=; b=kLD+rNDGTVzkzNxrYIvrFg sjH7a063YAEzl1s4fKtmbGmZy/d7bSeeZTQ3StNngsu6dFFaoRm10Neinx1bSS03 RUC6L3gOf5mlPVTR2WHz141K4Hk9WY4Ou8CCk8i+n5MosgexLsgEHXBiZNwgETP4 gtJL9nlVH1RJP8sYe+H9TXpe0XH9KZbkXBJIO5046WPArGdsIW8ICDtIf4NWYQZI xv/6KezP0925TOJIBqIxOm+BtTOxq94CubFNm8+R55XQheaRvBF15dYp6eyw12ba erwkjXw+u2VV+z599QIdt/wkzUoCtNG6+q3yc1182WpiAYgY5FcY+Xj2N3P6uenw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeluddgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfuvhgv nhcurfgvthgvrhdfuceoshhvvghnsehsvhgvnhhpvghtvghrrdguvghvqeenucggtffrrg htthgvrhhnpefgieegieffuefhtedtjefgteejteefleefgfefgfdvvddtgffhffduhedv feekffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsvhgvnhesshhvvghnphgvthgvrhdruggvvh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 86DF151C0060; Sun, 30 May 2021 07:17:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-468-gdb53729b73-fm-20210517.001-gdb53729b Mime-Version: 1.0 Message-Id: In-Reply-To: <162199855335.4130789.17766958356597249549@swboyd.mtv.corp.google.com> References: <20210524182745.22923-1-sven@svenpeter.dev> <20210524182745.22923-3-sven@svenpeter.dev> <162199855335.4130789.17766958356597249549@swboyd.mtv.corp.google.com> Date: Sun, 30 May 2021 13:17:22 +0200 From: "Sven Peter" To: "Stephen Boyd" , devicetree@vger.kernel.org, linux-clk Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Hector Martin" , "Michael Turquette" , "Rob Herring" , "Mark Kettenis" , "Arnd Bergmann" Subject: Re: [PATCH 2/3] clk: add support for gate clocks on Apple SoCs Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Thanks for the review! On Wed, May 26, 2021, at 05:09, Stephen Boyd wrote: > Quoting Sven Peter (2021-05-24 11:27:44) > > Add a simple driver for gate clocks found on Apple SoCs. These don't > > have any frequency associated with them and are only used to enable > > access to MMIO regions of various peripherals. > > Can we figure out what frequency they are clocking at? > I don't think so. I've written some more details about how Apple uses the clocks in a reply to Rob, but the short version is that these clock gates are only used as on/off switches. There are separate clocks that actually have a frequency associated with them. > > > > Signed-off-by: Sven Peter > > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig > > index e80918be8e9c..ac987a8cf318 100644 > > --- a/drivers/clk/Kconfig > > +++ b/drivers/clk/Kconfig > > @@ -245,6 +245,18 @@ config CLK_TWL6040 > > McPDM. McPDM module is using the external bit clock on the McPDM bus > > as functional clock. > > > > +config COMMON_CLK_APPLE > > + tristate "Clock driver for Apple platforms" > > + depends on ARCH_APPLE && COMMON_CLK > > The COMMON_CLK depend is redundant. Please remove. Removed for v2. > > > + default ARCH_APPLE > > + help > > + Support for clock gates on Apple SoCs such as the M1. > > + > > + These clock gates do not have a frequency associated with them and > > + are only used to power on/off various peripherals. Generally, a clock > > + gate needs to be enabled before the respective MMIO region can be > > + accessed. > > + > > config COMMON_CLK_AXI_CLKGEN > > tristate "AXI clkgen driver" > > depends on HAS_IOMEM || COMPILE_TEST > > diff --git a/drivers/clk/clk-apple-gate.c b/drivers/clk/clk-apple-gate.c > > new file mode 100644 > > index 000000000000..799e9269758f > > --- /dev/null > > +++ b/drivers/clk/clk-apple-gate.c > > @@ -0,0 +1,152 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Apple SoC clock/power gating driver > > + * > > + * Copyright The Asahi Linux Contributors > > + */ > > + > > +#include > > Hopefully this can be droped. > > > +#include > > And this one too. clkdev is not modern. Okay, will remove both headers (and also fix any code that uses them). > > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define CLOCK_TARGET_MODE_MASK 0x0f > > APPLE_ prefix on all these? Fixed for v2. > > > +#define CLOCK_TARGET_MODE(m) (((m)&0xf)) > > +#define CLOCK_ACTUAL_MODE_MASK 0xf0 > > +#define CLOCK_ACTUAL_MODE(m) (((m)&0xf) << 4) > > + > > +#define CLOCK_MODE_ENABLE 0xf > > +#define CLOCK_MODE_DISABLE 0 > > + > > +#define CLOCK_ENDISABLE_TIMEOUT 100 > > + > > +struct apple_clk_gate { > > + struct clk_hw hw; > > + void __iomem *reg; > > +}; > > + > > +#define to_apple_clk_gate(_hw) container_of(_hw, struct apple_clk_gate, hw) > > + > > +static int apple_clk_gate_endisable(struct clk_hw *hw, int enable) > > +{ > > + struct apple_clk_gate *gate = to_apple_clk_gate(hw); > > + u32 reg; > > + u32 mode; > > + > > + if (enable) > > + mode = CLOCK_MODE_ENABLE; > > + else > > + mode = CLOCK_MODE_DISABLE; > > + > > + reg = readl(gate->reg); > > + reg &= ~CLOCK_TARGET_MODE_MASK; > > + reg |= CLOCK_TARGET_MODE(mode); > > + writel(reg, gate->reg); > > + > > + return readl_poll_timeout_atomic(gate->reg, reg, > > + (reg & CLOCK_ACTUAL_MODE_MASK) == > > + CLOCK_ACTUAL_MODE(mode), > > + 1, CLOCK_ENDISABLE_TIMEOUT); > > Maybe this > > return readl_poll_timeout_atomic(gate->reg, reg, > (reg & CLOCK_ACTUAL_MODE_MASK) == CLOCK_ACTUAL_MODE(mode), > 1, CLOCK_ENDISABLE_TIMEOUT); > > at the least please don't break the == across two lines. Ah, sorry. I ran clang-format at the end and didn't catch that line when I did my final review. I'll use your suggestion for v2. > > > +} > > + > > +static int apple_clk_gate_enable(struct clk_hw *hw) > > +{ > > + return apple_clk_gate_endisable(hw, 1); > > +} > > + > > +static void apple_clk_gate_disable(struct clk_hw *hw) > > +{ > > + apple_clk_gate_endisable(hw, 0); > > +} > > + > > +static int apple_clk_gate_is_enabled(struct clk_hw *hw) > > +{ > > + struct apple_clk_gate *gate = to_apple_clk_gate(hw); > > + u32 reg; > > + > > + reg = readl(gate->reg); > > + > > + if ((reg & CLOCK_ACTUAL_MODE_MASK) == CLOCK_ACTUAL_MODE(CLOCK_MODE_ENABLE)) > > Any chance we can use FIELD_GET() and friends? Please don't do bit > shifting stuff inside conditionals as it just makes life more > complicated than it needs to be. Absolutely, thanks for the hint. I didn't know about FIELD_GET and will use it for v2. > > > + return 1; > > + return 0; > > How about just return ? Good point, fixed for v2. > > > +} > > + > > +static const struct clk_ops apple_clk_gate_ops = { > > + .enable = apple_clk_gate_enable, > > + .disable = apple_clk_gate_disable, > > + .is_enabled = apple_clk_gate_is_enabled, > > +}; > > + > > +static int apple_gate_clk_probe(struct platform_device *pdev) > > +{ > > + struct device *dev = &pdev->dev; > > + struct device_node *node = dev->of_node; > > + const struct clk_parent_data parent_data[] = { > > + { .index = 0 }, > > + }; > > Yay thanks for not doing it the old way! :) > > > + struct apple_clk_gate *data; > > + struct clk_hw *hw; > > + struct clk_init_data init; > > + struct resource *res; > > + int num_parents; > > + int ret; > > + > > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL); > > + if (!data) > > + return -ENOMEM; > > + > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > + data->reg = devm_ioremap_resource(dev, res); > > + if (IS_ERR(data->reg)) > > + return PTR_ERR(data->reg); > > + > > + num_parents = of_clk_get_parent_count(node); > > Oh no I spoke too soon. :( Sorry, will fix it for v2 to use the new way. > > > + if (num_parents > 1) { > > + dev_err(dev, "clock supports at most one parent\n"); > > + return -EINVAL; > > + } > > + > > + init.name = dev->of_node->name; > > + init.ops = &apple_clk_gate_ops; > > + init.flags = 0; > > + init.parent_names = NULL; > > + init.parent_data = parent_data; > > + init.num_parents = num_parents; > > + > > + data->hw.init = &init; > > + hw = &data->hw; > > + > > + ret = devm_clk_hw_register(dev, hw); > > + if (ret) > > + return ret; > > + > > + return devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get, hw); > > It looks like a one clk per DT node binding which is not how we do it. I > see Rob has started that discussion on the binding so we can keep that > there. > > > +} > > + > Thanks, Sven