From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: "Benoît Cousson" <bcousson@baylibre.com>,
"Tony Lindgren" <tony@atomide.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Adam Ford" <aford173@gmail.com>,
"André Roth" <neolynx@gmail.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"Enric Balletbo i Serra" <eballetbo@gmail.com>,
"Javier Martinez Canillas" <javier@dowhile0.org>,
"Roger Quadros" <rogerq@ti.com>,
"Teresa Remmet" <t.remmet@phytec.de>,
"H. Nikolaus Schaller" <hns@goldelico.com>
Cc: devicetree@vger.kernel.org, linux-omap@vger.kernel.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pyra-handheld.com, letux-kernel@openphoenux.org,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 5/8] cpufreq: ti-cpufreq: omap36xx use "cpu0", "vbb" if run in multi_regulator mode
Date: Wed, 11 Sep 2019 19:47:11 +0200 [thread overview]
Message-ID: <1c803be8060fb99b7d92e2f5cde3c0e1962fbe2b.1568224033.git.hns@goldelico.com> (raw)
In-Reply-To: <cover.1568224032.git.hns@goldelico.com>
In preparation for using the multi_regulator capability of
this driver for handling the ABB LDO for OPP1G of the omap36xx
we have to take care that the (legacy) vdd-supply name is
cpu0-supply = <&vcc>;
To do this we add another field to the SoC description table which
optionally can specify a list of regulator names.
For omap36xx we define "cpu0-supply" and "vbb-supply".
The default remains "vdd-supply" and "vbb-supply".
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 6 +++++-
drivers/cpufreq/ti-cpufreq.c | 12 ++++++++++--
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
index 0c38e4b8fc51..1758051798fe 100644
--- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -15,12 +15,16 @@ In 'cpus' nodes:
In 'operating-points-v2' table:
- compatible: Should be
- - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx SoCs
+ - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx,
+ omap34xx, omap36xx and am3517 SoCs
- syscon: A phandle pointing to a syscon node representing the control module
register space of the SoC.
Optional properties:
--------------------
+- "vdd-supply", "vbb-supply": to define two regulators for dra7xx
+- "cpu0-supply", "vbb-supply": to define two regulators for omap36xx
+
For each opp entry in 'operating-points-v2' table:
- opp-supported-hw: Two bitfields indicating:
1. Which revision of the SoC the OPP is supported by
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index f2f58d689320..1a3073a3093e 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -41,6 +41,7 @@
struct ti_cpufreq_data;
struct ti_cpufreq_soc_data {
+ const char * const *reg_names;
unsigned long (*efuse_xlate)(struct ti_cpufreq_data *opp_data,
unsigned long efuse);
unsigned long efuse_fallback;
@@ -164,7 +165,10 @@ static struct ti_cpufreq_soc_data omap34xx_soc_data = {
* seems to always read as 0).
*/
+static const char * const omap3_reg_names[] = {"cpu0", "vbb"};
+
static struct ti_cpufreq_soc_data omap36xx_soc_data = {
+ .reg_names = omap3_reg_names,
.efuse_xlate = omap3_efuse_xlate,
.efuse_offset = OMAP3_CONTROL_DEVICE_STATUS - OMAP3_SYSCON_BASE,
.efuse_shift = 9,
@@ -298,7 +302,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
const struct of_device_id *match;
struct opp_table *ti_opp_table;
struct ti_cpufreq_data *opp_data;
- const char * const reg_names[] = {"vdd", "vbb"};
+ const char * const default_reg_names[] = {"vdd", "vbb"};
int ret;
match = dev_get_platdata(&pdev->dev);
@@ -354,9 +358,13 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
opp_data->opp_table = ti_opp_table;
if (opp_data->soc_data->multi_regulator) {
+ const char * const *reg_names = default_reg_names;
+
+ if (opp_data->soc_data->reg_names)
+ reg_names = opp_data->soc_data->reg_names;
ti_opp_table = dev_pm_opp_set_regulators(opp_data->cpu_dev,
reg_names,
- ARRAY_SIZE(reg_names));
+ ARRAY_SIZE(default_reg_names));
if (IS_ERR(ti_opp_table)) {
dev_pm_opp_put_supported_hw(opp_data->opp_table);
ret = PTR_ERR(ti_opp_table);
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-09-11 17:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-11 17:47 [PATCH v3 0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits H. Nikolaus Schaller
2019-09-11 17:47 ` [PATCH v3 1/8] cpufreq: ti-cpufreq: add support for omap34xx and omap36xx H. Nikolaus Schaller
2019-09-11 19:05 ` Adam Ford
2019-09-11 17:47 ` [PATCH v3 2/8] ARM: dts: omap34xx & omap36xx: replace opp-v1 tables by opp-v2 for H. Nikolaus Schaller
2019-09-11 17:47 ` [PATCH v3 3/8] DTS: bindings: omap: update bindings documentation H. Nikolaus Schaller
2019-09-11 17:47 ` [PATCH v3 4/8] ARM: dts: omap3: bulk convert compatible to be explicitly ti, omap3430 or ti, omap3630 or ti, am3517 H. Nikolaus Schaller
2019-09-11 17:47 ` H. Nikolaus Schaller [this message]
2019-09-16 16:24 ` [PATCH v3 5/8] cpufreq: ti-cpufreq: omap36xx use "cpu0", "vbb" if run in multi_regulator mode Tony Lindgren
2019-09-17 19:22 ` Rob Herring
2019-09-11 17:47 ` [PATCH v3 6/8] ARM: dts: omap36xx: using OPP1G needs to control the abb_ldo H. Nikolaus Schaller
2019-09-13 21:13 ` Adam Ford
2019-09-14 9:30 ` H. Nikolaus Schaller
2019-09-16 16:25 ` Tony Lindgren
2019-09-11 17:47 ` [PATCH v3 7/8] cpufreq: ti-cpufreq: Add support for AM3517 H. Nikolaus Schaller
2019-09-16 16:26 ` Tony Lindgren
2019-09-11 17:47 ` [PATCH v3 8/8] ARM: dts: Add OPP-V2 table " H. Nikolaus Schaller
2019-09-16 16:26 ` Tony Lindgren
2019-09-16 16:28 ` [PATCH v3 0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits Tony Lindgren
2019-09-17 14:35 ` H. Nikolaus Schaller
2019-10-02 5:47 ` H. Nikolaus Schaller
2019-10-02 9:00 ` Viresh Kumar
2019-10-10 10:45 ` Viresh Kumar
2019-11-08 20:08 ` Adam Ford
2019-11-09 6:12 ` H. Nikolaus Schaller
2019-11-09 10:02 ` Adam Ford
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=1c803be8060fb99b7d92e2f5cde3c0e1962fbe2b.1568224033.git.hns@goldelico.com \
--to=hns@goldelico.com \
--cc=aford173@gmail.com \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=eballetbo@gmail.com \
--cc=javier@dowhile0.org \
--cc=kernel@pyra-handheld.com \
--cc=letux-kernel@openphoenux.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=neolynx@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=rogerq@ti.com \
--cc=t.remmet@phytec.de \
--cc=tony@atomide.com \
--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).