Message ID | 20230303-topic-rpmcc_sleep-v2-0-ae80a325fe94@linaro.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp584491wrd; Wed, 8 Mar 2023 13:36:51 -0800 (PST) X-Google-Smtp-Source: AK7set+CwNYQYbXOH/qtTKTA711kP9i9ywDb62Qin0cDf7JVV2ONI0VsMq21deXpD5JPDYfAAzr9 X-Received: by 2002:a17:902:ee95:b0:199:33ff:918a with SMTP id a21-20020a170902ee9500b0019933ff918amr19416669pld.21.1678311411486; Wed, 08 Mar 2023 13:36:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678311411; cv=none; d=google.com; s=arc-20160816; b=G5O7TPP3P+RiydEGUk85fMj7IJSmjAEFqTdnwo4K+84u6CWGsr+a+40oBDdEkeIkRq mXZEr4HLEy5FMlJ+cKAyB7mmutQRxGvMaN4svQELT20JYwvblHKpOIQZF+bc8rJDNETN nflLgBPguFCFD8uTy/+v1QDEhVDuqof1sHTHo06Lcl5tXmQYFxhG4tywSMIxikVcB/St nJoCIUR4uFqZAQEW/HHVsd+2+wAMhl+H6F2FHJfMS68C7J7Z/A+PDqlWYO/si2QTzrQT 0tbJtv5yjfNy+PROLu1iSvsnkuuEb86MdzK61g4d3xh6r/HgqwAq3sSe4iB3ElEH5j/2 Tw9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:content-transfer-encoding:mime-version :message-id:date:subject:from:dkim-signature; bh=Yx3K8KXfYeN1w6FBBGidGftrh4dFPASfNQz/HmCNuJ8=; b=o+XBBjCi/qOQqrHCZq0x/MIWPOTcbf+4jFG8ThMMertatvxapJVvYkeCGATC4KIPhl UrUg25K2MmWMM6QO2tNA7Iq3buUoFOrKRVErX1VrDWHX+JU7I48qr1M3trvINHlNVw83 WDEN+x0Dy8Czl0h22uVst9UwU77CLbbW6O7iW1XsCxE66jU/3ntgd1fTMdybV7d/USwl JX50PGXOxJ85qs5Oa2QDLOj6kc0MZNJsj1khe8gC9wu4Af+OiNboH3yN7fwRhyt9rbP+ T9zBou2faNzmhXj4J+rkHxcaqUAS7VzF3VumRpfVlTV8+l4G8qLJFQLhBN3BcjE3Bg6D 59kQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="Ul/itAD1"; 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=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kc14-20020a17090333ce00b0019accf72973si7894192plb.238.2023.03.08.13.36.34; Wed, 08 Mar 2023 13:36:51 -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=@linaro.org header.s=google header.b="Ul/itAD1"; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230016AbjCHVfr (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Wed, 8 Mar 2023 16:35:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229952AbjCHVfp (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Mar 2023 16:35:45 -0500 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BDB2B4F6B for <linux-kernel@vger.kernel.org>; Wed, 8 Mar 2023 13:35:38 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id t11so23133061lfr.1 for <linux-kernel@vger.kernel.org>; Wed, 08 Mar 2023 13:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678311336; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:from:to:cc:subject:date:message-id:reply-to; bh=Yx3K8KXfYeN1w6FBBGidGftrh4dFPASfNQz/HmCNuJ8=; b=Ul/itAD16p+95xv4fGh1OJ/KR0f+oFGvCtotcuPrQfa9VgDxo/A1SAp8F8YDoqwI74 lVMCy44wkwYFZrHNnvBe7mF09/7GMZMXoTLpoUXWyZo8B1i1HmY/AC3OF87f+JEf4iho /pyGCdDxL79VrH9tEx0hkVm7r3OdTo5f2D3FUuLW5N8v1z4i2Th7+amOUygNV/x1K2/E mkQ+DWU8tI9DkyWqZfrkoD57JA8JBgHiPiLEFmGJsFPuDgZjRwfqmdjevLUjoKhsokZI 7S2Alegth4zMb/Kuw56A3tsYZSlvVVSwloT8xA/mMBLH+oZwXUxfQfaN3MmSnihcj8G3 mxOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678311336; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Yx3K8KXfYeN1w6FBBGidGftrh4dFPASfNQz/HmCNuJ8=; b=X9K4ioy7jwZGBDyQ4csqnLLorMLOnUBgCrwMMQtsV5ZiHhuwwldXSuh9PF8q1PYqYE MMahbueLKfMo69JtG00cmLljjaKoqBjoXnjbkuQeqxPP/UkvicI8LhAkl1PENTeyj8DE mzLl/yv45SYSdmK7U7wjeMhOp1XKD3Y6jZdZYaRP09VKUc1EEcpZWNOO18klZNHcYUQ5 vMUhEkVxuqbNDEncfwfGsxGsNHW8VdlbkQacASuJAieJ7E0j8ohJjH4Hf6CaawDBx5uO 6XHk1eIJvncISrE630r57+Hlx4O4AFW/J7OOAMJRHpS32gNqN3dG2GhYJ960riEJul0Q uFhA== X-Gm-Message-State: AO0yUKXV+yKgpUeywsLgpHWrLVkR8wTQjLnrG9Dq8hORRykrhiooiQp2 vIY3yY5zbJ6hzkvr8Yo8+04UEA== X-Received: by 2002:ac2:48a7:0:b0:4da:ae47:6615 with SMTP id u7-20020ac248a7000000b004daae476615mr5800547lfg.49.1678311336396; Wed, 08 Mar 2023 13:35:36 -0800 (PST) Received: from [192.168.1.101] (abyj16.neoplus.adsl.tpnet.pl. [83.9.29.16]) by smtp.gmail.com with ESMTPSA id u7-20020ac243c7000000b004dc4d26c324sm2467479lfl.143.2023.03.08.13.35.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Mar 2023 13:35:35 -0800 (PST) From: Konrad Dybcio <konrad.dybcio@linaro.org> Subject: [PATCH RFT v2 00/14] SMD RPMCC sleep preparations Date: Wed, 08 Mar 2023 22:35:16 +0100 Message-Id: <20230303-topic-rpmcc_sleep-v2-0-ae80a325fe94@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAJT/CGQC/32NQQrCMBBFr1JmbSRNwVJXrjyAuJMi02TSBmISJ rUopXc39ADyV+9/Pm+FTOwow7lagWlx2cVQQB0q0BOGkYQzhUFJ1cgSMcfktOD00vqZPVES5tQ ims42slZQfgNmEgNj0FN5hrf3pUxM1n120QNu1zv0pZxcniN/d/lS79Mfz1ILKUynLdpuUC22F +8CcjxGHqHftu0HCyZurc0AAAA= To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, devicetree@vger.kernel.org, Konrad Dybcio <konrad.dybcio@linaro.org>, Shawn Guo <shawn.guo@linaro.org>, Taniya Das <quic_tdas@quicinc.com> X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=ed25519-sha256; t=1678311334; l=2646; i=konrad.dybcio@linaro.org; s=20230215; h=from:subject:message-id; bh=ag6sS2vNWieo5YFXrKuNAA3nF1wtvbbIdfAZ+4LnBg4=; b=872IBcUN9ZTJYbHMIDpj9icWsfsYZZXpj4dUIVgvkburRlwinDvLaWezNUvaqPTK6LEF2H5Gj73+ FO+gbPVbBcZRRL+aTA/MEpZhZWRq3u23wIVoPxogJ9LsAbIBCrES X-Developer-Key: i=konrad.dybcio@linaro.org; a=ed25519; pk=iclgkYvtl2w05SSXO5EjjSYlhFKsJ+5OSZBjOkQuEms= X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_HTTP,RCVD_IN_SORBS_SOCKS,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759837066609279974?= X-GMAIL-MSGID: =?utf-8?q?1759837066609279974?= |
Series |
SMD RPMCC sleep preparations
|
|
Message
Konrad Dybcio
March 8, 2023, 9:35 p.m. UTC
v1 -> v2:
- Use CLK_IS_CRITICAL instead of leaving a clk enable vote, expand macros
to do so
- Fix the keepalive clocks for 8998 & 660 (CNoC -> PNoC, it was
confusingly named cnoc_periph downstream)
- Introduce .determinte_rate to ensure we don't set keepalive clocks'
rates below 19.2 MHz
- Add a (!conditional!) way to test the ultimate goal of all these changes
by essentially enabling unused clk cleanup through a dt property (for
legacy reasons)
v2 was tested on:
- MSM8996 Sony Kagura (can disable unused)
- MSM8998 Sony Maple (can disable unused with OOT icc)
- SM6375 Sony PDX225 (can disable unused with OOT icc)
v1: https://lore.kernel.org/r/20230303-topic-rpmcc_sleep-v1-0-d9cfaf9b27a7@linaro.org
This series brings support for a couple of things necessary for the full
system idle on SMD RPM SoCs, namely unused clk shutdown and keepalive
votes (permanent active votes that are required on certain clocks for the
platform to function).
Tested on MSM8996 and SM6375, does not seem to introduce any additional
regressions.
Keepalive clocks for other platforms were gathered by digging in old
downstream kernels, please give them a test.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Konrad Dybcio (11):
dt-bindings: clock: qcom,rpmcc: Add a way to enable unused clock cleanup
clk: qcom: smd-rpm_ Make __DEFINE_CLK_SMD_RPM_BRANCH_PREFIX accept flags
clk: qcom: smd-rpm: Make DEFINE_CLK_SMD_RPM_BRANCH_A accept flags
clk: qcom: smd-rpm: Make BI_TCXO_AO critical
clk: qcom: smd-rpm: Make __DEFINE_CLK_SMD_RPM_PREFIX accept flags
clk: qcom: smd-rpm: Separate out a macro for defining an AO clock
clk: qcom: smd-rpm: Add support for keepalive votes
clk: qcom: smd-rpm: Introduce DEFINE_CLK_SMD_RPM_BUS_KEEPALIVE
clk: qcom: smd-rpm: Hook up PCNoC_0 keep_alive
clk: qcom: smd-rpm: Hook up CNoC_1 and SNoC_2 keep_alive
arm64: dts: qcom: msm8996: Enable rpmcc unused clk disablement
Shawn Guo (3):
clk: qcom: smd-rpm: Add .is_enabled hook
clk: qcom: smd-rpm: Add .is_prepared hook
clk: qcom: smd-rpm: Mark clock enabled in clk_smd_rpm_handoff()
.../devicetree/bindings/clock/qcom,rpmcc.yaml | 6 +
arch/arm64/boot/dts/qcom/msm8996.dtsi | 1 +
drivers/clk/qcom/clk-smd-rpm.c | 133 +++++++++++++++------
3 files changed, 106 insertions(+), 34 deletions(-)
---
base-commit: fc31900c948610e7b5c2f15fb7795832c8325327
change-id: 20230303-topic-rpmcc_sleep-d67aad9f3012
Best regards,
Comments
On 8.03.2023 22:35, Konrad Dybcio wrote: > v1 -> v2: > - Use CLK_IS_CRITICAL instead of leaving a clk enable vote, expand macros > to do so > - Fix the keepalive clocks for 8998 & 660 (CNoC -> PNoC, it was > confusingly named cnoc_periph downstream) > - Introduce .determinte_rate to ensure we don't set keepalive clocks' > rates below 19.2 MHz > - Add a (!conditional!) way to test the ultimate goal of all these changes > by essentially enabling unused clk cleanup through a dt property (for > legacy reasons) > > v2 was tested on: > > - MSM8996 Sony Kagura (can disable unused) > - MSM8998 Sony Maple (can disable unused with OOT icc) > - SM6375 Sony PDX225 (can disable unused with OOT icc) > > v1: https://lore.kernel.org/r/20230303-topic-rpmcc_sleep-v1-0-d9cfaf9b27a7@linaro.org > > This series brings support for a couple of things necessary for the full > system idle on SMD RPM SoCs, namely unused clk shutdown and keepalive > votes (permanent active votes that are required on certain clocks for the > platform to function). > > Tested on MSM8996 and SM6375, does not seem to introduce any additional > regressions. > > Keepalive clocks for other platforms were gathered by digging in old > downstream kernels, please give them a test. I have an implementation of rpmcc-within-icc ready(ish) locally. Turns out some SoCs need a keepalive (19.2MHz, active-only) vote on clocks that are NOT governed by interconnect.. So before we can disable clocks, both will need to be implemented.. ugh... I was hoping we could avoid having it in rpmcc.. Konrad > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > Konrad Dybcio (11): > dt-bindings: clock: qcom,rpmcc: Add a way to enable unused clock cleanup > clk: qcom: smd-rpm_ Make __DEFINE_CLK_SMD_RPM_BRANCH_PREFIX accept flags > clk: qcom: smd-rpm: Make DEFINE_CLK_SMD_RPM_BRANCH_A accept flags > clk: qcom: smd-rpm: Make BI_TCXO_AO critical > clk: qcom: smd-rpm: Make __DEFINE_CLK_SMD_RPM_PREFIX accept flags > clk: qcom: smd-rpm: Separate out a macro for defining an AO clock > clk: qcom: smd-rpm: Add support for keepalive votes > clk: qcom: smd-rpm: Introduce DEFINE_CLK_SMD_RPM_BUS_KEEPALIVE > clk: qcom: smd-rpm: Hook up PCNoC_0 keep_alive > clk: qcom: smd-rpm: Hook up CNoC_1 and SNoC_2 keep_alive > arm64: dts: qcom: msm8996: Enable rpmcc unused clk disablement > > Shawn Guo (3): > clk: qcom: smd-rpm: Add .is_enabled hook > clk: qcom: smd-rpm: Add .is_prepared hook > clk: qcom: smd-rpm: Mark clock enabled in clk_smd_rpm_handoff() > > .../devicetree/bindings/clock/qcom,rpmcc.yaml | 6 + > arch/arm64/boot/dts/qcom/msm8996.dtsi | 1 + > drivers/clk/qcom/clk-smd-rpm.c | 133 +++++++++++++++------ > 3 files changed, 106 insertions(+), 34 deletions(-) > --- > base-commit: fc31900c948610e7b5c2f15fb7795832c8325327 > change-id: 20230303-topic-rpmcc_sleep-d67aad9f3012 > > Best regards,
On Thu, Apr 20, 2023 at 03:50:16AM +0200, Konrad Dybcio wrote: > On 8.03.2023 22:35, Konrad Dybcio wrote: > > Keepalive clocks for other platforms were gathered by digging in old > > downstream kernels, please give them a test. > I have an implementation of rpmcc-within-icc ready(ish) locally. Turns out > some SoCs need a keepalive (19.2MHz, active-only) vote on clocks that > are NOT governed by interconnect.. So before we can disable clocks, > both will need to be implemented.. ugh... I was hoping we could avoid > having it in rpmcc.. > Can you give an example? Which clocks are affected on which SoC? Thanks, Stephan
On 20.04.2023 09:56, Stephan Gerhold wrote: > On Thu, Apr 20, 2023 at 03:50:16AM +0200, Konrad Dybcio wrote: >> On 8.03.2023 22:35, Konrad Dybcio wrote: >>> Keepalive clocks for other platforms were gathered by digging in old >>> downstream kernels, please give them a test. >> I have an implementation of rpmcc-within-icc ready(ish) locally. Turns out >> some SoCs need a keepalive (19.2MHz, active-only) vote on clocks that >> are NOT governed by interconnect.. So before we can disable clocks, >> both will need to be implemented.. ugh... I was hoping we could avoid >> having it in rpmcc.. >> > > Can you give an example? Which clocks are affected on which SoC? msm8998/sdm660 and PNoC Konrad > > Thanks, > Stephan
On Thu, Apr 20, 2023 at 11:36:24AM +0200, Konrad Dybcio wrote: > On 20.04.2023 09:56, Stephan Gerhold wrote: > > On Thu, Apr 20, 2023 at 03:50:16AM +0200, Konrad Dybcio wrote: > >> On 8.03.2023 22:35, Konrad Dybcio wrote: > >>> Keepalive clocks for other platforms were gathered by digging in old > >>> downstream kernels, please give them a test. > >> I have an implementation of rpmcc-within-icc ready(ish) locally. Turns out > >> some SoCs need a keepalive (19.2MHz, active-only) vote on clocks that > >> are NOT governed by interconnect.. So before we can disable clocks, > >> both will need to be implemented.. ugh... I was hoping we could avoid > >> having it in rpmcc.. > > Can you give an example? Which clocks are affected on which SoC? > msm8998/sdm660 and PNoC I don't see a PNoC for 8998/660, do you mean the "cnoc_periph_clk" downstream? Like the other NoCs it seems to be a RPM_BUS_CLK_TYPE, which means it does fit best into interconnect in my opinion. From a quick grep I don't see any usage of it in msm-4.4 downstream other than the active-only keepalive vote. So maybe you could just send that vote once in icc_rpm_smd and then ignore that clock (don't expose it at all)? Thanks, Stephan
On 20.04.2023 12:04, Stephan Gerhold wrote: > On Thu, Apr 20, 2023 at 11:36:24AM +0200, Konrad Dybcio wrote: >> On 20.04.2023 09:56, Stephan Gerhold wrote: >>> On Thu, Apr 20, 2023 at 03:50:16AM +0200, Konrad Dybcio wrote: >>>> On 8.03.2023 22:35, Konrad Dybcio wrote: >>>>> Keepalive clocks for other platforms were gathered by digging in old >>>>> downstream kernels, please give them a test. >>>> I have an implementation of rpmcc-within-icc ready(ish) locally. Turns out >>>> some SoCs need a keepalive (19.2MHz, active-only) vote on clocks that >>>> are NOT governed by interconnect.. So before we can disable clocks, >>>> both will need to be implemented.. ugh... I was hoping we could avoid >>>> having it in rpmcc.. >>> Can you give an example? Which clocks are affected on which SoC? >> msm8998/sdm660 and PNoC > > I don't see a PNoC for 8998/660, do you mean the "cnoc_periph_clk" It's the same, but Qualcomm kept changing the name every kernel release, so that's why we have 50 defines for the same thing upstream :( > downstream? Like the other NoCs it seems to be a RPM_BUS_CLK_TYPE, which > means it does fit best into interconnect in my opinion. From a quick > grep I don't see any usage of it in msm-4.4 downstream other than the > active-only keepalive vote. So maybe you could just send that vote once > in icc_rpm_smd and then ignore that clock (don't expose it at all)? Hm, perhaps that does sound like a good idea! As far as I understand, it's governed internally.. Older SoCs had a separate PNoC fabric exposed. Konrad > > Thanks, > Stephan
On 8.03.2023 22:35, Konrad Dybcio wrote: > v1 -> v2: > - Use CLK_IS_CRITICAL instead of leaving a clk enable vote, expand macros > to do so > - Fix the keepalive clocks for 8998 & 660 (CNoC -> PNoC, it was > confusingly named cnoc_periph downstream) > - Introduce .determinte_rate to ensure we don't set keepalive clocks' > rates below 19.2 MHz > - Add a (!conditional!) way to test the ultimate goal of all these changes > by essentially enabling unused clk cleanup through a dt property (for > legacy reasons) > > v2 was tested on: > > - MSM8996 Sony Kagura (can disable unused) > - MSM8998 Sony Maple (can disable unused with OOT icc) > - SM6375 Sony PDX225 (can disable unused with OOT icc) > > v1: https://lore.kernel.org/r/20230303-topic-rpmcc_sleep-v1-0-d9cfaf9b27a7@linaro.org > > This series brings support for a couple of things necessary for the full > system idle on SMD RPM SoCs, namely unused clk shutdown and keepalive > votes (permanent active votes that are required on certain clocks for the > platform to function). > > Tested on MSM8996 and SM6375, does not seem to introduce any additional > regressions. > > Keepalive clocks for other platforms were gathered by digging in old > downstream kernels, please give them a test. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > Konrad Dybcio (11): > dt-bindings: clock: qcom,rpmcc: Add a way to enable unused clock cleanup > clk: qcom: smd-rpm_ Make __DEFINE_CLK_SMD_RPM_BRANCH_PREFIX accept flags > clk: qcom: smd-rpm: Make DEFINE_CLK_SMD_RPM_BRANCH_A accept flags > clk: qcom: smd-rpm: Make BI_TCXO_AO critical Stephen, parallel to all of the discussions, would you be willing to take patches 4-6 as they are? XO_A being critical is something that won't hurt without the rest. Konrad > clk: qcom: smd-rpm: Make __DEFINE_CLK_SMD_RPM_PREFIX accept flags > clk: qcom: smd-rpm: Separate out a macro for defining an AO clock > clk: qcom: smd-rpm: Add support for keepalive votes > clk: qcom: smd-rpm: Introduce DEFINE_CLK_SMD_RPM_BUS_KEEPALIVE > clk: qcom: smd-rpm: Hook up PCNoC_0 keep_alive > clk: qcom: smd-rpm: Hook up CNoC_1 and SNoC_2 keep_alive > arm64: dts: qcom: msm8996: Enable rpmcc unused clk disablement > > Shawn Guo (3): > clk: qcom: smd-rpm: Add .is_enabled hook > clk: qcom: smd-rpm: Add .is_prepared hook > clk: qcom: smd-rpm: Mark clock enabled in clk_smd_rpm_handoff() > > .../devicetree/bindings/clock/qcom,rpmcc.yaml | 6 + > arch/arm64/boot/dts/qcom/msm8996.dtsi | 1 + > drivers/clk/qcom/clk-smd-rpm.c | 133 +++++++++++++++------ > 3 files changed, 106 insertions(+), 34 deletions(-) > --- > base-commit: fc31900c948610e7b5c2f15fb7795832c8325327 > change-id: 20230303-topic-rpmcc_sleep-d67aad9f3012 > > Best regards,
Quoting Konrad Dybcio (2023-04-20 08:57:53) > > > > Konrad Dybcio (11): > > dt-bindings: clock: qcom,rpmcc: Add a way to enable unused clock cleanup > > > clk: qcom: smd-rpm_ Make __DEFINE_CLK_SMD_RPM_BRANCH_PREFIX accept flags > > clk: qcom: smd-rpm: Make DEFINE_CLK_SMD_RPM_BRANCH_A accept flags > > clk: qcom: smd-rpm: Make BI_TCXO_AO critical > Stephen, parallel to all of the discussions, would you be willing to > take patches 4-6 as they are? XO_A being critical is something that > won't hurt without the rest. Sure, can you resend just those in a series?
On 4/25/23 20:35, Stephen Boyd wrote: > Quoting Konrad Dybcio (2023-04-20 08:57:53) >> >>> Konrad Dybcio (11): >>> dt-bindings: clock: qcom,rpmcc: Add a way to enable unused clock cleanup >>> clk: qcom: smd-rpm_ Make __DEFINE_CLK_SMD_RPM_BRANCH_PREFIX accept flags >>> clk: qcom: smd-rpm: Make DEFINE_CLK_SMD_RPM_BRANCH_A accept flags >>> clk: qcom: smd-rpm: Make BI_TCXO_AO critical >> Stephen, parallel to all of the discussions, would you be willing to >> take patches 4-6 as they are? XO_A being critical is something that >> won't hurt without the rest. > Sure, can you resend just those in a series? Thanks, I'll do that after Connect! Konrad