[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77991119-a200-fbfe-5dba-580a0b0d3228@quicinc.com>
Date: Wed, 12 Jul 2023 13:54:04 +0530
From: Rohit Agarwal <quic_rohiagar@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
<agross@...nel.org>, <andersson@...nel.org>,
<konrad.dybcio@...aro.org>, <robh+dt@...nel.org>,
<krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>
CC: <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] dt-bindings: power: rpmhpd: Add Generic RPMh PD
indexes
On 7/11/2023 8:41 PM, Dmitry Baryshkov wrote:
> On 11/07/2023 08:42, Rohit Agarwal wrote:
>> Add Generic RPMh Power Domain indexes that can be used
>> for all the Qualcomm SoC henceforth.
>>
>> Signed-off-by: Rohit Agarwal <quic_rohiagar@...cinc.com>
>> Suggested-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>> ---
>> include/dt-bindings/power/qcom-rpmhpd.h | 30
>> ++++++++++++++++++++++++++++++
>> 1 file changed, 30 insertions(+)
>> create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h
>>
>> diff --git a/include/dt-bindings/power/qcom-rpmhpd.h
>> b/include/dt-bindings/power/qcom-rpmhpd.h
>> new file mode 100644
>> index 0000000..4da2e04
>> --- /dev/null
>> +++ b/include/dt-bindings/power/qcom-rpmhpd.h
>> @@ -0,0 +1,30 @@
>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
>> +/*
>> + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights
>> reserved.
>> + */
>> +
>> +#ifndef _DT_BINDINGS_POWER_QCOM_RPMHPD_H
>> +#define _DT_BINDINGS_POWER_QCOM_RPMHPD_H
>> +
>> +/* Generic RPMH Power Domain Indexes */
>> +#define CX 0
>> +#define MX 1
>> +#define CX_AO 2
>> +#define MX_AO 3
>> +#define GFX 4
>> +#define MSS 5
>> +#define EBI 6
>> +#define LCX 7
>> +#define LMX 8
>> +#define MMCX 9
>> +#define MMCX_AO 10
>> +#define MXC 11
>> +#define MXC_AO 12
>> +#define NSP 13
>> +#define NSP0 14
>> +#define NSP1 15
>> +#define QPHY 16
>> +#define DDR 17
>> +#define XO 18
>
> I went through the existing defines. If we adopt the order of defines
> for sm8550, we can migrate that platform and all of sm8[234]50 without
> breaking ABI. This would be a minor gain, but still something.
>
Actually, I added them in the sequence based on the frequency with which
they occur in the driver, so that there are less NULL entries created
for any target additions. Shouldnt we keep it this way and ignore for
previous targets then?
Thanks,
Rohit.
>> +
>> +#endif
>
Powered by blists - more mailing lists