Message ID | 1688647793-20950-2-git-send-email-quic_rohiagar@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp2547757vqx; Thu, 6 Jul 2023 06:09:09 -0700 (PDT) X-Google-Smtp-Source: APBJJlE1CQTedhe7jA/YwFrAANn7/FqJNTiIcKk9ay/mMakSLYiG7wRk7bHuxNarJMjYjFRlZD6K X-Received: by 2002:a05:6a20:3d85:b0:10c:322:72d5 with SMTP id s5-20020a056a203d8500b0010c032272d5mr2765915pzi.23.1688648949481; Thu, 06 Jul 2023 06:09:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688648949; cv=none; d=google.com; s=arc-20160816; b=ZEq0j5OWwBFeQccY9OlVEzvylWl8bjfFQTDAnxEz+UJWK6HG/q5Nu7C49wtqdpW4BW 6Vc78+b/jk/3KMlnr1QNOQCdmzghzKkRqVgcV/86NB3JNuKKppc+VASKb2frFlPlv3ZS AFypviUXN2RvmsAhQrPWWmsgAfFI1q2mjMcGCXWYDL99JSfcoNng/hI6cOT1aMZmDl/y PLyv44eT1hGsm5w8aneANbbnFTTC7sxWoaGXx72Lb8oTofBK5F3rMh2WRLsxW5Aa4aSv dlkcdHFd1C+u2xbm3v7jwI4UHz0OITpDc8aRuJqt6bK23+bQ9mhDK0yUCBcdMdlqBzRK EScg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=mrrQfJyScYzURQREC3hWOc6S03ZHdGdpB8wHRMI6UcI=; fh=FqIaZmJRa7M15GQeKUdLg2SE2zbDk9BBzU6UB9zaVuw=; b=bipLaIE2Glu3GqJOhWYjaA7fQefe7NqFmA16wAim0oQdNTP5fUPzuglA479hwdT7VG MMOBQtW5JB+cqNzXI7TyNxKBWOJVp3puxVct0C0j9cjCOAXdm/19RaRYeuVXDc8L/WZv vMnQLZGEv7+M+rVOK6r6M6MmYf/DCoiGqLIxs/iUmjhct+t5N79n7XJJJLyl6EV0LO2N /NmcquEATKzzb6pRkAjLQhg94IVRHpMwT1Bv47q9FFD55rdHRheFyFT+DeHueHPT/xD6 ZD3eiNZUNZwdgqeiSJlfyTdcABXp6gSnMVtIceMYTAhh4W1qeIPeCmIS5sjJCberTxpo V1kw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=eaZv1BYK; 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=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a11-20020a056a000c8b00b00675c97e9214si1546653pfv.28.2023.07.06.06.08.53; Thu, 06 Jul 2023 06:09:09 -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=@quicinc.com header.s=qcppdkim1 header.b=eaZv1BYK; 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=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232440AbjGFMut (ORCPT <rfc822;hadasmailinglist@gmail.com> + 99 others); Thu, 6 Jul 2023 08:50:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232206AbjGFMur (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 6 Jul 2023 08:50:47 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 350621FC1; Thu, 6 Jul 2023 05:50:16 -0700 (PDT) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 366CfEJC019662; Thu, 6 Jul 2023 12:50:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references; s=qcppdkim1; bh=mrrQfJyScYzURQREC3hWOc6S03ZHdGdpB8wHRMI6UcI=; b=eaZv1BYKYJcxXvIir+ojRED96pM6b2bugyHoukP9WWeXiWIz77ucyEtPr0TjLubnxwuw 8Dx48aFiixXG7QMhCpoUSPSmFs06nUPaB5qdwCGA4T67GR6yjQtZLDk6eLIBxdcNMqS9 NyLZc1XxyvpezGaRk8y+OfMg5Ky+kGIazvy+29Pyh8boUzT5gHKUeWeEuXcC1S61hO5Z WlgVT72STplfeUg+QkAsB5UYMBQsUpJN91FVjFxX070COIg4G7FqATYSgyGjnBL6VOi2 NBWqkxhJMQgAzmQQDi+vl6/UGYJpK4q/SdyHL68SBs+6SKLfU/3FS65NaG2/swjhh0W3 SA== Received: from apblrppmta01.qualcomm.com (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.18.19]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3rntctrdhu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jul 2023 12:50:03 +0000 Received: from pps.filterd (APBLRPPMTA01.qualcomm.com [127.0.0.1]) by APBLRPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTP id 366Co0Pr024162; Thu, 6 Jul 2023 12:50:00 GMT Received: from pps.reinject (localhost [127.0.0.1]) by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 3rjd7kywam-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 06 Jul 2023 12:50:00 +0000 Received: from APBLRPPMTA01.qualcomm.com (APBLRPPMTA01.qualcomm.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 366Co0w9024155; Thu, 6 Jul 2023 12:50:00 GMT Received: from hu-sgudaval-hyd.qualcomm.com (hu-rohiagar-hyd.qualcomm.com [10.213.106.138]) by APBLRPPMTA01.qualcomm.com (PPS) with ESMTP id 366CnxVm024148; Thu, 06 Jul 2023 12:50:00 +0000 Received: by hu-sgudaval-hyd.qualcomm.com (Postfix, from userid 3970568) id 6159F5FF3; Thu, 6 Jul 2023 18:19:59 +0530 (+0530) From: Rohit Agarwal <quic_rohiagar@quicinc.com> To: agross@kernel.org, andersson@kernel.org, konrad.dybcio@linaro.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Rohit Agarwal <quic_rohiagar@quicinc.com> Subject: [PATCH 1/3] dt-bindings: power: rpmpd: Add Generic RPM(h) PD indexes Date: Thu, 6 Jul 2023 18:19:51 +0530 Message-Id: <1688647793-20950-2-git-send-email-quic_rohiagar@quicinc.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1688647793-20950-1-git-send-email-quic_rohiagar@quicinc.com> References: <1688647793-20950-1-git-send-email-quic_rohiagar@quicinc.com> X-QCInternal: smtphost X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: 0a-kGI2M2KHcmaznxVo74Gd1carwJWFR X-Proofpoint-ORIG-GUID: 0a-kGI2M2KHcmaznxVo74Gd1carwJWFR X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-06_09,2023-07-06_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 mlxlogscore=502 priorityscore=1501 adultscore=0 spamscore=0 phishscore=0 malwarescore=0 impostorscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307060115 X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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: <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?1770676760807675806?= X-GMAIL-MSGID: =?utf-8?q?1770676760807675806?= |
Series |
Add support of rpmhpd for SDX75
|
|
Commit Message
Rohit Agarwal
July 6, 2023, 12:49 p.m. UTC
Add Generic RPM(h) Power Domain indexes that can be used
for all the Qualcomm SoC henceforth.
Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com>
Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
include/dt-bindings/power/qcom-rpmpd.h | 49 ++++++++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
Comments
On Thu, Jul 06, 2023 at 06:19:51PM +0530, Rohit Agarwal wrote: > Add Generic RPM(h) Power Domain indexes that can be used > for all the Qualcomm SoC henceforth. > > Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> > Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> Does it make sense to give this link [1] so that we know what is Konrad's suggestion and the discussion around it? [1] https://lore.kernel.org/all/0d468d08-6410-e424-b4f3-5245cdb0334a@linaro.org/ > --- > include/dt-bindings/power/qcom-rpmpd.h | 49 ++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h > index 83be996..6498251 100644 > --- a/include/dt-bindings/power/qcom-rpmpd.h > +++ b/include/dt-bindings/power/qcom-rpmpd.h > @@ -4,6 +4,55 @@ > #ifndef _DT_BINDINGS_POWER_QCOM_RPMPD_H > #define _DT_BINDINGS_POWER_QCOM_RPMPD_H > > +/* Generic RPMH Power Domain Indexes */ > +#define RPMHPD_CX 0 > +#define RPMHPD_MX 1 > +#define RPMHPD_CX_AO 2 > +#define RPMHPD_MX_AO 3 > +#define RPMHPD_GFX 4 > +#define RPMHPD_MSS 5 > +#define RPMHPD_EBI 6 > +#define RPMHPD_LCX 7 > +#define RPMHPD_LMX 8 > +#define RPMHPD_MMCX 9 > +#define RPMHPD_MMCX_AO 10 > +#define RPMHPD_MXC 11 > +#define RPMHPD_MXC_AO 12 > +#define RPMHPD_NSP 13 > +#define RPMHPD_NSP0 14 > +#define RPMHPD_NSP1 15 > +#define RPMHPD_QPHY 16 > +#define RPMHPD_DDR 17 > +#define RPMHPD_XO 18 > + > +/* Generic RPM Power Domain Indexes */ > +#define RPMPD_VDDCX 0 > +#define RPMPD_VDDCX_AO 1 > +#define RPMPD_VDDMX 2 > +#define RPMPD_VDDMX_AO 3 > +#define RPMPD_VDDCX_VFL 4 > +#define RPMPD_VDDMX_VFL 5 > +#define RPMPD_VDDCX_VFC 6 > +#define RPMPD_LPI_CX 7 > +#define RPMPD_LPI_MX 8 > +#define RPMPD_SSCCX 9 > +#define RPMPD_SSCCX_VFL 10 > +#define RPMPD_SSCMX 11 > +#define RPMPD_SSCMX_VFL 12 > +#define RPMPD_VDDSSCX 13 > +#define RPMPD_VDDSSCX_VFC 14 > +#define RPMPD_VDDGFX 15 > +#define RPMPD_VDDGFX_VFC 16 > +#define RPMPD_VDDGX 17 > +#define RPMPD_VDDGX_AO 18 > +#define RPMPD_VDDMDCX 19 > +#define RPMPD_VDDMDCX_AO 20 > +#define RPMPD_VDDMDCX_VFC 21 > +#define RPMPD_VDDMD 22 > +#define RPMPD_VDDMD_AO 23 > +#define RPMPD_LPICX_VFL 24 > +#define RPMPD_LPIMX_VFL 25 > + How did you come up with this list? A union of all SoCs supported by RPMh driver? > /* SA8775P Power Domain Indexes */ > #define SA8775P_CX 0 > #define SA8775P_CX_AO 1 > -- > 2.7.4 > Thanks, Pavan
On 06/07/2023 14:49, Rohit Agarwal wrote: > Add Generic RPM(h) Power Domain indexes that can be used > for all the Qualcomm SoC henceforth. > > Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> > Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > include/dt-bindings/power/qcom-rpmpd.h | 49 ++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) Didn't you just send a patch doing similar? There is no changelog, no versioning, how can anyone figure out which patch is the latest or which one should be ignored? Best regards, Krzysztof
On 7/6/2023 8:06 PM, Krzysztof Kozlowski wrote: > On 06/07/2023 14:49, Rohit Agarwal wrote: >> Add Generic RPM(h) Power Domain indexes that can be used >> for all the Qualcomm SoC henceforth. >> >> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >> Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> >> --- >> include/dt-bindings/power/qcom-rpmpd.h | 49 ++++++++++++++++++++++++++++++++++ >> 1 file changed, 49 insertions(+) > Didn't you just send a patch doing similar? There is no changelog, no > versioning, how can anyone figure out which patch is the latest or which > one should be ignored? No, that patch was removing all the other SoCs macro which was against the ABI. So dropping that series completely and this being new series didnt include the versioning. Since all the patches in that series needed to be dropped I thought to start a new series. Thanks, Rohit. > Best regards, > Krzysztof >
On 7/6/2023 8:00 PM, Pavan Kondeti wrote: > On Thu, Jul 06, 2023 at 06:19:51PM +0530, Rohit Agarwal wrote: >> Add Generic RPM(h) Power Domain indexes that can be used >> for all the Qualcomm SoC henceforth. >> >> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >> Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> > Does it make sense to give this link [1] so that we know what is > Konrad's suggestion and the discussion around it? > > [1] > https://lore.kernel.org/all/0d468d08-6410-e424-b4f3-5245cdb0334a@linaro.org/ Yes, could be given in the cover letter. >> --- >> include/dt-bindings/power/qcom-rpmpd.h | 49 ++++++++++++++++++++++++++++++++++ >> 1 file changed, 49 insertions(+) >> >> diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h >> index 83be996..6498251 100644 >> --- a/include/dt-bindings/power/qcom-rpmpd.h >> +++ b/include/dt-bindings/power/qcom-rpmpd.h >> @@ -4,6 +4,55 @@ >> #ifndef _DT_BINDINGS_POWER_QCOM_RPMPD_H >> #define _DT_BINDINGS_POWER_QCOM_RPMPD_H >> >> +/* Generic RPMH Power Domain Indexes */ >> +#define RPMHPD_CX 0 >> +#define RPMHPD_MX 1 >> +#define RPMHPD_CX_AO 2 >> +#define RPMHPD_MX_AO 3 >> +#define RPMHPD_GFX 4 >> +#define RPMHPD_MSS 5 >> +#define RPMHPD_EBI 6 >> +#define RPMHPD_LCX 7 >> +#define RPMHPD_LMX 8 >> +#define RPMHPD_MMCX 9 >> +#define RPMHPD_MMCX_AO 10 >> +#define RPMHPD_MXC 11 >> +#define RPMHPD_MXC_AO 12 >> +#define RPMHPD_NSP 13 >> +#define RPMHPD_NSP0 14 >> +#define RPMHPD_NSP1 15 >> +#define RPMHPD_QPHY 16 >> +#define RPMHPD_DDR 17 >> +#define RPMHPD_XO 18 >> + >> +/* Generic RPM Power Domain Indexes */ >> +#define RPMPD_VDDCX 0 >> +#define RPMPD_VDDCX_AO 1 >> +#define RPMPD_VDDMX 2 >> +#define RPMPD_VDDMX_AO 3 >> +#define RPMPD_VDDCX_VFL 4 >> +#define RPMPD_VDDMX_VFL 5 >> +#define RPMPD_VDDCX_VFC 6 >> +#define RPMPD_LPI_CX 7 >> +#define RPMPD_LPI_MX 8 >> +#define RPMPD_SSCCX 9 >> +#define RPMPD_SSCCX_VFL 10 >> +#define RPMPD_SSCMX 11 >> +#define RPMPD_SSCMX_VFL 12 >> +#define RPMPD_VDDSSCX 13 >> +#define RPMPD_VDDSSCX_VFC 14 >> +#define RPMPD_VDDGFX 15 >> +#define RPMPD_VDDGFX_VFC 16 >> +#define RPMPD_VDDGX 17 >> +#define RPMPD_VDDGX_AO 18 >> +#define RPMPD_VDDMDCX 19 >> +#define RPMPD_VDDMDCX_AO 20 >> +#define RPMPD_VDDMDCX_VFC 21 >> +#define RPMPD_VDDMD 22 >> +#define RPMPD_VDDMD_AO 23 >> +#define RPMPD_LPICX_VFL 24 >> +#define RPMPD_LPIMX_VFL 25 >> + > How did you come up with this list? A union of all SoCs supported by > RPMh driver? Yes, union of all the SoCs and arranged based on frequencies of usage. Thanks, Rohit. >> /* SA8775P Power Domain Indexes */ >> #define SA8775P_CX 0 >> #define SA8775P_CX_AO 1 >> -- >> 2.7.4 >> > Thanks, > Pavan
On 6.07.2023 16:47, Rohit Agarwal wrote: > > On 7/6/2023 8:00 PM, Pavan Kondeti wrote: >> On Thu, Jul 06, 2023 at 06:19:51PM +0530, Rohit Agarwal wrote: >>> Add Generic RPM(h) Power Domain indexes that can be used >>> for all the Qualcomm SoC henceforth. >>> >>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >>> Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> >> Does it make sense to give this link [1] so that we know what is >> Konrad's suggestion and the discussion around it? >> >> [1] >> https://lore.kernel.org/all/0d468d08-6410-e424-b4f3-5245cdb0334a@linaro.org/ > Yes, could be given in the cover letter. >>> --- [...] >>> +#define RPMPD_VDDMD 22 >>> +#define RPMPD_VDDMD_AO 23 >>> +#define RPMPD_LPICX_VFL 24 >>> +#define RPMPD_LPIMX_VFL 25 >>> + >> How did you come up with this list? A union of all SoCs supported by >> RPMh driver? > Yes, union of all the SoCs and arranged based on frequencies of usage. The latter part is very thoughtful, thanks for taking that into account. That said (and I really don't wanna be picky here, I'm just coming up with ideas a bit later than I'd like to).. Perhaps this patch should be limited to RPMhPD [1] and the definitions could be moved to a new binding, so: include/dt-bindings/power/qcom,rpmhpd.h // this way we don't have to add RPMHPD_ #define CX 0 which would result in us being able to do: #include ....rpmhpd.h [...] power-domains = <&rpmhpd CX>; in the device tree which is even more concise! [1] The old RPM SMD platforms have some duplications in the names.. No point in duplicating that. The oldest entries remember 2013 so it's easy to see how we had some dirt build up there. Konrad > > Thanks, > Rohit. >>> /* SA8775P Power Domain Indexes */ >>> #define SA8775P_CX 0 >>> #define SA8775P_CX_AO 1 >>> -- >>> 2.7.4 >>> >> Thanks, >> Pavan
On 7/6/2023 8:30 PM, Konrad Dybcio wrote: > On 6.07.2023 16:47, Rohit Agarwal wrote: >> On 7/6/2023 8:00 PM, Pavan Kondeti wrote: >>> On Thu, Jul 06, 2023 at 06:19:51PM +0530, Rohit Agarwal wrote: >>>> Add Generic RPM(h) Power Domain indexes that can be used >>>> for all the Qualcomm SoC henceforth. >>>> >>>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >>>> Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>> Does it make sense to give this link [1] so that we know what is >>> Konrad's suggestion and the discussion around it? >>> >>> [1] >>> https://lore.kernel.org/all/0d468d08-6410-e424-b4f3-5245cdb0334a@linaro.org/ >> Yes, could be given in the cover letter. >>>> --- > [...] > >>>> +#define RPMPD_VDDMD 22 >>>> +#define RPMPD_VDDMD_AO 23 >>>> +#define RPMPD_LPICX_VFL 24 >>>> +#define RPMPD_LPIMX_VFL 25 >>>> + >>> How did you come up with this list? A union of all SoCs supported by >>> RPMh driver? >> Yes, union of all the SoCs and arranged based on frequencies of usage. > The latter part is very thoughtful, thanks for taking that into account. > > That said (and I really don't wanna be picky here, I'm just coming up with > ideas a bit later than I'd like to).. Perhaps this patch should be limited > to RPMhPD [1] and the definitions could be moved to a new binding, so: So should we not update anything in this old binding and completely move to the new bindings? rpmhpd.h? Not even rpmpd_* bindings? Thanks, Rohit. > include/dt-bindings/power/qcom,rpmhpd.h > // this way we don't have to add RPMHPD_ > #define CX 0 Ok, will remove this as well. > which would result in us being able to do: > > #include ....rpmhpd.h > [...] > power-domains = <&rpmhpd CX>; > > in the device tree > > which is even more concise! Yes Thanks, Rohit. > > [1] The old RPM SMD platforms have some duplications in the names.. > No point in duplicating that. The oldest entries remember 2013 so > it's easy to see how we had some dirt build up there. > > Konrad >> Thanks, >> Rohit. >>>> /* SA8775P Power Domain Indexes */ >>>> #define SA8775P_CX 0 >>>> #define SA8775P_CX_AO 1 >>>> -- >>>> 2.7.4 >>>> >>> Thanks, >>> Pavan
On 6.07.2023 17:15, Rohit Agarwal wrote: > > On 7/6/2023 8:30 PM, Konrad Dybcio wrote: >> On 6.07.2023 16:47, Rohit Agarwal wrote: >>> On 7/6/2023 8:00 PM, Pavan Kondeti wrote: >>>> On Thu, Jul 06, 2023 at 06:19:51PM +0530, Rohit Agarwal wrote: >>>>> Add Generic RPM(h) Power Domain indexes that can be used >>>>> for all the Qualcomm SoC henceforth. >>>>> >>>>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >>>>> Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>> Does it make sense to give this link [1] so that we know what is >>>> Konrad's suggestion and the discussion around it? >>>> >>>> [1] >>>> https://lore.kernel.org/all/0d468d08-6410-e424-b4f3-5245cdb0334a@linaro.org/ >>> Yes, could be given in the cover letter. >>>>> --- >> [...] >> >>>>> +#define RPMPD_VDDMD 22 >>>>> +#define RPMPD_VDDMD_AO 23 >>>>> +#define RPMPD_LPICX_VFL 24 >>>>> +#define RPMPD_LPIMX_VFL 25 >>>>> + >>>> How did you come up with this list? A union of all SoCs supported by >>>> RPMh driver? >>> Yes, union of all the SoCs and arranged based on frequencies of usage. >> The latter part is very thoughtful, thanks for taking that into account. >> >> That said (and I really don't wanna be picky here, I'm just coming up with >> ideas a bit later than I'd like to).. Perhaps this patch should be limited >> to RPMhPD [1] and the definitions could be moved to a new binding, so: > So should we not update anything in this old binding and completely move to the new bindings? Yes, create qcom,rpmhpd.h and add new common entries there and let this ship sink > rpmhpd.h? > Not even rpmpd_* bindings? Again, due to [1], let's not touch that for now. We'll worry about that when somebody will try to add a new entry to that driver. Konrad > > Thanks, > Rohit. >> include/dt-bindings/power/qcom,rpmhpd.h >> // this way we don't have to add RPMHPD_ >> #define CX 0 > Ok, will remove this as well. >> which would result in us being able to do: >> >> #include ....rpmhpd.h >> [...] >> power-domains = <&rpmhpd CX>; >> >> in the device tree >> >> which is even more concise! > > Yes > > Thanks, > Rohit. > >> >> [1] The old RPM SMD platforms have some duplications in the names.. >> No point in duplicating that. The oldest entries remember 2013 so >> it's easy to see how we had some dirt build up there. >> >> Konrad >>> Thanks, >>> Rohit. >>>>> /* SA8775P Power Domain Indexes */ >>>>> #define SA8775P_CX 0 >>>>> #define SA8775P_CX_AO 1 >>>>> -- >>>>> 2.7.4 >>>>> >>>> Thanks, >>>> Pavan
On 7/6/2023 8:52 PM, Konrad Dybcio wrote: > On 6.07.2023 17:15, Rohit Agarwal wrote: >> On 7/6/2023 8:30 PM, Konrad Dybcio wrote: >>> On 6.07.2023 16:47, Rohit Agarwal wrote: >>>> On 7/6/2023 8:00 PM, Pavan Kondeti wrote: >>>>> On Thu, Jul 06, 2023 at 06:19:51PM +0530, Rohit Agarwal wrote: >>>>>> Add Generic RPM(h) Power Domain indexes that can be used >>>>>> for all the Qualcomm SoC henceforth. >>>>>> >>>>>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >>>>>> Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>>> Does it make sense to give this link [1] so that we know what is >>>>> Konrad's suggestion and the discussion around it? >>>>> >>>>> [1] >>>>> https://lore.kernel.org/all/0d468d08-6410-e424-b4f3-5245cdb0334a@linaro.org/ >>>> Yes, could be given in the cover letter. >>>>>> --- >>> [...] >>> >>>>>> +#define RPMPD_VDDMD 22 >>>>>> +#define RPMPD_VDDMD_AO 23 >>>>>> +#define RPMPD_LPICX_VFL 24 >>>>>> +#define RPMPD_LPIMX_VFL 25 >>>>>> + >>>>> How did you come up with this list? A union of all SoCs supported by >>>>> RPMh driver? >>>> Yes, union of all the SoCs and arranged based on frequencies of usage. >>> The latter part is very thoughtful, thanks for taking that into account. >>> >>> That said (and I really don't wanna be picky here, I'm just coming up with >>> ideas a bit later than I'd like to).. Perhaps this patch should be limited >>> to RPMhPD [1] and the definitions could be moved to a new binding, so: >> So should we not update anything in this old binding and completely move to the new bindings? > Yes, create qcom,rpmhpd.h and add new common entries there and let this > ship sink > >> rpmhpd.h? >> Not even rpmpd_* bindings? > Again, due to [1], let's not touch that for now. We'll worry about that > when somebody will try to add a new entry to that driver. Yes. Thanks, Rohit. > > Konrad >> Thanks, >> Rohit. >>> include/dt-bindings/power/qcom,rpmhpd.h >>> // this way we don't have to add RPMHPD_ >>> #define CX 0 >> Ok, will remove this as well. >>> which would result in us being able to do: >>> >>> #include ....rpmhpd.h >>> [...] >>> power-domains = <&rpmhpd CX>; >>> >>> in the device tree >>> >>> which is even more concise! >> Yes >> >> Thanks, >> Rohit. >> >>> [1] The old RPM SMD platforms have some duplications in the names.. >>> No point in duplicating that. The oldest entries remember 2013 so >>> it's easy to see how we had some dirt build up there. >>> >>> Konrad >>>> Thanks, >>>> Rohit. >>>>>> /* SA8775P Power Domain Indexes */ >>>>>> #define SA8775P_CX 0 >>>>>> #define SA8775P_CX_AO 1 >>>>>> -- >>>>>> 2.7.4 >>>>>> >>>>> Thanks, >>>>> Pavan
diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h index 83be996..6498251 100644 --- a/include/dt-bindings/power/qcom-rpmpd.h +++ b/include/dt-bindings/power/qcom-rpmpd.h @@ -4,6 +4,55 @@ #ifndef _DT_BINDINGS_POWER_QCOM_RPMPD_H #define _DT_BINDINGS_POWER_QCOM_RPMPD_H +/* Generic RPMH Power Domain Indexes */ +#define RPMHPD_CX 0 +#define RPMHPD_MX 1 +#define RPMHPD_CX_AO 2 +#define RPMHPD_MX_AO 3 +#define RPMHPD_GFX 4 +#define RPMHPD_MSS 5 +#define RPMHPD_EBI 6 +#define RPMHPD_LCX 7 +#define RPMHPD_LMX 8 +#define RPMHPD_MMCX 9 +#define RPMHPD_MMCX_AO 10 +#define RPMHPD_MXC 11 +#define RPMHPD_MXC_AO 12 +#define RPMHPD_NSP 13 +#define RPMHPD_NSP0 14 +#define RPMHPD_NSP1 15 +#define RPMHPD_QPHY 16 +#define RPMHPD_DDR 17 +#define RPMHPD_XO 18 + +/* Generic RPM Power Domain Indexes */ +#define RPMPD_VDDCX 0 +#define RPMPD_VDDCX_AO 1 +#define RPMPD_VDDMX 2 +#define RPMPD_VDDMX_AO 3 +#define RPMPD_VDDCX_VFL 4 +#define RPMPD_VDDMX_VFL 5 +#define RPMPD_VDDCX_VFC 6 +#define RPMPD_LPI_CX 7 +#define RPMPD_LPI_MX 8 +#define RPMPD_SSCCX 9 +#define RPMPD_SSCCX_VFL 10 +#define RPMPD_SSCMX 11 +#define RPMPD_SSCMX_VFL 12 +#define RPMPD_VDDSSCX 13 +#define RPMPD_VDDSSCX_VFC 14 +#define RPMPD_VDDGFX 15 +#define RPMPD_VDDGFX_VFC 16 +#define RPMPD_VDDGX 17 +#define RPMPD_VDDGX_AO 18 +#define RPMPD_VDDMDCX 19 +#define RPMPD_VDDMDCX_AO 20 +#define RPMPD_VDDMDCX_VFC 21 +#define RPMPD_VDDMD 22 +#define RPMPD_VDDMD_AO 23 +#define RPMPD_LPICX_VFL 24 +#define RPMPD_LPIMX_VFL 25 + /* SA8775P Power Domain Indexes */ #define SA8775P_CX 0 #define SA8775P_CX_AO 1