Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp2662239rwl; Fri, 6 Jan 2023 09:17:31 -0800 (PST) X-Google-Smtp-Source: AMrXdXsjxhCuTB8/oIfduUeKS9jDmNsBhMEtPxfjS9r1XjKXRyalgZW4v7p4jfYkqFOw6a8KT2YN X-Received: by 2002:a17:902:a609:b0:192:5e53:15ca with SMTP id u9-20020a170902a60900b001925e5315camr52906834plq.35.1673025451637; Fri, 06 Jan 2023 09:17:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673025451; cv=none; d=google.com; s=arc-20160816; b=zarq8aF1JUpFhR8N+Qx0KlR3pxk2rB4SebORVOgp9LCj1LtiFTrk9mcAs142eyOU5W Cpr+mGNDK32kwk6EKUhzeRIgR9tIuUGwA6pwhQfE678tlrJ+7J7aThPIZ+xdA5SQ+Zvs PsniP7XSl2Ghr6IGUbgvHbZG43GsZqphcAUSvlzyrtKMOuVF1h9AraTwo1Pg23RoARt2 brpL2KhU7muCyhYbJ44vEjaI+y3rglGY++o2t4G0xIGObrebtNn/YXtzAEoJhUDZM53Y jf9a24znJ2JomNEByGFnlq6Q0njDXT+zbvv9K/iceSoFmS+Z0FidqQYRIAidIYtPRl06 Cs9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=o3GKP/O3T9S4EPWZZozV34HXBsCK+A2Iy9nSRCVvgPw=; b=G/EX+QlPSwzWOMjC4ZPmdNaD6NWGUkSffeimG3uT8MJlpXXCavsbAULJ1jAZtYJNOr aHokEotdnmdCCXa19dHeBjtREshh2yjfchiFlrutbsqRZQ1BmgVvyPVg/tUwoUPZmMsT 3RjoGKlaHWfEfx+PC9e6CA9psup9LH7VJczawVfPg5+b6KQ5DJk6xWsEKdOT++6AsRm8 zvvN+Go/PqrODFBDTvaclcdBEW2iV7ccn5APM66QnnI+GpwHdXeYZxGjcxv/UJNXbYMK Qxa29xu0jLCl3+0ssQmzBL6cbPLO2peWYl6c+7U3Xex68ELka80WaV03k0wa3ZnKv6po ElqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="K/0B+PMO"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d18-20020a170902e15200b00189b15ea35bsi1410233pla.208.2023.01.06.09.17.24; Fri, 06 Jan 2023 09:17:31 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b="K/0B+PMO"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235599AbjAFQxv (ORCPT + 54 others); Fri, 6 Jan 2023 11:53:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231376AbjAFQxu (ORCPT ); Fri, 6 Jan 2023 11:53:50 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 111CB6B5FE; Fri, 6 Jan 2023 08:53:49 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9058D61EBD; Fri, 6 Jan 2023 16:53:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07719C433F0; Fri, 6 Jan 2023 16:53:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673024028; bh=Fbx2l78QVMes1nesfkgnzi2i6pZByNm5VK0Mmvy8hIM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=K/0B+PMOagcU21OAn2W6D5NvjxVGuphRH4G0gvm3iMLXoKN8IijKWfrDv9pv5N+1b nyHuLz/SRShH1WvVFD7+cjHi5Efjo3t+kXOA+XZ85r8WvvUZLxVvD+T9IoSjciJdBH ydfYTdbNImGUp1P14YphJr+NgJOdbsLfdy4SJP9VsRx7VvU3vXQGr+BZehgm2isnJq qeucHuxGmgWYakwRP2OpUqTm3KeFpc6asJvE9BMw+nCiHaVcI4e9HUYmge5cu1ArNH C6oDgeXXq7b3+pa6awL6Eey1hnBXoEeqUx2+rMsj1tEvvbQsTCMjaatp9m2S09zgih Kd9Uf0TjgkAUQ== Date: Fri, 6 Jan 2023 10:53:45 -0600 From: Bjorn Andersson To: Krzysztof Kozlowski Cc: Dmitry Baryshkov , Mike Tipton , Abel Vesa , Andy Gross , Konrad Dybcio , Mike Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Linux Kernel Mailing List , devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org Subject: Re: [PATCH v6 4/5] clk: qcom: rpmh: Add support for SM8550 rpmh clocks Message-ID: <20230106165345.al757qnivf4pu2dq@builder.lan> References: <20221206224515.1495457-1-abel.vesa@linaro.org> <20221206224515.1495457-5-abel.vesa@linaro.org> <6fc64fae-e616-2038-0424-34ce0cb7e16d@linaro.org> <20221228185254.4acnjchbyq4krblb@builder.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 On Fri, Jan 06, 2023 at 08:45:42AM +0100, Krzysztof Kozlowski wrote: > On 28/12/2022 19:59, Dmitry Baryshkov wrote: > > On 28/12/2022 20:52, Bjorn Andersson wrote: > >> On Wed, Dec 14, 2022 at 06:25:01PM +0200, Dmitry Baryshkov wrote: > >>> On 07/12/2022 00:45, Abel Vesa wrote: > >>>> Adds the RPMH clocks present in SM8550 SoC. > >>>> > >>>> Signed-off-by: Abel Vesa > >>>> Reviewed-by: Konrad Dybcio > >>>> --- > >>>> drivers/clk/qcom/clk-rpmh.c | 110 +++++++++++++++++++++++++++++------- > >>>> 1 file changed, 90 insertions(+), 20 deletions(-) > >>>> > >>>> diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c > >>>> index 2c2ef4b6d130..ce81c76ed0fd 100644 > >>>> --- a/drivers/clk/qcom/clk-rpmh.c > >>>> +++ b/drivers/clk/qcom/clk-rpmh.c > >>>> @@ -130,6 +130,34 @@ static DEFINE_MUTEX(rpmh_clk_lock); > >>>> }, \ > >>>> } > >>>> +#define DEFINE_CLK_FIXED_FACTOR(_name, _parent_name, _div) \ > >>>> + static struct clk_fixed_factor clk_fixed_factor##_##_name = { \ > >>>> + .mult = 1, \ > >>>> + .div = _div, \ > >>>> + .hw.init = &(struct clk_init_data){ \ > >>>> + .ops = &clk_fixed_factor_ops, \ > >>>> + .name = #_name, \ > >>>> + .parent_data = &(const struct clk_parent_data){ \ > >>>> + .fw_name = #_parent_name, \ > >>>> + .name = #_parent_name, \ > >>>> + }, \ > >>>> + .num_parents = 1, \ > >>>> + }, \ > >>>> + }; \ > >>>> + static struct clk_fixed_factor clk_fixed_factor##_##_name##_ao = { \ > >>>> + .mult = 1, \ > >>>> + .div = _div, \ > >>>> + .hw.init = &(struct clk_init_data){ \ > >>>> + .ops = &clk_fixed_factor_ops, \ > >>>> + .name = #_name "_ao", \ > >>>> + .parent_data = &(const struct clk_parent_data){ \ > >>>> + .fw_name = #_parent_name "_ao", \ > >>>> + .name = #_parent_name "_ao", \ > >>>> + }, \ > >>>> + .num_parents = 1, \ > >>>> + }, \ > >>>> + } > >>>> + > >>>> static inline struct clk_rpmh *to_clk_rpmh(struct clk_hw *_hw) > >>>> { > >>>> return container_of(_hw, struct clk_rpmh, hw); > >>>> @@ -345,6 +373,8 @@ DEFINE_CLK_RPMH_ARC(bi_tcxo, "xo.lvl", 0x3, 2); > >>>> DEFINE_CLK_RPMH_ARC(bi_tcxo, "xo.lvl", 0x3, 4); > >>>> DEFINE_CLK_RPMH_ARC(qlink, "qphy.lvl", 0x1, 4); > >>>> +DEFINE_CLK_FIXED_FACTOR(bi_tcxo_div2, bi_tcxo, 2); > >>>> + > >>>> DEFINE_CLK_RPMH_VRM(ln_bb_clk1, _a2, "lnbclka1", 2); > >>>> DEFINE_CLK_RPMH_VRM(ln_bb_clk2, _a2, "lnbclka2", 2); > >>>> DEFINE_CLK_RPMH_VRM(ln_bb_clk3, _a2, "lnbclka3", 2); > >>>> @@ -366,6 +396,16 @@ DEFINE_CLK_RPMH_VRM(rf_clk2, _d, "rfclkd2", 1); > >>>> DEFINE_CLK_RPMH_VRM(rf_clk3, _d, "rfclkd3", 1); > >>>> DEFINE_CLK_RPMH_VRM(rf_clk4, _d, "rfclkd4", 1); > >>>> +DEFINE_CLK_RPMH_VRM(clk1, _a1, "clka1", 1); > >>>> +DEFINE_CLK_RPMH_VRM(clk2, _a1, "clka2", 1); > >>>> +DEFINE_CLK_RPMH_VRM(clk3, _a1, "clka3", 1); > >>>> +DEFINE_CLK_RPMH_VRM(clk4, _a1, "clka4", 1); > >>>> +DEFINE_CLK_RPMH_VRM(clk5, _a1, "clka5", 1); > >>>> + > >>>> +DEFINE_CLK_RPMH_VRM(clk6, _a2, "clka6", 2); > >>>> +DEFINE_CLK_RPMH_VRM(clk7, _a2, "clka7", 2); > >>>> +DEFINE_CLK_RPMH_VRM(clk8, _a2, "clka8", 2); > >>>> + > >>>> DEFINE_CLK_RPMH_VRM(div_clk1, _div2, "divclka1", 2); > >>>> DEFINE_CLK_RPMH_BCM(ce, "CE0"); > >>>> @@ -576,6 +616,33 @@ static const struct clk_rpmh_desc clk_rpmh_sm8450 = { > >>>> .num_clks = ARRAY_SIZE(sm8450_rpmh_clocks), > >>>> }; > >>>> +static struct clk_hw *sm8550_rpmh_clocks[] = { > >>>> + [RPMH_CXO_PAD_CLK] = &clk_rpmh_bi_tcxo_div2.hw, > >>>> + [RPMH_CXO_PAD_CLK_A] = &clk_rpmh_bi_tcxo_div2_ao.hw, > >>>> + [RPMH_CXO_CLK] = &clk_fixed_factor_bi_tcxo_div2.hw, > >>>> + [RPMH_CXO_CLK_A] = &clk_fixed_factor_bi_tcxo_div2_ao.hw, > >>>> + [RPMH_LN_BB_CLK1] = &clk_rpmh_clk6_a2.hw, > >>>> + [RPMH_LN_BB_CLK1_A] = &clk_rpmh_clk6_a2_ao.hw, > >>>> + [RPMH_LN_BB_CLK2] = &clk_rpmh_clk7_a2.hw, > >>>> + [RPMH_LN_BB_CLK2_A] = &clk_rpmh_clk7_a2_ao.hw, > >>>> + [RPMH_LN_BB_CLK3] = &clk_rpmh_clk8_a2.hw, > >>>> + [RPMH_LN_BB_CLK3_A] = &clk_rpmh_clk8_a2_ao.hw, > >>>> + [RPMH_RF_CLK1] = &clk_rpmh_clk1_a1.hw, > >>>> + [RPMH_RF_CLK1_A] = &clk_rpmh_clk1_a1_ao.hw, > >>>> + [RPMH_RF_CLK2] = &clk_rpmh_clk2_a1.hw, > >>>> + [RPMH_RF_CLK2_A] = &clk_rpmh_clk2_a1_ao.hw, > >>>> + [RPMH_RF_CLK3] = &clk_rpmh_clk3_a1.hw, > >>>> + [RPMH_RF_CLK3_A] = &clk_rpmh_clk3_a1_ao.hw, > >>>> + [RPMH_RF_CLK4] = &clk_rpmh_clk4_a1.hw, > >>>> + [RPMH_RF_CLK4_A] = &clk_rpmh_clk4_a1_ao.hw, > >>>> + [RPMH_IPA_CLK] = &clk_rpmh_ipa.hw, > >>>> +}; > >>>> + > >>>> +static const struct clk_rpmh_desc clk_rpmh_sm8550 = { > >>>> + .clks = sm8550_rpmh_clocks, > >>>> + .num_clks = ARRAY_SIZE(sm8550_rpmh_clocks), > >>>> +}; > >>>> + > >>>> static struct clk_hw *sc7280_rpmh_clocks[] = { > >>>> [RPMH_CXO_CLK] = &clk_rpmh_bi_tcxo_div4.hw, > >>>> [RPMH_CXO_CLK_A] = &clk_rpmh_bi_tcxo_div4_ao.hw, > >>>> @@ -683,29 +750,31 @@ static int clk_rpmh_probe(struct platform_device *pdev) > >>>> name = hw_clks[i]->init->name; > >>>> - rpmh_clk = to_clk_rpmh(hw_clks[i]); > >>>> - res_addr = cmd_db_read_addr(rpmh_clk->res_name); > >>>> - if (!res_addr) { > >>>> - dev_err(&pdev->dev, "missing RPMh resource address for %s\n", > >>>> - rpmh_clk->res_name); > >>>> - return -ENODEV; > >>>> - } > >>>> + if (hw_clks[i]->init->ops != &clk_fixed_factor_ops) { > >>> > >>> We discussed this separately, the fixed factor clocks will be moved to the > >>> child nodes, leaving rpmhcc with only cmd-db based clocks. > >>> > >> > >> Are you saying that you will represent bi_tcxo as a fixed-factor-clock > >> under /clocks with RPMH_CXO_PAD_CLK as parent and a clock-div = <2>; ? > > > > Yes, this was the idea. The rpmhcc driver is pretty much centric around > > the cmd-db clocks. Adding a fixed-factor clock results either in a > > horrible hacks or in a significant code refactoring. However we already > > have an existing way to fixed-factor clocks: DT nodes. Adding support > > for such nodes to rpmhcc driver requires just a single additional API > > call: devm_of_platform_populate(). > > Please no. DT is not to solve driver issues, skip some code or make > things simpler for driver developers. If everyone - U-boot, *BSD, > firmwares - pushes to DT stuff like this, because this makes their > driver development easier, you would have total mess. Linux does not > have any priorities here in this approach. This is not solving the driver issue, rather the opposite. Moving it out of the driver accurately represents that there's an additional divider between the clock that is controlled by this driver and the next clock provider(s). Regards, Bjorn