linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Stephan Gerhold <stephan@gerhold.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Loic Poulain <loic.poulain@linaro.org>,
	Andy Gross <agross@kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Lina Iyer <ilina@codeaurora.org>
Subject: Re: [PATCH] arch: arm64: dts: apq8016-dbc: Add missing cpu opps
Date: Fri, 8 May 2020 14:08:09 +0200	[thread overview]
Message-ID: <CAPDyKFohjoY0rsTwVGQY_csDRfvxF0RiU+d12EpC+mk6BC95gA@mail.gmail.com> (raw)
In-Reply-To: <20200507053435.GC3236072@builder.lan>

+ Lina

On Thu, 7 May 2020 at 07:33, Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
>
> On Wed 06 May 14:18 PDT 2020, Stephan Gerhold wrote:
>
> Viresh, Ulf,
>
> Stephan is trying to describe the relationship between the CPU rail and
> the memory rail on db410c (where the performance state of the memory
> rail needs to be kept above the performance state of the CPU supply.
>
> The latter is modelled as a power-domain and the performance state
> changes as expected, but no one enables the power-domain.

Just to make one thing clear, from a genpd framework point of view,
power on/off of a genpd is orthogonal to setting/aggregating
performance states for it.

It's instead up to the genpd provider to deal with this (as I
understand, that seems to be the issue from the below discussions).

>
> What's the appropriate method for ensuring the power-domain is
> enabled/disabled as needed? Should it be referenced in the hierarchical
> power domain for the CPUs perhaps?

If I understand the dependency correctly, perhaps you are right that
there needs to be a subdomain assigned. Although, I don't know if this
ever has been tested to work for a real use case, when it comes to
performance state propagations upwards in the hierarchy.

Viresh?

If you also need to manage genpd power on/off, that should be managed
by using runtime PM reference counting on those devices that are
attached to the genpd in question.

Kind regards
Uffe


>
> Regards,
> Bjorn
>
> > Hi,
> >
> > On Sun, Apr 26, 2020 at 02:31:48PM +0200, Stephan Gerhold wrote:
> > > On Wed, Apr 22, 2020 at 09:55:06PM -0700, Bjorn Andersson wrote:
> > > > On Fri 03 Apr 11:00 PDT 2020, Stephan Gerhold wrote:
> > > >
> > > > > On Fri, Apr 03, 2020 at 12:09:25PM +0200, Stephan Gerhold wrote:
> > > > > > On Thu, Apr 02, 2020 at 06:31:19PM -0700, Bjorn Andersson wrote:
> > > > > > > On Thu 02 Apr 01:13 PDT 2020, Stephan Gerhold wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Wed, Apr 01, 2020 at 07:50:59PM +0200, Loic Poulain wrote:
> > > > > > > > > The highest cpu frequency opps have been dropped because CPR is not
> > > > > > > > > supported. However, we can simply specify operating voltage so that
> > > > > > > > > they match the max corner voltages for each freq. With that, we can
> > > > > > > > > support up to 1.36Ghz. Ideally, msm8916 CPR should be implemented to
> > > > > > > > > fine tune operating voltages and optimize power consumption.
> > > > > > > >
> > > > > > > > Thanks for the patch! I was wondering how to enable the higher CPU
> > > > > > > > frequencies for a while now...
> > > > > > > >
> > > > > > > > I was actually quite excited to see CPR being mainlined for QCS404.
> > > > > > > > If we are trying to add such a workaround (rather than CPR) for MSM8916
> > > > > > > > now, does that mean it's unlikely to see CPR working for MSM8916
> > > > > > > > anytime soon?
> > > > > > > >
> > > > > > > > AFAICT, there is a WIP branch from Niklas Cassel here:
> > > > > > > > https://git.linaro.org/people/nicolas.dechesne/niklas.cassel/kernel.git/log/?h=cpr-msm8916-mainline
> > > > > > > > but it hasn't been updated for a while. (Not sure if it was working
> > > > > > > > already...)
> > > > > > > >
> > > > > > > > Can someone explain what is missing to make CPR work for MSM8916?
> > > > > > > >
> > > > > > >
> > > > > > > CPR needs to control 3 things; VDD_APC, VDD_MX and MEMACC. On QCS404 it
> > > > > > > seems we don't have to adjust VDD_MX, so the code for this is missing
> > > > > > > from the driver.
> > > > > > >
> > > > > > > So, afaict, what's missing is that rpmpd.c needs to gain support for
> > > > > > > 8916, then the CPR driver needs to gain a cpr_acc_desc and compatible
> > > > > > > for 8916, it needs to reference the VDDMX power domain and before/after
> > > > > > > we're adjusting the corner of the CPR we need to adjust the MX according
> > > > > > > to the mapping specified in the downstream kernel (i.e.  1->4, 2->5 and
> > > > > > > 3->7).
> > > > > > >
> > > > > > >
> > > > > > > Unfortunately, the requirement that VDDMX (VDD_MEM I presume) must be
> > > > > > > higher than VDD_APC most likely needs to be taken into consideration for
> > > > > > > Loic's proposed static voltage scaling as well. Unless VDD_MEM is left
> > > > > > > in Turbo mode from the boot loader I think we need to take VDDMX to
> > > > > > > corner 7 for speeds 998MHz and above (i.e. where we pull VDD_APC to
> > > > > > > 1.35V).
> > > > > > >
> > > > > >
> > > > > > I see! I wonder how hard it would be to add MSM8916 to rpmpd,
> > > > > > looking at previous commits it's mainly setting up a few defines?
> > > > > >
> > > > > > If I understand it correctly, the OPPs from rpmpd could then be
> > > > > > referenced as "required-opps" in the CPU OPP table so that VDD_MX is
> > > > > > scaled together with the CPU frequency, and doesn't need to stay at
> > > > > > turbo mode (like in v3 from Loic) the whole time.
> > > > > >
> > > > >
> > > > > I have been thinking about this some more and I think I came up with
> > > > > some changes that make sense (but not entirely sure).
> > > > >
> > > > > Based on the available downstream sources I guessed the defines to add
> > > > > for MSM8916 to the rpmpd driver. Then I added the VDD_MX OPPs as
> > > > > "required-opps" to the CPU OPP table so it would vote for the appopriate
> > > > > corners (with the mapping you mentioned above).
> > > > >
> > > >
> > > > I was not aware it was possible to describe the dependency between the
> > > > CPU opp table and MX in this fashion. If that's the case then this looks
> > > > really good and it should be straight forward to add MSM8916 support to
> > > > the CPR driver as well.
> > > >
> > >
> > > Indeed!
> > >
> > > > > I haven't tested it yet, maybe I can get some feedback first if the code
> > > > > seems reasonable or if I'm missing something obvious? :)
> > > > >
> > > >
> > > > Have you tested this yet?
> > > >
> > >
> > > I just did. It does not fully work, yet:
> > >
> > > rpmpd_set_performance() is indeed called as necessary when switching the
> > > CPU frequency. When I set 200 MHz it sets corner 3, with 533 MHz corner 4
> > > and starting with 998 MHz corner 6. So far so good :)
> > >
> > > However, there is never actually anything sent to the RPM. :(
> > > It bails out in rpmpd_set_performance() before calling rpmpd_aggregate_corner():
> > >
> > >     /* Always send updates for vfc and vfl */
> > >     if (!pd->enabled && pd->key != KEY_FLOOR_CORNER &&
> > >         pd->key != KEY_FLOOR_LEVEL)
> > >             goto out;
> > >
> > > Seems like we just try to set performance states, but never actually
> > > enable (rpmpd_power_on()) the power domain (pd->enabled == false).
> > >
> > > I'm not sure which of the components involved here should handle that.
> > > The OPP core when setting required OPPs, the genpd core etc.
> > >
> > > Any ideas?
> > >
> > > Thanks,
> > > Stephan
> > >
> >
> > For now I have added something to qcom-cpufreq-nvmem.c to power on/enable
> > the power domain (not really sure if it belongs there...):
> >
> > diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> > index a1b8238872a2..ed352ead037e 100644
> > --- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
> > +++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> > @@ -26,6 +26,7 @@
> >  #include <linux/platform_device.h>
> >  #include <linux/pm_domain.h>
> >  #include <linux/pm_opp.h>
> > +#include <linux/pm_runtime.h>
> >  #include <linux/slab.h>
> >  #include <linux/soc/qcom/smem.h>
> >
> > @@ -370,10 +371,13 @@ static int qcom_cpufreq_probe(struct platform_device *pdev)
> >               }
> >
> >               if (drv->data->genpd_names) {
> > +                     struct device **pd_dev;
> > +                     const char **name = drv->data->genpd_names;
> > +
> >                       drv->genpd_opp_tables[cpu] =
> >                               dev_pm_opp_attach_genpd(cpu_dev,
> >                                                       drv->data->genpd_names,
> > -                                                     NULL);
> > +                                                     &pd_dev);
> >                       if (IS_ERR(drv->genpd_opp_tables[cpu])) {
> >                               ret = PTR_ERR(drv->genpd_opp_tables[cpu]);
> >                               if (ret != -EPROBE_DEFER)
> > @@ -382,6 +386,12 @@ static int qcom_cpufreq_probe(struct platform_device *pdev)
> >                                               ret);
> >                               goto free_genpd_opp;
> >                       }
> > +
> > +                     while (*name) {
> > +                             pm_runtime_get_sync(*pd_dev);
> > +                             name++;
> > +                             pd_dev++;
> > +                     }
> >               }
> >       }
> >
> > I really wonder why this doesn't affect CPR (or does it?).
> > So far I was not able to find anything that would power on/enable
> > the "cpr" power domain either. But I don't have a qcs404 to verify.
> >
> > As far as I can tell from the log, the corner votes are correctly sent
> > to the RPM now when the CPU frequency is changed.
> >
> > However...
> >
> > > > > Also: Is there a good way to validate these changes?
> > > > > I suppose I could check the genpd state but that wouldn't tell me if the
> > > > > corner was applied correctly. Maybe I can check the actual voltage
> > > > > through the SPMI interface, hm...
> > > > >
> > > >
> > > > Validating that S2 and VDD_MX changes appropriately in Linux would be a
> > > > pretty good test.
> > > >
> >
> > Unfortunately I was not able to see any change in the voltage of L3 yet.
> > On samsung-a5u, /sys/class/regulator/<l3 spmi regulator>/microvolts
> > permanently reports 1300000 uV, even after a few different corner votes.
> >
> > I'm not sure if:
> >
> >   - This is normal (maybe some other remoteproc has a higher vote?)
> >     - I tried to disable wcnss, venus and hexagon without difference
> >
> >   - I'm just missing something in the code
> >
> >   - This is some peculiarity of the RPM firmware on samsung-a5u.
> >     (Although that seems quite unlikely to me...)
> >
> > Any ideas? :/
> >
> > Thanks,
> > Stephan
> >
> > > > > If this seems like a good approach I can split up the changes in
> > > > > reasonable patches and post it separately. For now the full diff below.
> > > > >
> > > >
> > > > Please do
> > > >
> > > > Regards,
> > > > Bjorn
> > > >
> > > > > Stephan
> > > > >
> > > > >  arch/arm64/boot/dts/qcom/msm8916.dtsi  | 65 +++++++++++++++++++++++++++++-----
> > > > >  drivers/cpufreq/cpufreq-dt-platdev.c   |  1 +
> > > > >  drivers/cpufreq/qcom-cpufreq-nvmem.c   | 11 ++++++
> > > > >  drivers/soc/qcom/rpmpd.c               | 21 +++++++++++
> > > > >  include/dt-bindings/power/qcom-rpmpd.h |  7 ++++
> > > > >  5 files changed, 96 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> > > > > index b0a82447976a..5b8fce8609d0 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> > > > > +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> > > > > @@ -10,6 +10,7 @@
> > > > >  #include <dt-bindings/soc/qcom,apr.h>
> > > > >  #include <dt-bindings/sound/qcom,q6afe.h>
> > > > >  #include <dt-bindings/thermal/thermal.h>
> > > > > +#include <dt-bindings/power/qcom-rpmpd.h>
> > > > >
> > > > >  / {
> > > > >         interrupt-parent = <&intc>;
> > > > > @@ -108,8 +109,8 @@ CPU0: cpu@0 {
> > > > >                         cpu-supply = <&pm8916_spmi_s2>;
> > > > >                         operating-points-v2 = <&cpu_opp_table>;
> > > > >                         #cooling-cells = <2>;
> > > > > -                       power-domains = <&CPU_PD0>;
> > > > > -                       power-domain-names = "psci";
> > > > > +                       power-domains = <&CPU_PD0>, <&rpmpd MSM8916_VDDMX_AO>;
> > > > > +                       power-domain-names = "psci", "mx";
> > > > >                 };
> > > > >
> > > > >                 CPU1: cpu@1 {
> > > > > @@ -122,8 +123,8 @@ CPU1: cpu@1 {
> > > > >                         cpu-supply = <&pm8916_spmi_s2>;
> > > > >                         operating-points-v2 = <&cpu_opp_table>;
> > > > >                         #cooling-cells = <2>;
> > > > > -                       power-domains = <&CPU_PD1>;
> > > > > -                       power-domain-names = "psci";
> > > > > +                       power-domains = <&CPU_PD1>, <&rpmpd MSM8916_VDDMX_AO>;
> > > > > +                       power-domain-names = "psci", "mx";
> > > > >                 };
> > > > >
> > > > >                 CPU2: cpu@2 {
> > > > > @@ -136,8 +137,8 @@ CPU2: cpu@2 {
> > > > >                         cpu-supply = <&pm8916_spmi_s2>;
> > > > >                         operating-points-v2 = <&cpu_opp_table>;
> > > > >                         #cooling-cells = <2>;
> > > > > -                       power-domains = <&CPU_PD2>;
> > > > > -                       power-domain-names = "psci";
> > > > > +                       power-domains = <&CPU_PD2>, <&rpmpd MSM8916_VDDMX_AO>;
> > > > > +                       power-domain-names = "psci", "mx";
> > > > >                 };
> > > > >
> > > > >                 CPU3: cpu@3 {
> > > > > @@ -150,8 +151,8 @@ CPU3: cpu@3 {
> > > > >                         cpu-supply = <&pm8916_spmi_s2>;
> > > > >                         operating-points-v2 = <&cpu_opp_table>;
> > > > >                         #cooling-cells = <2>;
> > > > > -                       power-domains = <&CPU_PD3>;
> > > > > -                       power-domain-names = "psci";
> > > > > +                       power-domains = <&CPU_PD3>, <&rpmpd MSM8916_VDDMX_AO>;
> > > > > +                       power-domain-names = "psci", "mx";
> > > > >                 };
> > > > >
> > > > >                 L2_0: l2-cache {
> > > > > @@ -343,40 +344,52 @@ modem_alert0: trip-point@0 {
> > > > >         };
> > > > >
> > > > >         cpu_opp_table: cpu_opp_table {
> > > > > -               compatible = "operating-points-v2";
> > > > > +               /*
> > > > > +                * FIXME: The naming here is really weird, since MSM8916 does
> > > > > +                * not have kyro. Maybe we should add a more generic compatible?
> > > > > +                */
> > > > > +               compatible = "operating-points-v2-kryo-cpu";
> > > > >                 opp-shared;
> > > > >
> > > > >                 opp-200000000 {
> > > > >                         opp-hz = /bits/ 64 <200000000>;
> > > > >                         opp-microvolt = <1050000>;
> > > > > +                       required-opps = <&rpmpd_opp_svs_soc>;
> > > > >                 };
> > > > >                 opp-400000000 {
> > > > >                         opp-hz = /bits/ 64 <400000000>;
> > > > >                         opp-microvolt = <1050000>;
> > > > > +                       required-opps = <&rpmpd_opp_svs_soc>;
> > > > >                 };
> > > > >                 opp-533330000 {
> > > > >                         opp-hz = /bits/ 64 <533330000>;
> > > > >                         opp-microvolt = <1150000>;
> > > > > +                       required-opps = <&rpmpd_opp_nom>;
> > > > >                 };
> > > > >                 opp-800000000 {
> > > > >                         opp-hz = /bits/ 64 <800000000>;
> > > > >                         opp-microvolt = <1150000>;
> > > > > +                       required-opps = <&rpmpd_opp_nom>;
> > > > >                 };
> > > > >                 opp-998400000 {
> > > > >                         opp-hz = /bits/ 64 <998400000>;
> > > > >                         opp-microvolt = <1350000>;
> > > > > +                       required-opps = <&rpmpd_opp_super_turbo>;
> > > > >                 };
> > > > >                 opp-1094400000 {
> > > > >                         opp-hz = /bits/ 64 <1094400000>;
> > > > >                         opp-microvolt = <1350000>;
> > > > > +                       required-opps = <&rpmpd_opp_super_turbo>;
> > > > >                 };
> > > > >                 opp-1152000000 {
> > > > >                         opp-hz = /bits/ 64 <1152000000>;
> > > > >                         opp-microvolt = <1350000>;
> > > > > +                       required-opps = <&rpmpd_opp_super_turbo>;
> > > > >                 };
> > > > >                 opp-1209600000 {
> > > > >                         opp-hz = /bits/ 64 <1209600000>;
> > > > >                         opp-microvolt = <1350000>;
> > > > > +                       required-opps = <&rpmpd_opp_super_turbo>;
> > > > >                 };
> > > > >         };
> > > > >
> > > > > @@ -1710,6 +1723,40 @@ rpmcc: qcom,rpmcc {
> > > > >                                         #clock-cells = <1>;
> > > > >                                 };
> > > > >
> > > > > +                               rpmpd: power-controller {
> > > > > +                                       compatible = "qcom,msm8916-rpmpd";
> > > > > +                                       #power-domain-cells = <1>;
> > > > > +                                       operating-points-v2 = <&rpmpd_opp_table>;
> > > > > +
> > > > > +                                       rpmpd_opp_table: opp-table {
> > > > > +                                               compatible = "operating-points-v2";
> > > > > +
> > > > > +                                               rpmpd_opp_ret: opp1 {
> > > > > +                                                       opp-level = <1>;
> > > > > +                                               };
> > > > > +
> > > > > +                                               rpmpd_opp_svs: opp2 {
> > > > > +                                                       opp-level = <2>;
> > > > > +                                               };
> > > > > +
> > > > > +                                               rpmpd_opp_svs_soc: opp3 {
> > > > > +                                                       opp-level = <3>;
> > > > > +                                               };
> > > > > +
> > > > > +                                               rpmpd_opp_nom: opp4 {
> > > > > +                                                       opp-level = <4>;
> > > > > +                                               };
> > > > > +
> > > > > +                                               rpmpd_opp_turbo: opp5 {
> > > > > +                                                       opp-level = <5>;
> > > > > +                                               };
> > > > > +
> > > > > +                                               rpmpd_opp_super_turbo: opp6 {
> > > > > +                                                       opp-level = <6>;
> > > > > +                                               };
> > > > > +                                       };
> > > > > +                               };
> > > > > +
> > > > >                                 smd_rpm_regulators: pm8916-regulators {
> > > > >                                         compatible = "qcom,rpm-pm8916-regulators";
> > > > >
> > > > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> > > > > index f2ae9cd455c1..b0f6bd0fffc1 100644
> > > > > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > > > > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > > > > @@ -128,6 +128,7 @@ static const struct of_device_id blacklist[] __initconst = {
> > > > >         { .compatible = "nvidia,tegra210", },
> > > > >
> > > > >         { .compatible = "qcom,apq8096", },
> > > > > +       { .compatible = "qcom,msm8916", },
> > > > >         { .compatible = "qcom,msm8996", },
> > > > >         { .compatible = "qcom,qcs404", },
> > > > >
> > > > > diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> > > > > index f0d2d5035413..c77a30349d08 100644
> > > > > --- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
> > > > > +++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> > > > > @@ -129,6 +129,16 @@ static const struct qcom_cpufreq_match_data match_data_kryo = {
> > > > >         .get_version = qcom_cpufreq_kryo_name_version,
> > > > >  };
> > > > >
> > > > > +static const char *msm8916_genpd_names[] = { "mx", NULL };
> > > > > +
> > > > > +static const struct qcom_cpufreq_match_data match_data_msm8916 = {
> > > > > +       /*
> > > > > +        * FIXME: Might need to implement .get_version here to handle
> > > > > +        * different frequencies depending on speedbin/pvs version.
> > > > > +        */
> > > > > +       .genpd_names = msm8916_genpd_names,
> > > > > +};
> > > > > +
> > > > >  static const char *qcs404_genpd_names[] = { "cpr", NULL };
> > > > >
> > > > >  static const struct qcom_cpufreq_match_data match_data_qcs404 = {
> > > > > @@ -301,6 +311,7 @@ static struct platform_driver qcom_cpufreq_driver = {
> > > > >
> > > > >  static const struct of_device_id qcom_cpufreq_match_list[] __initconst = {
> > > > >         { .compatible = "qcom,apq8096", .data = &match_data_kryo },
> > > > > +       { .compatible = "qcom,msm8916", .data = &match_data_msm8916 },
> > > > >         { .compatible = "qcom,msm8996", .data = &match_data_kryo },
> > > > >         { .compatible = "qcom,qcs404", .data = &match_data_qcs404 },
> > > > >         {},
> > > > > diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
> > > > > index 2b1834c5609a..192ba9099964 100644
> > > > > --- a/drivers/soc/qcom/rpmpd.c
> > > > > +++ b/drivers/soc/qcom/rpmpd.c
> > > > > @@ -115,6 +115,26 @@ struct rpmpd_desc {
> > > > >
> > > > >  static DEFINE_MUTEX(rpmpd_lock);
> > > > >
> > > > > +/* msm8916 RPM Power Domains */
> > > > > +DEFINE_RPMPD_PAIR(msm8916, vddcx, vddcx_ao, SMPA, CORNER, 1);
> > > > > +DEFINE_RPMPD_PAIR(msm8916, vddmx, vddmx_ao, LDOA, CORNER, 3);
> > > > > +
> > > > > +DEFINE_RPMPD_VFC(msm8916, vddcx_vfc, SMPA, 1);
> > > > > +
> > > > > +static struct rpmpd *msm8916_rpmpds[] = {
> > > > > +       [MSM8916_VDDCX] =       &msm8916_vddcx,
> > > > > +       [MSM8916_VDDCX_AO] =    &msm8916_vddcx_ao,
> > > > > +       [MSM8916_VDDCX_VFC] =   &msm8916_vddcx_vfc,
> > > > > +       [MSM8916_VDDMX] =       &msm8916_vddmx,
> > > > > +       [MSM8916_VDDMX_AO] =    &msm8916_vddmx_ao,
> > > > > +};
> > > > > +
> > > > > +static const struct rpmpd_desc msm8916_desc = {
> > > > > +       .rpmpds = msm8916_rpmpds,
> > > > > +       .num_pds = ARRAY_SIZE(msm8916_rpmpds),
> > > > > +       .max_state = MAX_8996_RPMPD_STATE,
> > > > > +};
> > > > > +
> > > > >  /* msm8976 RPM Power Domains */
> > > > >  DEFINE_RPMPD_PAIR(msm8976, vddcx, vddcx_ao, SMPA, LEVEL, 2);
> > > > >  DEFINE_RPMPD_PAIR(msm8976, vddmx, vddmx_ao, SMPA, LEVEL, 6);
> > > > > @@ -220,6 +240,7 @@ static const struct rpmpd_desc qcs404_desc = {
> > > > >  };
> > > > >
> > > > >  static const struct of_device_id rpmpd_match_table[] = {
> > > > > +       { .compatible = "qcom,msm8916-rpmpd", .data = &msm8916_desc },
> > > > >         { .compatible = "qcom,msm8976-rpmpd", .data = &msm8976_desc },
> > > > >         { .compatible = "qcom,msm8996-rpmpd", .data = &msm8996_desc },
> > > > >         { .compatible = "qcom,msm8998-rpmpd", .data = &msm8998_desc },
> > > > > diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
> > > > > index 3f74096d5a7c..70d304a2deae 100644
> > > > > --- a/include/dt-bindings/power/qcom-rpmpd.h
> > > > > +++ b/include/dt-bindings/power/qcom-rpmpd.h
> > > > > @@ -51,6 +51,13 @@
> > > > >  #define RPMH_REGULATOR_LEVEL_TURBO     384
> > > > >  #define RPMH_REGULATOR_LEVEL_TURBO_L1  416
> > > > >
> > > > > +/* MSM8916 Power Domain Indexes */
> > > > > +#define MSM8916_VDDCX          0
> > > > > +#define MSM8916_VDDCX_AO       1
> > > > > +#define MSM8916_VDDCX_VFC      2
> > > > > +#define MSM8916_VDDMX          3
> > > > > +#define MSM8916_VDDMX_AO       4
> > > > > +
> > > > >  /* MSM8976 Power Domain Indexes */
> > > > >  #define MSM8976_VDDCX          0
> > > > >  #define MSM8976_VDDCX_AO       1

  reply	other threads:[~2020-05-08 12:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01 17:50 [PATCH] arch: arm64: dts: apq8016-dbc: Add missing cpu opps Loic Poulain
2020-04-01 23:46 ` Bjorn Andersson
2020-04-02  8:13 ` Stephan Gerhold
2020-04-02  9:58   ` Loic Poulain
2020-04-03  1:31   ` Bjorn Andersson
2020-04-03 10:09     ` Stephan Gerhold
2020-04-03 18:00       ` Stephan Gerhold
2020-04-23  4:55         ` Bjorn Andersson
2020-04-26 12:31           ` Stephan Gerhold
2020-05-06 21:18             ` Stephan Gerhold
2020-05-07  5:34               ` Bjorn Andersson
2020-05-08 12:08                 ` Ulf Hansson [this message]
2020-05-08 13:42                   ` Stephan Gerhold
2020-05-11  5:29                   ` Viresh Kumar
2020-05-07 10:46               ` Stephan Gerhold
2020-05-21 19:18                 ` Stephan Gerhold
2020-05-23 12:08                   ` Stephan Gerhold
2020-05-27 20:47                     ` Georgi Djakov
2020-05-25 15:32           ` Niklas Cassel
2020-05-25 16:36             ` Stephan Gerhold
2020-05-25 19:44               ` Niklas Cassel
2020-05-26  8:59                 ` Stephan Gerhold
2020-05-26 15:54                   ` Niklas Cassel
2020-05-26 20:54                     ` Stephan Gerhold
2020-05-27 10:39                       ` Niklas Cassel
2020-05-27 12:04                         ` Stephan Gerhold
2020-05-27 12:59                           ` Niklas Cassel
2020-05-27 20:56                             ` Stephan Gerhold
2020-05-27 23:10                               ` Niklas Cassel
2020-05-28 13:32                                 ` Stephan Gerhold
2020-05-28  4:44                           ` Viresh Kumar
2020-04-28 20:04 ` Amit Kucheria

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPDyKFohjoY0rsTwVGQY_csDRfvxF0RiU+d12EpC+mk6BC95gA@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=ilina@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=stephan@gerhold.net \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).