| Message ID | 20190110040209.6028-1-rnayak@codeaurora.org |
|---|---|
| Headers | show |
| Series | Add power domain driver for corners on msm8996/sdm845 | expand |
On 10-01-19, 09:32, Rajendra Nayak wrote: > Now that the OPP bindings are updated to include an optional > 'opp-level' property, add support to parse it from device tree > and store it as part of dev_pm_opp structure. > Also add and export an helper 'dev_pm_opp_get_level()' that can be > used to get the level value read from device tree when present. > > Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> > --- > drivers/opp/core.c | 18 ++++++++++++++++++ > drivers/opp/of.c | 2 ++ > drivers/opp/opp.h | 2 ++ > include/linux/pm_opp.h | 7 +++++++ > 4 files changed, 29 insertions(+) > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index e5507add8f04..90b78a122be9 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -130,6 +130,24 @@ unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp) > } > EXPORT_SYMBOL_GPL(dev_pm_opp_get_freq); > > +/** > + * dev_pm_opp_get_level() - Gets the level corresponding to an available opp > + * @opp: opp for which level value has to be returned for > + * > + * Return: level read from device tree corresponding to the opp, else > + * return 0. > + */ > +unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp) > +{ > + if (IS_ERR_OR_NULL(opp) || !opp->available) { > + pr_err("%s: Invalid parameters\n", __func__); > + return 0; > + } > + > + return opp->level; > +} > +EXPORT_SYMBOL_GPL(dev_pm_opp_get_level); > + > /** > * dev_pm_opp_is_turbo() - Returns if opp is turbo OPP or not > * @opp: opp for which turbo mode is being verified > diff --git a/drivers/opp/of.c b/drivers/opp/of.c > index 06f0f632ec47..1779f2c93291 100644 > --- a/drivers/opp/of.c > +++ b/drivers/opp/of.c > @@ -594,6 +594,8 @@ static struct dev_pm_opp *_opp_add_static_v2(struct opp_table *opp_table, > new_opp->rate = (unsigned long)rate; > } > > + of_property_read_u32(np, "opp-level", &new_opp->level); > + > /* Check if the OPP supports hardware's hierarchy of versions or not */ > if (!_opp_is_supported(dev, opp_table, np)) { > dev_dbg(dev, "OPP not supported by hardware: %llu\n", rate); > diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h > index e24d81497375..4458175aa661 100644 > --- a/drivers/opp/opp.h > +++ b/drivers/opp/opp.h > @@ -60,6 +60,7 @@ extern struct list_head opp_tables; > * @suspend: true if suspend OPP > * @pstate: Device's power domain's performance state. > * @rate: Frequency in hertz > + * @level: Performance level > * @supplies: Power supplies voltage/current values > * @clock_latency_ns: Latency (in nanoseconds) of switching to this OPP's > * frequency from any other OPP's frequency. > @@ -80,6 +81,7 @@ struct dev_pm_opp { > bool suspend; > unsigned int pstate; > unsigned long rate; > + unsigned int level; > > struct dev_pm_opp_supply *supplies; > > diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h > index 0a2a88e5a383..473d2c7516f0 100644 > --- a/include/linux/pm_opp.h > +++ b/include/linux/pm_opp.h > @@ -86,6 +86,8 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp); > > unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp); > > +unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp); > + > bool dev_pm_opp_is_turbo(struct dev_pm_opp *opp); > > int dev_pm_opp_get_opp_count(struct device *dev); > @@ -157,6 +159,11 @@ static inline unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp) > return 0; > } > > +static inline unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp) > +{ > + return 0; > +} > + > static inline bool dev_pm_opp_is_turbo(struct dev_pm_opp *opp) > { > return false; Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Rafael On 10-01-19, 09:32, Rajendra Nayak wrote: > Changes in v11: > * Updated opp-level binding description based on feedback > from Viresh > * Other minor fixups in 'PATCH 2/9' > Documentation/devicetree/bindings/opp/opp.txt | 3 + > .../devicetree/bindings/power/qcom,rpmpd.txt | 145 +++++++ > arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 ++ > arch/arm64/boot/dts/qcom/sdm845.dtsi | 51 +++ > drivers/opp/core.c | 18 + > drivers/opp/of.c | 2 + > drivers/opp/opp.h | 2 + > drivers/soc/qcom/Kconfig | 18 + > drivers/soc/qcom/Makefile | 2 + > drivers/soc/qcom/rpmhpd.c | 402 ++++++++++++++++++ > drivers/soc/qcom/rpmpd.c | 317 ++++++++++++++ > include/dt-bindings/power/qcom-rpmpd.h | 39 ++ > include/linux/pm_opp.h | 7 + > 13 files changed, 1040 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt > create mode 100644 drivers/soc/qcom/rpmhpd.c > create mode 100644 drivers/soc/qcom/rpmpd.c > create mode 100644 include/dt-bindings/power/qcom-rpmpd.h Rafael/Ulf: Who should pick this series ? Should I take this via OPP tree ?
Quoting Rajendra Nayak (2019-01-09 20:02:02) > Now that the OPP bindings are updated to include an optional > 'opp-level' property, add support to parse it from device tree > and store it as part of dev_pm_opp structure. > Also add and export an helper 'dev_pm_opp_get_level()' that can be > used to get the level value read from device tree when present. > > Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> > --- Reviewed-by: Stephen Boyd <swboyd@chromium.org>
On Wed 09 Jan 22:33 PST 2019, Viresh Kumar wrote: > +Rafael > > On 10-01-19, 09:32, Rajendra Nayak wrote: > > Changes in v11: > > * Updated opp-level binding description based on feedback > > from Viresh > > * Other minor fixups in 'PATCH 2/9' > > > Documentation/devicetree/bindings/opp/opp.txt | 3 + > > .../devicetree/bindings/power/qcom,rpmpd.txt | 145 +++++++ > > arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 ++ > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 51 +++ > > drivers/opp/core.c | 18 + > > drivers/opp/of.c | 2 + > > drivers/opp/opp.h | 2 + > > drivers/soc/qcom/Kconfig | 18 + > > drivers/soc/qcom/Makefile | 2 + > > drivers/soc/qcom/rpmhpd.c | 402 ++++++++++++++++++ > > drivers/soc/qcom/rpmpd.c | 317 ++++++++++++++ > > include/dt-bindings/power/qcom-rpmpd.h | 39 ++ > > include/linux/pm_opp.h | 7 + > > 13 files changed, 1040 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt > > create mode 100644 drivers/soc/qcom/rpmhpd.c > > create mode 100644 drivers/soc/qcom/rpmpd.c > > create mode 100644 include/dt-bindings/power/qcom-rpmpd.h > > Rafael/Ulf: Who should pick this series ? Should I take this via OPP > tree ? > Given that the weight of the patches lies in arm-soc area it could be favourable to just take them that way, with the one opp-patch carrying your (Rafael's?) ack. If you prefer otherwise, I suggest that we take patch 6 and 8 (the two dts patches) through arm-soc and you merge the rest in your tree. Regards, Bjorn
On Wed, 16 Jan 2019 at 06:52, Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > > On Wed 09 Jan 22:33 PST 2019, Viresh Kumar wrote: > > > +Rafael > > > > On 10-01-19, 09:32, Rajendra Nayak wrote: > > > Changes in v11: > > > * Updated opp-level binding description based on feedback > > > from Viresh > > > * Other minor fixups in 'PATCH 2/9' > > > > > Documentation/devicetree/bindings/opp/opp.txt | 3 + > > > .../devicetree/bindings/power/qcom,rpmpd.txt | 145 +++++++ > > > arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 ++ > > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 51 +++ > > > drivers/opp/core.c | 18 + > > > drivers/opp/of.c | 2 + > > > drivers/opp/opp.h | 2 + > > > drivers/soc/qcom/Kconfig | 18 + > > > drivers/soc/qcom/Makefile | 2 + > > > drivers/soc/qcom/rpmhpd.c | 402 ++++++++++++++++++ > > > drivers/soc/qcom/rpmpd.c | 317 ++++++++++++++ > > > include/dt-bindings/power/qcom-rpmpd.h | 39 ++ > > > include/linux/pm_opp.h | 7 + > > > 13 files changed, 1040 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt > > > create mode 100644 drivers/soc/qcom/rpmhpd.c > > > create mode 100644 drivers/soc/qcom/rpmpd.c > > > create mode 100644 include/dt-bindings/power/qcom-rpmpd.h > > > > Rafael/Ulf: Who should pick this series ? Should I take this via OPP > > tree ? > > > > Given that the weight of the patches lies in arm-soc area it could be > favourable to just take them that way, with the one opp-patch carrying > your (Rafael's?) ack. > > If you prefer otherwise, I suggest that we take patch 6 and 8 (the two > dts patches) through arm-soc and you merge the rest in your tree. It sure sounds easiest to funnel this though the soc maintainer tree, unless Viresh think there are lots of additional changes to the OPP core going in this cycle, which thus may conflict. However, it's not my call. Kind regards Uffe
On 15-01-19, 21:52, Bjorn Andersson wrote: > On Wed 09 Jan 22:33 PST 2019, Viresh Kumar wrote: > > > +Rafael > > > > On 10-01-19, 09:32, Rajendra Nayak wrote: > > > Changes in v11: > > > * Updated opp-level binding description based on feedback > > > from Viresh > > > * Other minor fixups in 'PATCH 2/9' > > > > > Documentation/devicetree/bindings/opp/opp.txt | 3 + > > > .../devicetree/bindings/power/qcom,rpmpd.txt | 145 +++++++ > > > arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 ++ > > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 51 +++ > > > drivers/opp/core.c | 18 + > > > drivers/opp/of.c | 2 + > > > drivers/opp/opp.h | 2 + > > > drivers/soc/qcom/Kconfig | 18 + > > > drivers/soc/qcom/Makefile | 2 + > > > drivers/soc/qcom/rpmhpd.c | 402 ++++++++++++++++++ > > > drivers/soc/qcom/rpmpd.c | 317 ++++++++++++++ > > > include/dt-bindings/power/qcom-rpmpd.h | 39 ++ > > > include/linux/pm_opp.h | 7 + > > > 13 files changed, 1040 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt > > > create mode 100644 drivers/soc/qcom/rpmhpd.c > > > create mode 100644 drivers/soc/qcom/rpmpd.c > > > create mode 100644 include/dt-bindings/power/qcom-rpmpd.h > > > > Rafael/Ulf: Who should pick this series ? Should I take this via OPP > > tree ? > > > > Given that the weight of the patches lies in arm-soc area it could be > favourable to just take them that way, with the one opp-patch carrying > your (Rafael's?) ack. > > If you prefer otherwise, I suggest that we take patch 6 and 8 (the two > dts patches) through arm-soc and you merge the rest in your tree. Okay, take it via arm-soc. I will ask for a branch later on if I find more patches going for the OPP core this cycle.
On Thu, Jan 10, 2019 at 09:32:04AM +0530, Rajendra Nayak wrote: > The Power domains for corners just pass the performance state set by the > consumers to the RPM (Remote Power manager) which then takes care > of setting the appropriate voltage on the corresponding rails to > meet the performance needs. > > We add all power domain data needed on msm8996 here. This driver can easily > be extended by adding data for other qualcomm SoCs as well. > > Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> > Acked-by: Rob Herring <robh@kernel.org> > Reviewed-by: Stephen Boyd <swboyd@chromium.org> > --- > drivers/soc/qcom/Kconfig | 9 ++ > drivers/soc/qcom/Makefile | 1 + > drivers/soc/qcom/rpmpd.c | 282 ++++++++++++++++++++++++++++++++++++++ > 3 files changed, 292 insertions(+) > create mode 100644 drivers/soc/qcom/rpmpd.c > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig > index fcbf8a2e4080..df5cd9fa0d5e 100644 > --- a/drivers/soc/qcom/Kconfig > +++ b/drivers/soc/qcom/Kconfig > @@ -98,6 +98,15 @@ config QCOM_RPMH > of hardware components aggregate requests for these resources and > help apply the aggregated state on the resource. > > +config QCOM_RPMPD > + bool "Qualcomm RPM Power domain driver" > + depends on MFD_QCOM_RPM && QCOM_SMD_RPM Since this is bool, but the dependent configurations are tristate, configurations such as arm64:allmodconfig result in CONFIG_QCOM_RPMPD=y CONFIG_MFD_QCOM_RPM=m CONFIG_QCOM_SMD_RPM=m This in turn results in arm-linux-gnueabi-ld: drivers/soc/qcom/rpmpd.o: in function `rpmpd_send_enable': >> rpmpd.c:(.text+0x64): undefined reference to `qcom_rpm_smd_write' arm-linux-gnueabi-ld: drivers/soc/qcom/rpmpd.o: in function `rpmpd_power_on': rpmpd.c:(.text+0x408): undefined reference to `qcom_rpm_smd_write' >> arm-linux-gnueabi-ld: rpmpd.c:(.text+0x460): undefined reference to `qcom_rpm_smd_write' as reported by 0day. Either this needs to change to tristate, or the dependency must be depends on MFD_QCOM_RPM=y && QCOM_SMD_RPM=y Guenter
[].. >> >> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig >> index fcbf8a2e4080..df5cd9fa0d5e 100644 >> --- a/drivers/soc/qcom/Kconfig >> +++ b/drivers/soc/qcom/Kconfig >> @@ -98,6 +98,15 @@ config QCOM_RPMH >> of hardware components aggregate requests for these resources and >> help apply the aggregated state on the resource. >> >> +config QCOM_RPMPD >> + bool "Qualcomm RPM Power domain driver" >> + depends on MFD_QCOM_RPM && QCOM_SMD_RPM > > Since this is bool, but the dependent configurations are tristate, > configurations such as arm64:allmodconfig result in > > CONFIG_QCOM_RPMPD=y > CONFIG_MFD_QCOM_RPM=m > CONFIG_QCOM_SMD_RPM=m > > This in turn results in > > arm-linux-gnueabi-ld: drivers/soc/qcom/rpmpd.o: in function `rpmpd_send_enable': >>> rpmpd.c:(.text+0x64): undefined reference to `qcom_rpm_smd_write' > arm-linux-gnueabi-ld: drivers/soc/qcom/rpmpd.o: in function `rpmpd_power_on': > rpmpd.c:(.text+0x408): undefined reference to `qcom_rpm_smd_write' >>> arm-linux-gnueabi-ld: rpmpd.c:(.text+0x460): undefined reference to `qcom_rpm_smd_write' > > as reported by 0day. Thanks for reporting this, the QCOM_RPMPD dependency on MFD_QCOM_RPM was removed by a patch on top from Bjorn [1]. I have posted a fix now [2] to make QCOM_RPMPD depend on QCOM_SMD_RPM=y [1] https://lkml.org/lkml/2019/1/17/5 [2] https://lkml.org/lkml/2019/1/17/1043