Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp1231356rwp; Thu, 13 Jul 2023 08:01:45 -0700 (PDT) X-Google-Smtp-Source: APBJJlHejunAt6kEmwLepor7fziacoBj162EEub8qlgAfL05batQcpEzy27eB3436yERrCf6ZfHt X-Received: by 2002:a05:6a20:8e28:b0:12f:eb73:fc64 with SMTP id y40-20020a056a208e2800b0012feb73fc64mr1429991pzj.51.1689260504647; Thu, 13 Jul 2023 08:01:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689260504; cv=none; d=google.com; s=arc-20160816; b=ZK43Ruqd1VPvAXbPrEipbSr05ITDO8701oFNZGSuIveNtMJbNtetS4OTArlReoGD5r 3j7OGpwIF2/Ve4B4k7eEof2RVI+vOpc+hYp75y6YnGK2N2fcthAXcl3GofVpFU5/Twdi MAPLfG3/eoPWhY5/QnUX78hCqRfTl/LtkfnY+ZmfSPL6aU0liDLiZDNabN5oB3lx+aA5 g+C0Dww5Q3hfgYE9QFa0HycxjUyrBtFAeQ8K0gQKNNdfnltwGpj1CVhIeRBc7gULnjEq J0YOpT5DEKLK8yW8JbBKFjOdt85j0d2gjYyKFIuRpd530BDg3+MdjjLiyea/Ikf6F4TG f0TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=yxJReeu3wFsDEIoI+Y5EvxsHxuUj1xvYudc1q2Ogc0w=; fh=yrQkxyr8jSI8BF4OtbS2a/TFxwuANMHOfIHi5Q50Gus=; b=CTg6PFT40f6GqCb3Myt4MBtHacgF4ccAcyzmZzW1UkPKpuh2irTnWGNJR0osaRNikG r7va6i+2ozmgVDc7Se2oC9Hs1+DaLBIHcAw215Z02lSEpI40C/ZAXUuz4DTZ+O98+dzF rIQR3Tdh9NUf+nwf85BtjRFvT8jc1KJzjXCig2fxFItsHKP3j7itH0kJYTdKzHPDraG+ ilBWK33KVCiIixF2v9OvzWXioOiRtLWCvwsAvLP9xomyU6ZhVHCNfHchwYp/ytz9M+fH DhNp+/fU6nonrtIlkzvutvesi6FbtnveAPDKod8HB/O1XpY+E4Ts3/+R6cpgLRazpPC+ FTKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@edgeble-ai.20221208.gappssmtp.com header.s=20221208 header.b=ond3ynwi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r29-20020a63205d000000b005307d9f387esi5075218pgm.536.2023.07.13.08.01.30; Thu, 13 Jul 2023 08:01:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@edgeble-ai.20221208.gappssmtp.com header.s=20221208 header.b=ond3ynwi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231777AbjGMOzZ (ORCPT + 99 others); Thu, 13 Jul 2023 10:55:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229689AbjGMOzY (ORCPT ); Thu, 13 Jul 2023 10:55:24 -0400 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51BEC2712 for ; Thu, 13 Jul 2023 07:55:15 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-cb19b1b9a36so759739276.0 for ; Thu, 13 Jul 2023 07:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=edgeble-ai.20221208.gappssmtp.com; s=20221208; t=1689260114; x=1691852114; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yxJReeu3wFsDEIoI+Y5EvxsHxuUj1xvYudc1q2Ogc0w=; b=ond3ynwi15WishNDTT+qMQTWpC87sA93J5YINYb/UQxMxZtD2l81f0u58lE6VXbpVk m2eTgHMocycV9opUSB5jzMXo+QW9SIxbmRfv10fDXTK8UDHm+sskKWUAfchlIaw4ZYiZ 0+f7et0pRsFrjwhnRPex2rRL6iL6jfER52dp3tUGBJBYUoYrqYSq4j+SaQQgN0gUzSMJ p0u3HaguYLLz+bv2OZZ2NiBHKAjs6dHJ/X8v7bwJFIBwQbrewTqiEegnqlPaWnASV/Kt zASovpdUT8U93pGjLTEtpB10OsfBHfnxvuG2RF35LhZmgSrefjNNE0gH/J/BZd5QKk9D Wb+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689260114; x=1691852114; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yxJReeu3wFsDEIoI+Y5EvxsHxuUj1xvYudc1q2Ogc0w=; b=c+HZh85GHJv2iCcSFDkNXTSPEqAByOmztjlsgSDtxxsQ0e9VBKu/Y961ox1iJrCet4 zDYAkdUS0KccZ084VcM+bi9omC8UwB8od/pFteokURaJNu8JX+KZRBjDvbjbZH/qRdWx IEi2rXPMKFQ4RZgJ+IRVkxI2RLKC0DIWmGr6irdqQpIygoIxKvMW5XpK5k3CjE4o6Co1 f4Z+kKlf4DFXIffJXUeR06tH/9oJF4ibx3ecWKH9086Vkai156vkF2jA22MC4XYGga82 oLSf5v0pco3lrxWLdnLSLklCeaB9122fPEOSWVnarBBuOAdzIW87jDTWvXgCwHOwYJo7 2R5A== X-Gm-Message-State: ABy/qLZkDFqEVZxbka0BDn2m1eS0c8q9603olCSHxINXItO9C2Yc66yG 6dN74YwQKk6DonE2/NkGtcRdEIRyPkjhWAEvgWMMwg== X-Received: by 2002:a25:c0c8:0:b0:c4f:43d7:7daf with SMTP id c191-20020a25c0c8000000b00c4f43d77dafmr1442561ybf.1.1689260114481; Thu, 13 Jul 2023 07:55:14 -0700 (PDT) MIME-Version: 1.0 References: <20230403193250.108693-1-sebastian.reichel@collabora.com> <20230403193250.108693-2-sebastian.reichel@collabora.com> In-Reply-To: <20230403193250.108693-2-sebastian.reichel@collabora.com> From: Jagan Teki Date: Thu, 13 Jul 2023 20:25:03 +0530 Message-ID: Subject: Re: [PATCHv2 1/2] clk: rockchip: rk3588: make gate linked clocks ignore unused To: Sebastian Reichel Cc: Heiko Stuebner , linux-rockchip@lists.infradead.org, Peter Geis , Elaine Zhang , Finley Xiao , Michael Turquette , Stephen Boyd , Boris Brezillon , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel@collabora.com, Vincent Legoll Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sebastian, On Tue, 4 Apr 2023 at 01:03, Sebastian Reichel wrote: > > RK3588 has a couple of hardware blocks called Native Interface Unit > (NIU) that gate the clocks to devices behind them. Effectively this > means that some clocks require two parent clocks being enabled. > Downstream implemented this by using a separate clock driver > ("clk-link") for them, which enables the second clock using PM > framework. > > In the upstream kernel we are currently missing support for the second > parent. The information about it is in the GATE_LINK() macro as > linkname, but that is not used. Thus the second parent clock is not > properly enabled. So far this did not really matter, since these clocks > are mostly required for the more advanced IP blocks, that are not yet > supported upstream. As this is about to change we need a fix. There > are three options available: > > 1. Properly implement support for having two parent clocks in the > clock framework. > 2. Mark the affected clocks CLK_IGNORE_UNUSED, so that they are not > disabled. This wastes some power, but keeps the hack contained > within the clock driver. Going from this to the first solution > is easy once that has been implemented. > 3. Enabling the extra clock in the consumer driver. This leaks some > implementation details into DT. > > This patch implements the second option as an intermediate solution > until the first one is available. I used an alias for CLK_IS_CRITICAL, > so that it's easy to see which clocks are not really critical once > the clock framework supports a better way to implement this. > > Tested-by: Vincent Legoll > Signed-off-by: Sebastian Reichel > --- > drivers/clk/rockchip/clk-rk3588.c | 42 +++++++++++++++++++------------ > 1 file changed, 26 insertions(+), 16 deletions(-) > > diff --git a/drivers/clk/rockchip/clk-rk3588.c b/drivers/clk/rockchip/clk-rk3588.c > index b7ce3fbd6fa6..6994165e0395 100644 > --- a/drivers/clk/rockchip/clk-rk3588.c > +++ b/drivers/clk/rockchip/clk-rk3588.c > @@ -13,15 +13,25 @@ > #include "clk.h" > > /* > - * GATE with additional linked clock. Downstream enables the linked clock > - * (via runtime PM) whenever the gate is enabled. The downstream implementation > - * does this via separate clock nodes for each of the linked gate clocks, > - * which leaks parts of the clock tree into DT. It is unclear why this is > - * actually needed and things work without it for simple use cases. Thus > - * the linked clock is ignored for now. > + * Recent Rockchip SoCs have a new hardware block called Native Interface > + * Unit (NIU), which gates clocks to devices behind them. These effectively > + * need two parent clocks. > + * > + * Downstream enables the linked clock via runtime PM whenever the gate is > + * enabled. This implementation uses separate clock nodes for each of the > + * linked gate clocks, which leaks parts of the clock tree into DT. > + * > + * The GATE_LINK macro instead takes the second parent via 'linkname', but > + * ignores the information. Once the clock framework is ready to handle it, the > + * information should be passed on here. But since these clocks are required to > + * access multiple relevant IP blocks, such as PCIe or USB, we mark all linked > + * clocks critical until a better solution is available. This will waste some > + * power, but avoids leaking implementation details into DT or hanging the > + * system. > */ Does it mean the clk-link topology in the downstream kernel can be reused the same as normal clock notation? For example, I'm trying to add HCLK_VO1 directly to VO1 syscon instead of routing to pclk_vo1_grf(done downstream) vo1_grf: syscon@fd5a8000 { compatible = "rockchip,rk3588-vo-grf", "syscon"; reg = <0x0 0xfd5a8000 0x0 0x100>; clocks = <&cru HCLK_VO1>; }; This seems breaking syscon for vo1_grf and observed a bus error while accessing regmap. I remember in one of the RKDC discussion that the double parenting of these clocks is mandatory while accessing associated IP blocks. Any thoughts? Thanks, Jagan.