Message ID | 20231121-ipq5332-nsscc-v2-3-a7ff61beab72@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2b07:b0:403:3b70:6f57 with SMTP id io7csp663301vqb; Tue, 21 Nov 2023 06:32:43 -0800 (PST) X-Google-Smtp-Source: AGHT+IG8GkWVEc3qgMC1dRPKykgIEfb9CZeaZFf6glyx4mlSXCVZ5ciU0qJmuxec575bKBwAAWW9 X-Received: by 2002:a17:903:228f:b0:1cc:3829:8355 with SMTP id b15-20020a170903228f00b001cc38298355mr10588753plh.12.1700577162779; Tue, 21 Nov 2023 06:32:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700577162; cv=none; d=google.com; s=arc-20160816; b=thshKWE0wyJOnd6JyQBD4xbjE1pBXUMKVM3Iy/LB04Tza4afyzxuHEc2dOMHddmZd8 wmtqWd1vLFb7L1iTrwdO7ZmnMGsDoH4UI2DfTxiNhByNcV4ndev8bq6R00GrHQTg7Ei1 HVJuCYG4UMIFbesUvzzsWXje29DTU4FCTeqcXCWSln4XplcN9VXMPXyloIlfW0uP+vHM X8dfXhNkGdqR5MFPLjC2KhkTSWK+IkK771ITa6oJcmEVG8sqesl5mpFCUSgQFUXhziHU mmXPHW/gOU+oA+lDGE9EwYIacgL72exhY8oasTNafuYFq2X+qBfpDBCx+6qHKoPffoxJ HDlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=BskTKg7bjJwUbywnO6hqoJyv7Sqc6PQkw8i1ACSRrkc=; fh=4o2Uhotm7K4toTGrzBZgStTRt3POatOmlxgHLNvmPes=; b=o0YQ36DA/eHqmnYUVma7fDtIIQd9OXgkHaEFM+rFa7JBT0mNpLP2lPFtSeh8OrjfXw Io2VTt8wXmSQKQgUQS80myTC+RAo3q69VBb3Vpm9oNThiQeRneR4ioWXikxLYnatPAgN Lk0rij51Q+aBZPkG+i5ODidXKZfuuvUCMhW+faofqQQzI30yPN1PSl/Q+5BuQ/HvcZUE 3XHFEP7uJZ2pvC50MNLbU6rjmIltsIFs4m1b6tNwHKypnE/MCaHhjhSTiYUm5mkQYOjD oEvq/TGwFyYzivcUC4cYimu95fBvUq/lUsOHkPnK+EvT6GWLOU+MCjBwxX+l1jdvmmMc dELg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=giPbUB03; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id z7-20020a1709028f8700b001b3bd85f54bsi9751039plo.35.2023.11.21.06.32.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Nov 2023 06:32:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=giPbUB03; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id E44C480532DD; Tue, 21 Nov 2023 06:32:19 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234406AbjKUOcK (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Tue, 21 Nov 2023 09:32:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234544AbjKUOcC (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Nov 2023 09:32:02 -0500 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B91810CF; Tue, 21 Nov 2023 06:31:59 -0800 (PST) Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3ALE28dY030673; Tue, 21 Nov 2023 14:31:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : date : subject : mime-version : content-type : content-transfer-encoding : message-id : references : in-reply-to : to : cc; s=qcppdkim1; bh=BskTKg7bjJwUbywnO6hqoJyv7Sqc6PQkw8i1ACSRrkc=; b=giPbUB03x2TM5EshPduPzxlTCtJ3XfPPHq00TPqUYnMmo/QXTVooDvO9TLlL1TzeZeQe MqJwBHA9WW5Elag7IlJfI5eqoWF17XpNesg5hdXQaT1fdVLdWZAQ3KQgb/nKwKS6SkHv mAQydbwL0m/eV6idTLIysXJCgb1TvJvf9k4YBcZm0FQ+KoDSudpKyYU373O2FHKwkmbf auRSDohp9gAd3uMK8zEWlAfIfcTvsFOdDjLEZEXB3GrtlGYlBd7mm9tbdfEJWDV2eLSn 7UH0x8jdJx/JHmlq/cMn8YoDdlcT8UxjW5ypuy2jMUKHS0D+IGHtk4Az36mXY46KqrV+ WQ== Received: from nalasppmta03.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3ug7eabps7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Nov 2023 14:31:50 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA03.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 3ALEVOvi027441 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Nov 2023 14:31:24 GMT Received: from hu-kathirav-blr.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Tue, 21 Nov 2023 06:31:18 -0800 From: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Date: Tue, 21 Nov 2023 20:00:45 +0530 Subject: [PATCH v2 3/9] dt-bindings: clock: ipq5332: drop the few nss clocks definition MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <20231121-ipq5332-nsscc-v2-3-a7ff61beab72@quicinc.com> References: <20231121-ipq5332-nsscc-v2-0-a7ff61beab72@quicinc.com> In-Reply-To: <20231121-ipq5332-nsscc-v2-0-a7ff61beab72@quicinc.com> To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Richard Cochran <richardcochran@gmail.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org> CC: <linux-arm-msm@vger.kernel.org>, <linux-clk@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>, <netdev@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, "Kathiravan Thirumoorthy" <quic_kathirav@quicinc.com> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1700577061; l=1337; i=quic_kathirav@quicinc.com; s=20230906; h=from:subject:message-id; bh=pqduzhZaHeCV7j9kVmg9wiQQH0ixzsxoMBso//t3Mdk=; b=AB4Sr7MUMK8RN0i2Jln/VtEBE1OW7jFmY9eRCjKU3g1TSlI5c6NW0QmFqQn6N8O97CHQoNX0+ CPr35vWsxLxApIE/hes/qKuN1PjJHMRfneRfjEho7xPNmRBwaOuFzQU X-Developer-Key: i=quic_kathirav@quicinc.com; a=ed25519; pk=xWsR7pL6ch+vdZ9MoFGEaP61JUaRf0XaZYWztbQsIiM= X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: aa_TJ_eNJ2XAhN2o794W46TEkvO_FyOq X-Proofpoint-ORIG-GUID: aa_TJ_eNJ2XAhN2o794W46TEkvO_FyOq X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-21_05,2023-11-21_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 suspectscore=0 phishscore=0 mlxscore=0 spamscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=793 bulkscore=0 impostorscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311210114 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,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 agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 21 Nov 2023 06:32:20 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783184399381789834 X-GMAIL-MSGID: 1783184399381789834 |
Series |
Add NSS clock controller support for Qualcomm IPQ5332
|
|
Commit Message
Kathiravan Thirumoorthy
Nov. 21, 2023, 2:30 p.m. UTC
In commit 0dd3f263c810 ("clk: qcom: ipq5332: enable few nssnoc clocks in
driver probe"), gcc_snoc_nssnoc_clk, gcc_snoc_nssnoc_1_clk,
gcc_nssnoc_nsscc_clk are enabled in driver probe to keep it always-on.
So let's drop the binding definition as well.
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
---
Changes in V2:
- No changes
---
include/dt-bindings/clock/qcom,ipq5332-gcc.h | 3 ---
1 file changed, 3 deletions(-)
Comments
On 21/11/2023 15:30, Kathiravan Thirumoorthy wrote: > In commit 0dd3f263c810 ("clk: qcom: ipq5332: enable few nssnoc clocks in Where is this commit coming from? > driver probe"), gcc_snoc_nssnoc_clk, gcc_snoc_nssnoc_1_clk, > gcc_nssnoc_nsscc_clk are enabled in driver probe to keep it always-on. Implementation can change and for example bring back these clocks. Are you going to change bindings? No, drop the patch. Bindings should be dropped only in a few rare cases like clocks not available for OS or bugs. Best regards, Krzysztof
On 11/21/2023 8:36 PM, Krzysztof Kozlowski wrote: > On 21/11/2023 15:30, Kathiravan Thirumoorthy wrote: >> In commit 0dd3f263c810 ("clk: qcom: ipq5332: enable few nssnoc clocks in > > Where is this commit coming from? > >> driver probe"), gcc_snoc_nssnoc_clk, gcc_snoc_nssnoc_1_clk, >> gcc_nssnoc_nsscc_clk are enabled in driver probe to keep it always-on. > > Implementation can change and for example bring back these clocks. Are > you going to change bindings? No, drop the patch. > > Bindings should be dropped only in a few rare cases like clocks not > available for OS or bugs. Thanks Krzysztof. Will drop this patch in V3. One more question to understand further. In IPQ SoCs there are bunch of coresight / QDSS clocks but coresight framework doesn't handle all clocks. Those clocks are enabled in bootloader stage itself. In such case, should I drop the clocks from both binding and driver or only from driver? Thanks, Kathiravan. > > Best regards, > Krzysztof >
On 22/11/2023 11:08, Kathiravan Thirumoorthy wrote: > > > On 11/21/2023 8:36 PM, Krzysztof Kozlowski wrote: >> On 21/11/2023 15:30, Kathiravan Thirumoorthy wrote: >>> In commit 0dd3f263c810 ("clk: qcom: ipq5332: enable few nssnoc clocks in >> >> Where is this commit coming from? >> >>> driver probe"), gcc_snoc_nssnoc_clk, gcc_snoc_nssnoc_1_clk, >>> gcc_nssnoc_nsscc_clk are enabled in driver probe to keep it always-on. >> >> Implementation can change and for example bring back these clocks. Are >> you going to change bindings? No, drop the patch. >> >> Bindings should be dropped only in a few rare cases like clocks not >> available for OS or bugs. > > Thanks Krzysztof. Will drop this patch in V3. > > One more question to understand further. In IPQ SoCs there are bunch of > coresight / QDSS clocks but coresight framework doesn't handle all > clocks. Those clocks are enabled in bootloader stage itself. In such > case, should I drop the clocks from both binding and driver or only from > driver? That's not really the reason to drop them at all. Neither from driver, nor from bindings. You should not rely on bootloader handling your clocks Best regards, Krzysztof
On 11/22/2023 3:42 PM, Krzysztof Kozlowski wrote: > On 22/11/2023 11:08, Kathiravan Thirumoorthy wrote: >> >> >> On 11/21/2023 8:36 PM, Krzysztof Kozlowski wrote: >>> On 21/11/2023 15:30, Kathiravan Thirumoorthy wrote: >>>> In commit 0dd3f263c810 ("clk: qcom: ipq5332: enable few nssnoc clocks in >>> >>> Where is this commit coming from? >>> >>>> driver probe"), gcc_snoc_nssnoc_clk, gcc_snoc_nssnoc_1_clk, >>>> gcc_nssnoc_nsscc_clk are enabled in driver probe to keep it always-on. >>> >>> Implementation can change and for example bring back these clocks. Are >>> you going to change bindings? No, drop the patch. >>> >>> Bindings should be dropped only in a few rare cases like clocks not >>> available for OS or bugs. >> >> Thanks Krzysztof. Will drop this patch in V3. >> >> One more question to understand further. In IPQ SoCs there are bunch of >> coresight / QDSS clocks but coresight framework doesn't handle all >> clocks. Those clocks are enabled in bootloader stage itself. In such >> case, should I drop the clocks from both binding and driver or only from >> driver? > > That's not really the reason to drop them at all. Neither from driver, > nor from bindings. You should not rely on bootloader handling your clocks Thanks, lets say if those clocks are not needed at all by OS since QDSS is not used and needed only for the boot loaders to access the corresponding address space, in such case what can be done? I understand, at first those clocks should not have been added to the driver. > > Best regards, > Krzysztof >
On Wed, 22 Nov 2023 at 12:19, Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> wrote: > > > > On 11/22/2023 3:42 PM, Krzysztof Kozlowski wrote: > > On 22/11/2023 11:08, Kathiravan Thirumoorthy wrote: > >> > >> > >> On 11/21/2023 8:36 PM, Krzysztof Kozlowski wrote: > >>> On 21/11/2023 15:30, Kathiravan Thirumoorthy wrote: > >>>> In commit 0dd3f263c810 ("clk: qcom: ipq5332: enable few nssnoc clocks in > >>> > >>> Where is this commit coming from? > >>> > >>>> driver probe"), gcc_snoc_nssnoc_clk, gcc_snoc_nssnoc_1_clk, > >>>> gcc_nssnoc_nsscc_clk are enabled in driver probe to keep it always-on. > >>> > >>> Implementation can change and for example bring back these clocks. Are > >>> you going to change bindings? No, drop the patch. > >>> > >>> Bindings should be dropped only in a few rare cases like clocks not > >>> available for OS or bugs. > >> > >> Thanks Krzysztof. Will drop this patch in V3. > >> > >> One more question to understand further. In IPQ SoCs there are bunch of > >> coresight / QDSS clocks but coresight framework doesn't handle all > >> clocks. Those clocks are enabled in bootloader stage itself. In such > >> case, should I drop the clocks from both binding and driver or only from > >> driver? > > > > That's not really the reason to drop them at all. Neither from driver, > > nor from bindings. You should not rely on bootloader handling your clocks > > > Thanks, lets say if those clocks are not needed at all by OS since QDSS > is not used and needed only for the boot loaders to access the > corresponding address space, in such case what can be done? I > understand, at first those clocks should not have been added to the driver. First, what is QDSS? Yet another acronym? Second, if they are not used now, they can get used later.
On 11/22/2023 3:53 PM, Dmitry Baryshkov wrote: > On Wed, 22 Nov 2023 at 12:19, Kathiravan Thirumoorthy > <quic_kathirav@quicinc.com> wrote: >> >> >> >> On 11/22/2023 3:42 PM, Krzysztof Kozlowski wrote: >>> On 22/11/2023 11:08, Kathiravan Thirumoorthy wrote: >>>> >>>> >>>> On 11/21/2023 8:36 PM, Krzysztof Kozlowski wrote: >>>>> On 21/11/2023 15:30, Kathiravan Thirumoorthy wrote: >>>>>> In commit 0dd3f263c810 ("clk: qcom: ipq5332: enable few nssnoc clocks in >>>>> >>>>> Where is this commit coming from? >>>>> >>>>>> driver probe"), gcc_snoc_nssnoc_clk, gcc_snoc_nssnoc_1_clk, >>>>>> gcc_nssnoc_nsscc_clk are enabled in driver probe to keep it always-on. >>>>> >>>>> Implementation can change and for example bring back these clocks. Are >>>>> you going to change bindings? No, drop the patch. >>>>> >>>>> Bindings should be dropped only in a few rare cases like clocks not >>>>> available for OS or bugs. >>>> >>>> Thanks Krzysztof. Will drop this patch in V3. >>>> >>>> One more question to understand further. In IPQ SoCs there are bunch of >>>> coresight / QDSS clocks but coresight framework doesn't handle all >>>> clocks. Those clocks are enabled in bootloader stage itself. In such >>>> case, should I drop the clocks from both binding and driver or only from >>>> driver? >>> >>> That's not really the reason to drop them at all. Neither from driver, >>> nor from bindings. You should not rely on bootloader handling your clocks >> >> >> Thanks, lets say if those clocks are not needed at all by OS since QDSS >> is not used and needed only for the boot loaders to access the >> corresponding address space, in such case what can be done? I >> understand, at first those clocks should not have been added to the driver. > > First, what is QDSS? Yet another acronym? Qualcomm Debug Sub System - which compromises of various debug infra like coresight, DCC and so on. > > Second, if they are not used now, they can get used later. > Thanks. I will drop it from driver and leave the bindings as it is. Thanks, Kathiravan
diff --git a/include/dt-bindings/clock/qcom,ipq5332-gcc.h b/include/dt-bindings/clock/qcom,ipq5332-gcc.h index 8a405a0a96d0..4649026da332 100644 --- a/include/dt-bindings/clock/qcom,ipq5332-gcc.h +++ b/include/dt-bindings/clock/qcom,ipq5332-gcc.h @@ -55,7 +55,6 @@ #define GCC_NSSCC_CLK 46 #define GCC_NSSCFG_CLK 47 #define GCC_NSSNOC_ATB_CLK 48 -#define GCC_NSSNOC_NSSCC_CLK 49 #define GCC_NSSNOC_QOSGEN_REF_CLK 50 #define GCC_NSSNOC_SNOC_1_CLK 51 #define GCC_NSSNOC_SNOC_CLK 52 @@ -124,8 +123,6 @@ #define GCC_SDCC1_APPS_CLK_SRC 115 #define GCC_SLEEP_CLK_SRC 116 #define GCC_SNOC_LPASS_CFG_CLK 117 -#define GCC_SNOC_NSSNOC_1_CLK 118 -#define GCC_SNOC_NSSNOC_CLK 119 #define GCC_SNOC_PCIE3_1LANE_1_M_CLK 120 #define GCC_SNOC_PCIE3_1LANE_1_S_CLK 121 #define GCC_SNOC_PCIE3_1LANE_M_CLK 122