Date   

[ANNOUNCE] Release v4.19.128-cip28 and v4.4.227-cip46

Nobuhiro Iwamatsu
 

Hi,

CIP kernel team has released Linux kernel v4.19.128-cip28 and v4.4.227-cip46.
The linux-4.19.y-cip tree has been updated base version from v4.19.124
to v4.19.128, and The linux-4.4.y-cip tree has been updated base version from
v4.4.222 to v4.4.227.
In addition, the linux-4.4.y-cip tree added support for MoxaUC-8100-ME-T, LCD support
for iwg20d-q7, and PM/OOP functionality for TI ARM SoC am33xx,

You can get this release via the git tree at:

v4.19.128-cip28:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
775b010f64a43fe825f22c8784b6589ac4295956
added commits:
CIP: Bump version suffix to -cip28 after merge from stable

v4.4.227-cip46:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.4.y-cip
commit hash:
e65152cafde5d1f6db9b8e6e8a65fed2b19ea91d
added commits:
CIP: Bump version suffix to -cip46 after merge from stable
cpufreq: cpufreq-dt: avoid uninitialized variable warnings:
cpufreq-dt: fix handling regulator_get_voltage() result
cpufreq-dt: Supply power coefficient when registering cooling devices
devicetree: bindings: Add optional dynamic-power-coefficient property
PM / OPP: Use snprintf() instead of sprintf()
PM / OPP: Set cpu_dev->id in cpumask first
PM / OPP: Parse 'opp-<prop>-<name>' bindings
PM / OPP: Parse 'opp-supported-hw' binding
PM / OPP: Add missing doc comments
PM / OPP: Rename OPP nodes as opp@<opp-hz>
PM / OPP: Remove 'operating-points-names' binding
PM / OPP: Add {opp-microvolt|opp-microamp}-<name> binding
PM / OPP: Add "opp-supported-hw" binding
PM / OPP: Add debugfs support
ARM: dts: am335x: moxa-uc-8100-me-t: Replaced register offsets with defines
ARM: dts: am33xx: Added AM33XX_PADCONF macro
ARM: dts: am33xx: Added macros for numeric pinmux addresses
ARM: dts: am335x: add support for Moxa UC-8100-ME-T open platform
ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
ARM: dts: iwg20d-q7-common: Add LCD support

Best regards,
Nobuhiro
u


Re: CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi, Pavel-san,

I'll go through the IRC logs.
The log is the following.
https://irclogs.baserock.org/meetings/cip/2020/06/cip.2020-06-11-09.00.log.html

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Pavel Machek
Sent: Thursday, June 11, 2020 8:24 PM
To: cip-dev@...
Subject: Re: [cip-dev] CIP IRC weekly meeting today

Hi!


Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
I'm sorry I missed the meeting. I'll go through the IRC logs.

My activity last week: reviews on 4.19.127 and patches queued for 4.19.128.

Best regards,
Pavel


Re: CIP IRC weekly meeting today

Pavel Machek
 

Hi!


Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
I'm sorry I missed the meeting. I'll go through the IRC logs.

My activity last week: reviews on 4.19.127 and patches queued for 4.19.128.

Best regards,
Pavel


CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=6&day=11&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/06/cip.2020-06-04-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
3. Upload a guideline for reference hardware platform addition - masashi910
4. Post LTP results to KernelCI - patersonc
5. Ask board owners to review reference platform configs to optimize backporting - masashi910
6. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - iwamatsu

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Share your suggestions for supporting session lock requirement in CIP

Dinesh Kumar
 

Hi All,

 

IEC-62443-4-2 has following two requirements related to session termination and session lock.

CR2.5 Req-1 Session lock: Component should support session lock after a configurable time period of inactivity.

CR2.6 Req-2 Remote session termination: Component should support terminating remote session after a configurable time of inactivity

 

CR2.6 Req-2 can be met by adding system variable TMOUT.

 

For meeting CR2.5 we need following changes in CIP.

1.       Systemd code changes

2.       Add deamon which subscribes to dbus notification(sample code attached)

3.       Add vlock Debian package which performs session lock

4.       Enable dbus in systemd

 

Systemd code change are as follows.

 

--- a/src/login/logind.c
+++ b/src/login/logind.c
@@ -1019,7 +1019,7 @@ static int manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us
                     (m->idle_action_not_before_usec <= 0 || n >= m->idle_action_not_before_usec + m->idle_action_usec)) {
                         log_info("System idle. Taking action.");
 
-                        manager_handle_action(m, 0, m->idle_action, false, false);
+                        manager_handle_action(m, 0, m->idle_action, false, true);
                         m->idle_action_not_before_usec = n;
                 }

 

It means there are several changes required in CIP as well as it would be difficult to maintain for long term, if we chose this option.

 

My request is, if anyone has any better idea to achieve session lock, please share so we can evaluate it further.

 

Thanks & Regards,

Dinesh Kumar

 

.


Re: isar-cip-core and cip-kernel-config

Daniel Sangorrin <daniel.sangorrin@...>
 

Good to know Jan, thanks for the update.

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Jan Kiszka
Sent: Tuesday, June 9, 2020 7:01 PM
To: cip-dev <cip-dev@...>
Subject: [cip-dev] isar-cip-core and cip-kernel-config

Hi all,

a quick follow-up from our cip-core meeting today:

isar-cip-core is already able to pull configs from cip-kernel-config. It
does so for all machines where USE_CIP_KERNEL_CONFIG = "1", ie.
hihope-rzg2m, iwg20m and simatic-ipc227e. So we "only" need to check the
other targets and see how they can be migrated.

And we should remove the old defconfigs from isar-cip-core then (some
could already go).

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [PATCH 4.4.y-cip v3 00/14] PM / OPP v2 & cpufreq backports part 1

Pavel Machek
 

Hi!

This is v3 of the part 1 of MOXA's PM / OPP / cpufreq backport series.
Changes since v2:

- Squashed "PM / OPP: Fix parsing of opp-microvolt and opp-microamp
properties" into "PM / OPP: Parse 'opp-<prop>-<name>' bindings"

Changes since v1:

- Added missing SoB and upstream commit hash for "PM / OPP: Set
cpu_dev->id in cpumask first"
Thanks! I have applied the series, will run some basic tests and push
the results if they work okay.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.4.y-cip 0/3] ARM: dts: am335x: Replace numeric pinmux address with macro defines

Pavel Machek
 

Hi!

On the other hand, I don't see any obvious benefit. Whether we use hex
constants or symbolic constants affects readability, but has no effect on
functionality.

Do you have any patches on top of these that rely on symbolic constants in the
dts? Are there any changes in the generated .dtb?
What is the benefit of this series (besides cleanup)?
Thanks for your response!

If macros of numeric pinmux addresses is used, we don't need to see AM335X's Technical Reference Manual again and again to find out the meaning of each pinmux address, just check "am33xx.h". Besides, it helps us to configure module pin's for different device trees easily. For example of mii, If we want to configure module of mii pin, we check module in "am33xx.h" can pick register names we want to modify. It's hard to remember pin address number for the specific module to us.

If AM33XX_PADCONF is taken, we can make sure both of pin's direction and mux mode are actually set, and it helps us to debug.

We have many boards based on AM335x SoC. Some dts rely on symbolic constants and some dts are not. I think this patch series can let us develop boards with AM335x SoC easiler.
Aha, ok, having more boards like this certainly explains the
benefits. Thanks for an explanation.

I have applied patches, I'll run some basic tests and push the
results.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


isar-cip-core and cip-kernel-config

Jan Kiszka
 

Hi all,

a quick follow-up from our cip-core meeting today:

isar-cip-core is already able to pull configs from cip-kernel-config. It
does so for all machines where USE_CIP_KERNEL_CONFIG = "1", ie.
hihope-rzg2m, iwg20m and simatic-ipc227e. So we "only" need to check the
other targets and see how they can be migrated.

And we should remove the old defconfigs from isar-cip-core then (some
could already go).

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


[PATCH 4.4.y-cip v3 13/14] cpufreq-dt: fix handling regulator_get_voltage() result

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Andrzej Hajda <a.hajda@...>

commit 929ca89c305a6ed7a4149115be99af6d73c36918 upstream.

The function can return negative values so it should be assigned
to signed type.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci.

Link: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda <a.hajda@...>
Acked-by: Viresh Kumar <viresh.kumar@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
drivers/cpufreq/cpufreq-dt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 1ceece9d67112..9bc37c437874a 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -50,7 +50,8 @@ static int set_target(struct cpufreq_policy *policy, un=
signed int index)
struct private_data *priv =3D policy->driver_data;
struct device *cpu_dev =3D priv->cpu_dev;
struct regulator *cpu_reg =3D priv->cpu_reg;
- unsigned long volt =3D 0, volt_old =3D 0, tol =3D 0;
+ unsigned long volt =3D 0, tol =3D 0;
+ int volt_old =3D 0;
unsigned int old_freq, new_freq;
long freq_Hz, freq_exact;
int ret;
@@ -83,7 +84,7 @@ static int set_target(struct cpufreq_policy *policy, un=
signed int index)
opp_freq / 1000, volt);
}
=20
- dev_dbg(cpu_dev, "%u MHz, %ld mV --> %u MHz, %ld mV\n",
+ dev_dbg(cpu_dev, "%u MHz, %d mV --> %u MHz, %ld mV\n",
old_freq / 1000, (volt_old > 0) ? volt_old / 1000 : -1,
new_freq / 1000, volt ? volt / 1000 : -1);
=20
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 10/14] PM / OPP: Use snprintf() instead of sprintf()

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@...>

commit 5ff24d601092b222340b28466e263b1c4559407e upstream.

sprintf() can access memory outside of the range of the character array,
and is risky in some situations. The driver specified prop_name string
can be longer than NAME_MAX here (only an attacker will do that though)
and so blindly copying it into the character array of size NAME_MAX
isn't safe. Instead we must use snprintf() here.

Reported-by: Geert Uytterhoeven <geert@...>
Signed-off-by: Viresh Kumar <viresh.kumar@...>
Acked-by: Geert Uytterhoeven <geert+renesas@...>
Acked-by: Stephen Boyd <sboyd@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
drivers/base/power/opp/core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index 504a6d4e46723..1e0a2ddf73323 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -808,7 +808,8 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,=
struct device *dev,
=20
/* Search for "opp-microvolt-<name>" */
if (dev_opp->prop_name) {
- sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
+ snprintf(name, sizeof(name), "opp-microvolt-%s",
+ dev_opp->prop_name);
prop =3D of_find_property(opp->np, name, NULL);
}
=20
@@ -855,7 +856,8 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,=
struct device *dev,
/* Search for "opp-microamp-<name>" */
prop =3D NULL;
if (dev_opp->prop_name) {
- sprintf(name, "opp-microamp-%s", dev_opp->prop_name);
+ snprintf(name, sizeof(name), "opp-microamp-%s",
+ dev_opp->prop_name);
prop =3D of_find_property(opp->np, name, NULL);
}
=20
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 11/14] devicetree: bindings: Add optional dynamic-power-coefficient property

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Punit Agrawal <punit.agrawal@...>

commit 3be3f8f36e7349006f19c8c8f0d686e98462a993 upstream.

The dynamic power consumption of a device is proportional to the
square of voltage (V) and the clock frequency (f). It can be expressed as

Pdyn =3D dynamic-power-coefficient * V^2 * f.

The coefficient represents the running time dynamic power consumption in
units of mw/MHz/uVolt^2 and can be used in the above formula to
calculate the dynamic power in mW.

Signed-off-by: Punit Agrawal <punit.agrawal@...>
Acked-by: Rob Herring <robh@...>
Reviewed-by: Viresh Kumar <viresh.kumar@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
Documentation/devicetree/bindings/arm/cpus.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentati=
on/devicetree/bindings/arm/cpus.txt
index 9ef9a2089a5e7..6b1d8ebb94b7b 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -243,6 +243,23 @@ nodes to be present and contain the properties descr=
ibed below.
Definition: Specifies the syscon node controlling the cpu core
power domains.
=20
+ - dynamic-power-coefficient
+ Usage: optional
+ Value type: <prop-encoded-array>
+ Definition: A u32 value that represents the running time dynamic
+ power coefficient in units of mW/MHz/uVolt^2. The
+ coefficient can either be calculated from power
+ measurements or derived by analysis.
+
+ The dynamic power consumption of the CPU is
+ proportional to the square of the Voltage (V) and
+ the clock frequency (f). The coefficient is used to
+ calculate the dynamic power as below -
+
+ Pdyn =3D dynamic-power-coefficient * V^2 * f
+
+ where voltage is in uV, frequency is in MHz.
+
Example 1 (dual-cluster big.LITTLE system 32-bit):
=20
cpus {
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 14/14] cpufreq: cpufreq-dt: avoid uninitialized variable warnings:

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Arnd Bergmann <arnd@...>

commit b331bc20d9281213f7fb67912638e0fb5baeb324 upstream.

gcc warns quite a bit about values returned from allocate_resources()
in cpufreq-dt.c:

cpufreq-dt.c: In function 'cpufreq_init':
cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here
cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here
cpufreq-dt.c: In function 'dt_cpufreq_probe':
cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here

The problem is that it's slightly hard for gcc to follow return
codes across PTR_ERR() calls.

This patch uses explicit assignments to the "ret" variable to make
it easier for gcc to verify that the code is actually correct,
without the need to add a bogus initialization.

Signed-off-by: Arnd Bergmann <arnd@...>
Acked-by: Viresh Kumar <viresh.kumar@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
drivers/cpufreq/cpufreq-dt.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 9bc37c437874a..0ca74d0700583 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -142,15 +142,16 @@ static int allocate_resources(int cpu, struct devic=
e **cdev,
=20
try_again:
cpu_reg =3D regulator_get_optional(cpu_dev, reg);
- if (IS_ERR(cpu_reg)) {
+ ret =3D PTR_ERR_OR_ZERO(cpu_reg);
+ if (ret) {
/*
* If cpu's regulator supply node is present, but regulator is
* not yet registered, we should try defering probe.
*/
- if (PTR_ERR(cpu_reg) =3D=3D -EPROBE_DEFER) {
+ if (ret =3D=3D -EPROBE_DEFER) {
dev_dbg(cpu_dev, "cpu%d regulator not ready, retry\n",
cpu);
- return -EPROBE_DEFER;
+ return ret;
}
=20
/* Try with "cpu-supply" */
@@ -159,18 +160,16 @@ try_again:
goto try_again;
}
=20
- dev_dbg(cpu_dev, "no regulator for cpu%d: %ld\n",
- cpu, PTR_ERR(cpu_reg));
+ dev_dbg(cpu_dev, "no regulator for cpu%d: %d\n", cpu, ret);
}
=20
cpu_clk =3D clk_get(cpu_dev, NULL);
- if (IS_ERR(cpu_clk)) {
+ ret =3D PTR_ERR_OR_ZERO(cpu_clk);
+ if (ret) {
/* put regulator */
if (!IS_ERR(cpu_reg))
regulator_put(cpu_reg);
=20
- ret =3D PTR_ERR(cpu_clk);
-
/*
* If cpu's clk node is present, but clock is not yet
* registered, we should try defering probe.
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 12/14] cpufreq-dt: Supply power coefficient when registering cooling devices

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Punit Agrawal <punit.agrawal@...>

commit f8fa8ae06b8c2c25d81c99766f9226adc5c3e073 upstream.

Support registering cooling devices with dynamic power coefficient
where provided by the device tree. This allows OF registered cooling
devices driver to be used with the power_allocator thermal governor.

Signed-off-by: Punit Agrawal <punit.agrawal@...>
Acked-by: Viresh Kumar <viresh.kumar@...>
Reviewed-by: Javi Merino <javi.merino@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
drivers/cpufreq/cpufreq-dt.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 90d64081ddb34..1ceece9d67112 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -407,8 +407,13 @@ static void cpufreq_ready(struct cpufreq_policy *pol=
icy)
* thermal DT code takes care of matching them.
*/
if (of_find_property(np, "#cooling-cells", NULL)) {
- priv->cdev =3D of_cpufreq_cooling_register(np,
- policy->related_cpus);
+ u32 power_coefficient =3D 0;
+
+ of_property_read_u32(np, "dynamic-power-coefficient",
+ &power_coefficient);
+
+ priv->cdev =3D of_cpufreq_power_cooling_register(np,
+ policy->related_cpus, power_coefficient, NULL);
if (IS_ERR(priv->cdev)) {
dev_err(priv->cpu_dev,
"running cpufreq without cooling device: %ld\n",
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 09/14] PM / OPP: Set cpu_dev->id in cpumask first

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Pi-Cheng Chen <pi-cheng.chen@...>

commit d9de19b1cc013433ad293365b5b3902ec73dfd60 upstream.

Set cpu_dev->id in cpumask first when setting up cpumask for CPUs that
share the same OPP table. This might be helpful when handling cpumask
without the original CPU bitfield set.

Signed-off-by: Pi-Cheng Chen <pi-cheng.chen@...>
Acked-by: Viresh Kumar <viresh.kumar@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
drivers/base/power/opp/cpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c
index 1a2e8f260b060..a0db8b3575f38 100644
--- a/drivers/base/power/opp/cpu.c
+++ b/drivers/base/power/opp/cpu.c
@@ -218,7 +218,6 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_of_cpumask_add_table);
/*
* Works only for OPP v2 bindings.
*
- * cpumask should be already set to mask of cpu_dev->id.
* Returns -ENOENT if operating-points-v2 bindings aren't supported.
*/
int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t=
cpumask)
@@ -234,6 +233,8 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu=
_dev, cpumask_var_t cpumask
return -ENOENT;
}
=20
+ cpumask_set_cpu(cpu_dev->id, cpumask);
+
/* OPPs are shared ? */
if (!of_property_read_bool(np, "opp-shared"))
goto put_cpu_node;
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 08/14] PM / OPP: Parse 'opp-<prop>-<name>' bindings

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@...>

commit 01fb4d3c39d35b725441e8a9a26b3f3ad67793ed upstream.
commit fd8d8e63467c922be9ae4452cca2980d473477d9 upstream squashed in.

OPP bindings (for few properties) allow a platform to choose a
value/range among a set of available options. The options are present as
opp-<prop>-<name>, where the platform needs to supply the <name> string.

The OPP properties which allow such an option are: opp-microvolt and
opp-microamp.

Add support to the OPP-core to parse these bindings, by introducing
dev_pm_opp_{set|put}_prop_name() APIs.

Signed-off-by: Viresh Kumar <viresh.kumar@...>
Tested-by: Lee Jones <lee.jones@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
[wens: Squashed in Bartlomiej Zolnierkiewicz's <b.zolnierkie@...>
upstream commit fd8d8e63467c922be9ae4452cca2980d473477d9 to fix a =
bug]
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
drivers/base/power/opp/core.c | 165 ++++++++++++++++++++++++++++++----
drivers/base/power/opp/opp.h | 2 +
include/linux/pm_opp.h | 9 ++
3 files changed, 161 insertions(+), 15 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index a73433c3cbe45..504a6d4e46723 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -562,6 +562,9 @@ static void _remove_device_opp(struct device_opp *dev=
_opp)
if (dev_opp->supported_hw)
return;
=20
+ if (dev_opp->prop_name)
+ return;
+
list_dev =3D list_first_entry(&dev_opp->dev_list, struct device_list_op=
p,
node);
=20
@@ -794,35 +797,48 @@ unlock:
}
=20
/* TODO: Support multiple regulators */
-static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev=
)
+static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev=
,
+ struct device_opp *dev_opp)
{
u32 microvolt[3] =3D {0};
u32 val;
int count, ret;
+ struct property *prop =3D NULL;
+ char name[NAME_MAX];
+
+ /* Search for "opp-microvolt-<name>" */
+ if (dev_opp->prop_name) {
+ sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
+ prop =3D of_find_property(opp->np, name, NULL);
+ }
+
+ if (!prop) {
+ /* Search for "opp-microvolt" */
+ sprintf(name, "opp-microvolt");
+ prop =3D of_find_property(opp->np, name, NULL);
=20
- /* Missing property isn't a problem, but an invalid entry is */
- if (!of_find_property(opp->np, "opp-microvolt", NULL))
- return 0;
+ /* Missing property isn't a problem, but an invalid entry is */
+ if (!prop)
+ return 0;
+ }
=20
- count =3D of_property_count_u32_elems(opp->np, "opp-microvolt");
+ count =3D of_property_count_u32_elems(opp->np, name);
if (count < 0) {
- dev_err(dev, "%s: Invalid opp-microvolt property (%d)\n",
- __func__, count);
+ dev_err(dev, "%s: Invalid %s property (%d)\n",
+ __func__, name, count);
return count;
}
=20
/* There can be one or three elements here */
if (count !=3D 1 && count !=3D 3) {
- dev_err(dev, "%s: Invalid number of elements in opp-microvolt property=
(%d)\n",
- __func__, count);
+ dev_err(dev, "%s: Invalid number of elements in %s property (%d)\n",
+ __func__, name, count);
return -EINVAL;
}
=20
- ret =3D of_property_read_u32_array(opp->np, "opp-microvolt", microvolt,
- count);
+ ret =3D of_property_read_u32_array(opp->np, name, microvolt, count);
if (ret) {
- dev_err(dev, "%s: error parsing opp-microvolt: %d\n", __func__,
- ret);
+ dev_err(dev, "%s: error parsing %s: %d\n", __func__, name, ret);
return -EINVAL;
}
=20
@@ -836,7 +852,20 @@ static int opp_parse_supplies(struct dev_pm_opp *opp=
, struct device *dev)
opp->u_volt_max =3D microvolt[2];
}
=20
- if (!of_property_read_u32(opp->np, "opp-microamp", &val))
+ /* Search for "opp-microamp-<name>" */
+ prop =3D NULL;
+ if (dev_opp->prop_name) {
+ sprintf(name, "opp-microamp-%s", dev_opp->prop_name);
+ prop =3D of_find_property(opp->np, name, NULL);
+ }
+
+ if (!prop) {
+ /* Search for "opp-microamp" */
+ sprintf(name, "opp-microamp");
+ prop =3D of_find_property(opp->np, name, NULL);
+ }
+
+ if (prop && !of_property_read_u32(opp->np, name, &val))
opp->u_amp =3D val;
=20
return 0;
@@ -954,6 +983,112 @@ unlock:
}
EXPORT_SYMBOL_GPL(dev_pm_opp_put_supported_hw);
=20
+/**
+ * dev_pm_opp_set_prop_name() - Set prop-extn name
+ * @dev: Device for which the regulator has to be set.
+ * @name: name to postfix to properties.
+ *
+ * This is required only for the V2 bindings, and it enables a platform =
to
+ * specify the extn to be used for certain property names. The propertie=
s to
+ * which the extension will apply are opp-microvolt and opp-microamp. OP=
P core
+ * should postfix the property name with -<name> while looking for them.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+int dev_pm_opp_set_prop_name(struct device *dev, const char *name)
+{
+ struct device_opp *dev_opp;
+ int ret =3D 0;
+
+ /* Hold our list modification lock here */
+ mutex_lock(&dev_opp_list_lock);
+
+ dev_opp =3D _add_device_opp(dev);
+ if (!dev_opp) {
+ ret =3D -ENOMEM;
+ goto unlock;
+ }
+
+ /* Make sure there are no concurrent readers while updating dev_opp */
+ WARN_ON(!list_empty(&dev_opp->opp_list));
+
+ /* Do we already have a prop-name associated with dev_opp? */
+ if (dev_opp->prop_name) {
+ dev_err(dev, "%s: Already have prop-name %s\n", __func__,
+ dev_opp->prop_name);
+ ret =3D -EBUSY;
+ goto err;
+ }
+
+ dev_opp->prop_name =3D kstrdup(name, GFP_KERNEL);
+ if (!dev_opp->prop_name) {
+ ret =3D -ENOMEM;
+ goto err;
+ }
+
+ mutex_unlock(&dev_opp_list_lock);
+ return 0;
+
+err:
+ _remove_device_opp(dev_opp);
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_set_prop_name);
+
+/**
+ * dev_pm_opp_put_prop_name() - Releases resources blocked for prop-name
+ * @dev: Device for which the regulator has to be set.
+ *
+ * This is required only for the V2 bindings, and is called for a matchi=
ng
+ * dev_pm_opp_set_prop_name(). Until this is called, the device_opp stru=
cture
+ * will not be freed.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+void dev_pm_opp_put_prop_name(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ /* Hold our list modification lock here */
+ mutex_lock(&dev_opp_list_lock);
+
+ /* Check for existing list for 'dev' first */
+ dev_opp =3D _find_device_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ dev_err(dev, "Failed to find dev_opp: %ld\n", PTR_ERR(dev_opp));
+ goto unlock;
+ }
+
+ /* Make sure there are no concurrent readers while updating dev_opp */
+ WARN_ON(!list_empty(&dev_opp->opp_list));
+
+ if (!dev_opp->prop_name) {
+ dev_err(dev, "%s: Doesn't have a prop-name\n", __func__);
+ goto unlock;
+ }
+
+ kfree(dev_opp->prop_name);
+ dev_opp->prop_name =3D NULL;
+
+ /* Try freeing device_opp if this was the last blocking resource */
+ _remove_device_opp(dev_opp);
+
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_put_prop_name);
+
static bool _opp_is_supported(struct device *dev, struct device_opp *dev=
_opp,
struct device_node *np)
{
@@ -1048,7 +1183,7 @@ static int _opp_add_static_v2(struct device *dev, s=
truct device_node *np)
if (!of_property_read_u32(np, "clock-latency-ns", &val))
new_opp->clock_latency_ns =3D val;
=20
- ret =3D opp_parse_supplies(new_opp, dev);
+ ret =3D opp_parse_supplies(new_opp, dev, dev_opp);
if (ret)
goto free_opp;
=20
diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
index 70f4564a6ab9d..690638ef36ee5 100644
--- a/drivers/base/power/opp/opp.h
+++ b/drivers/base/power/opp/opp.h
@@ -131,6 +131,7 @@ struct device_list_opp {
* @suspend_opp: Pointer to OPP to be used during device suspend.
* @supported_hw: Array of version number to support.
* @supported_hw_count: Number of elements in supported_hw array.
+ * @prop_name: A name to postfix to many DT properties, while parsing th=
em.
* @dentry: debugfs dentry pointer of the real device directory (not lin=
ks).
* @dentry_name: Name of the real dentry.
*
@@ -157,6 +158,7 @@ struct device_opp {
=20
unsigned int *supported_hw;
unsigned int supported_hw_count;
+ const char *prop_name;
=20
#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 3a85110242f00..95403d2ccaf56 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -58,6 +58,8 @@ struct srcu_notifier_head *dev_pm_opp_get_notifier(stru=
ct device *dev);
int dev_pm_opp_set_supported_hw(struct device *dev, const u32 *versions,
unsigned int count);
void dev_pm_opp_put_supported_hw(struct device *dev);
+int dev_pm_opp_set_prop_name(struct device *dev, const char *name);
+void dev_pm_opp_put_prop_name(struct device *dev);
#else
static inline unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *op=
p)
{
@@ -142,6 +144,13 @@ static inline int dev_pm_opp_set_supported_hw(struct=
device *dev,
=20
static inline void dev_pm_opp_put_supported_hw(struct device *dev) {}
=20
+static inline int dev_pm_opp_set_prop_name(struct device *dev, const cha=
r *name)
+{
+ return -EINVAL;
+}
+
+static inline void dev_pm_opp_put_prop_name(struct device *dev) {}
+
#endif /* CONFIG_PM_OPP */
=20
#if defined(CONFIG_PM_OPP) && defined(CONFIG_OF)
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 07/14] PM / OPP: Parse 'opp-supported-hw' binding

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@...>

commit 7de36b0aa51a5a59e28fb2da768fa3ab07de0674 upstream.

OPP bindings allow a platform to enable OPPs based on the version of the
hardware they are used for.

Add support to the OPP-core to parse these bindings, by introducing
dev_pm_opp_{set|put}_supported_hw() APIs.

Signed-off-by: Viresh Kumar <viresh.kumar@...>
Tested-by: Lee Jones <lee.jones@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
drivers/base/power/opp/core.c | 148 ++++++++++++++++++++++++++++++++++
drivers/base/power/opp/opp.h | 5 ++
include/linux/pm_opp.h | 13 +++
3 files changed, 166 insertions(+)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index 22d91d9b1b037..a73433c3cbe45 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -559,6 +559,9 @@ static void _remove_device_opp(struct device_opp *dev=
_opp)
if (!list_empty(&dev_opp->opp_list))
return;
=20
+ if (dev_opp->supported_hw)
+ return;
+
list_dev =3D list_first_entry(&dev_opp->dev_list, struct device_list_op=
p,
node);
=20
@@ -839,6 +842,145 @@ static int opp_parse_supplies(struct dev_pm_opp *op=
p, struct device *dev)
return 0;
}
=20
+/**
+ * dev_pm_opp_set_supported_hw() - Set supported platforms
+ * @dev: Device for which supported-hw has to be set.
+ * @versions: Array of hierarchy of versions to match.
+ * @count: Number of elements in the array.
+ *
+ * This is required only for the V2 bindings, and it enables a platform =
to
+ * specify the hierarchy of versions it supports. OPP layer will then en=
able
+ * OPPs, which are available for those versions, based on its 'opp-suppo=
rted-hw'
+ * property.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+int dev_pm_opp_set_supported_hw(struct device *dev, const u32 *versions,
+ unsigned int count)
+{
+ struct device_opp *dev_opp;
+ int ret =3D 0;
+
+ /* Hold our list modification lock here */
+ mutex_lock(&dev_opp_list_lock);
+
+ dev_opp =3D _add_device_opp(dev);
+ if (!dev_opp) {
+ ret =3D -ENOMEM;
+ goto unlock;
+ }
+
+ /* Make sure there are no concurrent readers while updating dev_opp */
+ WARN_ON(!list_empty(&dev_opp->opp_list));
+
+ /* Do we already have a version hierarchy associated with dev_opp? */
+ if (dev_opp->supported_hw) {
+ dev_err(dev, "%s: Already have supported hardware list\n",
+ __func__);
+ ret =3D -EBUSY;
+ goto err;
+ }
+
+ dev_opp->supported_hw =3D kmemdup(versions, count * sizeof(*versions),
+ GFP_KERNEL);
+ if (!dev_opp->supported_hw) {
+ ret =3D -ENOMEM;
+ goto err;
+ }
+
+ dev_opp->supported_hw_count =3D count;
+ mutex_unlock(&dev_opp_list_lock);
+ return 0;
+
+err:
+ _remove_device_opp(dev_opp);
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_set_supported_hw);
+
+/**
+ * dev_pm_opp_put_supported_hw() - Releases resources blocked for suppor=
ted hw
+ * @dev: Device for which supported-hw has to be set.
+ *
+ * This is required only for the V2 bindings, and is called for a matchi=
ng
+ * dev_pm_opp_set_supported_hw(). Until this is called, the device_opp s=
tructure
+ * will not be freed.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+void dev_pm_opp_put_supported_hw(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ /* Hold our list modification lock here */
+ mutex_lock(&dev_opp_list_lock);
+
+ /* Check for existing list for 'dev' first */
+ dev_opp =3D _find_device_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ dev_err(dev, "Failed to find dev_opp: %ld\n", PTR_ERR(dev_opp));
+ goto unlock;
+ }
+
+ /* Make sure there are no concurrent readers while updating dev_opp */
+ WARN_ON(!list_empty(&dev_opp->opp_list));
+
+ if (!dev_opp->supported_hw) {
+ dev_err(dev, "%s: Doesn't have supported hardware list\n",
+ __func__);
+ goto unlock;
+ }
+
+ kfree(dev_opp->supported_hw);
+ dev_opp->supported_hw =3D NULL;
+ dev_opp->supported_hw_count =3D 0;
+
+ /* Try freeing device_opp if this was the last blocking resource */
+ _remove_device_opp(dev_opp);
+
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_put_supported_hw);
+
+static bool _opp_is_supported(struct device *dev, struct device_opp *dev=
_opp,
+ struct device_node *np)
+{
+ unsigned int count =3D dev_opp->supported_hw_count;
+ u32 version;
+ int ret;
+
+ if (!dev_opp->supported_hw)
+ return true;
+
+ while (count--) {
+ ret =3D of_property_read_u32_index(np, "opp-supported-hw", count,
+ &version);
+ if (ret) {
+ dev_warn(dev, "%s: failed to read opp-supported-hw property at index =
%d: %d\n",
+ __func__, count, ret);
+ return false;
+ }
+
+ /* Both of these are bitwise masks of the versions */
+ if (!(version & dev_opp->supported_hw[count]))
+ return false;
+ }
+
+ return true;
+}
+
/**
* _opp_add_static_v2() - Allocate static OPPs (As per 'v2' DT bindings)
* @dev: device for which we do this operation
@@ -885,6 +1027,12 @@ static int _opp_add_static_v2(struct device *dev, s=
truct device_node *np)
goto free_opp;
}
=20
+ /* Check if the OPP supports hardware's hierarchy of versions or not */
+ if (!_opp_is_supported(dev, dev_opp, np)) {
+ dev_dbg(dev, "OPP not supported by hardware: %llu\n", rate);
+ goto free_opp;
+ }
+
/*
* Rate is defined as an unsigned long in clk API, and so casting
* explicitly to its type. Must be fixed once rate is 64 bit
diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
index b8880c7f8be1c..70f4564a6ab9d 100644
--- a/drivers/base/power/opp/opp.h
+++ b/drivers/base/power/opp/opp.h
@@ -129,6 +129,8 @@ struct device_list_opp {
* @clock_latency_ns_max: Max clock latency in nanoseconds.
* @shared_opp: OPP is shared between multiple devices.
* @suspend_opp: Pointer to OPP to be used during device suspend.
+ * @supported_hw: Array of version number to support.
+ * @supported_hw_count: Number of elements in supported_hw array.
* @dentry: debugfs dentry pointer of the real device directory (not lin=
ks).
* @dentry_name: Name of the real dentry.
*
@@ -153,6 +155,9 @@ struct device_opp {
bool shared_opp;
struct dev_pm_opp *suspend_opp;
=20
+ unsigned int *supported_hw;
+ unsigned int supported_hw_count;
+
#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
char dentry_name[NAME_MAX];
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 9a2e50337af9f..3a85110242f00 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -55,6 +55,9 @@ int dev_pm_opp_enable(struct device *dev, unsigned long=
freq);
int dev_pm_opp_disable(struct device *dev, unsigned long freq);
=20
struct srcu_notifier_head *dev_pm_opp_get_notifier(struct device *dev);
+int dev_pm_opp_set_supported_hw(struct device *dev, const u32 *versions,
+ unsigned int count);
+void dev_pm_opp_put_supported_hw(struct device *dev);
#else
static inline unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *op=
p)
{
@@ -129,6 +132,16 @@ static inline struct srcu_notifier_head *dev_pm_opp_=
get_notifier(
{
return ERR_PTR(-EINVAL);
}
+
+static inline int dev_pm_opp_set_supported_hw(struct device *dev,
+ const u32 *versions,
+ unsigned int count)
+{
+ return -EINVAL;
+}
+
+static inline void dev_pm_opp_put_supported_hw(struct device *dev) {}
+
#endif /* CONFIG_PM_OPP */
=20
#if defined(CONFIG_PM_OPP) && defined(CONFIG_OF)
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 06/14] PM / OPP: Add missing doc comments

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@...>

commit dc4e7b1fa20a840d2317fcfdaa1064fc09d2afcb upstream.

Few doc-style comments were missing, add them. Rearrange another one to
match the sequence within the structure.

Signed-off-by: Viresh Kumar <viresh.kumar@...>
Acked-by: Pavel Machek <pavel@...>
Reviewed-by: Stephen Boyd <sboyd@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
drivers/base/power/opp/opp.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
index a6bd8d2c2b47f..b8880c7f8be1c 100644
--- a/drivers/base/power/opp/opp.h
+++ b/drivers/base/power/opp/opp.h
@@ -51,8 +51,8 @@ extern struct mutex dev_opp_list_lock;
* are protected by the dev_opp_list_lock for integrity.
* IMPORTANT: the opp nodes should be maintained in increasing
* order.
- * @dynamic: not-created from static DT entries.
* @available: true/false - marks if this OPP as available or not
+ * @dynamic: not-created from static DT entries.
* @turbo: true if turbo (boost) OPP
* @suspend: true if suspend OPP
* @rate: Frequency in hertz
@@ -126,7 +126,9 @@ struct device_list_opp {
* @dev_list: list of devices that share these OPPs
* @opp_list: list of opps
* @np: struct device_node pointer for opp's DT node.
+ * @clock_latency_ns_max: Max clock latency in nanoseconds.
* @shared_opp: OPP is shared between multiple devices.
+ * @suspend_opp: Pointer to OPP to be used during device suspend.
* @dentry: debugfs dentry pointer of the real device directory (not lin=
ks).
* @dentry_name: Name of the real dentry.
*
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 05/14] PM / OPP: Rename OPP nodes as opp@<opp-hz>

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@...>

commit 754dcf35f34698661801ae1d391efa02affe83a7 upstream.

It would be better to name OPP nodes as opp@<opp-hz> as that will ensure
that multiple DT nodes don't contain the same frequency. Of course we
expect the writer to name the node with its opp-hz frequency and not any
other frequency.

And that will let the compile error out if multiple nodes are using the
same opp-hz frequency.

Suggested-by: Stephen Boyd <sboyd@...>
Reviewed-by: Stephen Boyd <sboyd@...>
Acked-by: Rob Herring <robh@...>
Signed-off-by: Viresh Kumar <viresh.kumar@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
Documentation/devicetree/bindings/opp/opp.txt | 38 +++++++++----------
1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentatio=
n/devicetree/bindings/opp/opp.txt
index 24eac9a977494..601256fe8c0dd 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -177,20 +177,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, =
switch DVFS states together.
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>;
opp-microamp =3D <70000>;
clock-latency-ns =3D <300000>;
opp-suspend;
};
- opp01 {
+ opp@1100000000 {
opp-hz =3D /bits/ 64 <1100000000>;
opp-microvolt =3D <980000 1000000 1010000>;
opp-microamp =3D <80000>;
clock-latency-ns =3D <310000>;
};
- opp02 {
+ opp@1200000000 {
opp-hz =3D /bits/ 64 <1200000000>;
opp-microvolt =3D <1025000>;
clock-latency-ns =3D <290000>;
@@ -256,20 +256,20 @@ independently.
* independently.
*/
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>;
opp-microamp =3D <70000>;
clock-latency-ns =3D <300000>;
opp-suspend;
};
- opp01 {
+ opp@1100000000 {
opp-hz =3D /bits/ 64 <1100000000>;
opp-microvolt =3D <980000 1000000 1010000>;
opp-microamp =3D <80000>;
clock-latency-ns =3D <310000>;
};
- opp02 {
+ opp@1200000000 {
opp-hz =3D /bits/ 64 <1200000000>;
opp-microvolt =3D <1025000>;
opp-microamp =3D <90000;
@@ -332,20 +332,20 @@ DVFS state together.
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>;
opp-microamp =3D <70000>;
clock-latency-ns =3D <300000>;
opp-suspend;
};
- opp01 {
+ opp@1100000000 {
opp-hz =3D /bits/ 64 <1100000000>;
opp-microvolt =3D <980000 1000000 1010000>;
opp-microamp =3D <80000>;
clock-latency-ns =3D <310000>;
};
- opp02 {
+ opp@1200000000 {
opp-hz =3D /bits/ 64 <1200000000>;
opp-microvolt =3D <1025000>;
opp-microamp =3D <90000>;
@@ -358,20 +358,20 @@ DVFS state together.
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp10 {
+ opp@1300000000 {
opp-hz =3D /bits/ 64 <1300000000>;
opp-microvolt =3D <1045000 1050000 1055000>;
opp-microamp =3D <95000>;
clock-latency-ns =3D <400000>;
opp-suspend;
};
- opp11 {
+ opp@1400000000 {
opp-hz =3D /bits/ 64 <1400000000>;
opp-microvolt =3D <1075000>;
opp-microamp =3D <100000>;
clock-latency-ns =3D <400000>;
};
- opp12 {
+ opp@1500000000 {
opp-hz =3D /bits/ 64 <1500000000>;
opp-microvolt =3D <1010000 1100000 1110000>;
opp-microamp =3D <95000>;
@@ -398,7 +398,7 @@ Example 4: Handling multiple regulators
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
@@ -411,7 +411,7 @@ Example 4: Handling multiple regulators
=20
/* OR */
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>, /* Supply 0 */
<960000 965000 975000>, /* Supply 1 */
@@ -424,7 +424,7 @@ Example 4: Handling multiple regulators
=20
/* OR */
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>, /* Supply 0 */
<960000 965000 975000>, /* Supply 1 */
@@ -456,7 +456,7 @@ Example 5: opp-supported-hw
status =3D "okay";
opp-shared;
=20
- opp00 {
+ opp@600000000 {
/*
* Supports all substrate and process versions for 0xF
* cuts, i.e. only first four cuts.
@@ -467,7 +467,7 @@ Example 5: opp-supported-hw
...
};
=20
- opp01 {
+ opp@800000000 {
/*
* Supports:
* - cuts: only one, 6th cut (represented by 6th bit).
@@ -499,7 +499,7 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt-slow =3D <900000 915000 925000>;
opp-microvolt-fast =3D <970000 975000 985000>;
@@ -507,7 +507,7 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
opp-microamp-fast =3D <71000>;
};
=20
- opp01 {
+ opp@1200000000 {
opp-hz =3D /bits/ 64 <1200000000>;
opp-microvolt-slow =3D <900000 915000 925000>, /* Supply vcc0 */
<910000 925000 935000>; /* Supply vcc1 */
--=20
2.27.0.rc0


[PATCH 4.4.y-cip v3 02/14] PM / OPP: Add "opp-supported-hw" binding

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@...>

commit 1c4d12de2719dfdf27c6dab31e7a5641ee293c94 upstream.

We may want to enable only a subset of OPPs, from the bigger list of
OPPs, based on what version of the hardware we are running on. This
would enable us to not duplicate OPP tables for every version of the
hardware we support.

To enable that, this patch defines a new property 'opp-supported-hw'. It
can support any number of hierarchy levels of the versions the hardware
follows. And based on the selected hardware versions, we can pick only
the relevant OPPs at runtime.

Reviewed-by: Stephen Boyd <sboyd@...>
Acked-by: Rob Herring <robh@...>
Signed-off-by: Viresh Kumar <viresh.kumar@...>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@...>
---
Documentation/devicetree/bindings/opp/opp.txt | 65 +++++++++++++++++++
1 file changed, 65 insertions(+)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentatio=
n/devicetree/bindings/opp/opp.txt
index 0cb44dc21f97c..d072fa0ffbd44 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -123,6 +123,26 @@ Optional properties:
- opp-suspend: Marks the OPP to be used during device suspend. Only one =
OPP in
the table should have this.
=20
+- opp-supported-hw: This enables us to select only a subset of OPPs from=
the
+ larger OPP table, based on what version of the hardware we are running=
on. We
+ still can't have multiple nodes with the same opp-hz value in OPP tabl=
e.
+
+ It's an user defined array containing a hierarchy of hardware version =
numbers,
+ supported by the OPP. For example: a platform with hierarchy of three =
levels
+ of versions (A, B and C), this field should be like <X Y Z>, where X
+ corresponds to Version hierarchy A, Y corresponds to version hierarchy=
B and Z
+ corresponds to version hierarchy C.
+
+ Each level of hierarchy is represented by a 32 bit value, and so there=
can be
+ only 32 different supported version per hierarchy. i.e. 1 bit per vers=
ion. A
+ value of 0xFFFFFFFF will enable the OPP for all versions for that hier=
archy
+ level. And a value of 0x00000000 will disable the OPP completely, and =
so we
+ never want that to happen.
+
+ If 32 values aren't sufficient for a version hierarchy, than that vers=
ion
+ hierarchy can be contained in multiple 32 bit values. i.e. <X Y Z1 Z2>=
in the
+ above example, Z1 & Z2 refer to the version hierarchy Z.
+
- status: Marks the node enabled/disabled.
=20
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states to=
gether.
@@ -463,3 +483,48 @@ Example 5: Multiple OPP tables
};
};
};
+
+Example 6: opp-supported-hw
+(example: three level hierarchy of versions: cuts, substrate and process=
)
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible =3D "arm,cortex-a7";
+ ...
+
+ cpu-supply =3D <&cpu_supply>
+ operating-points-v2 =3D <&cpu0_opp_table_slow>;
+ };
+ };
+
+ opp_table {
+ compatible =3D "operating-points-v2";
+ status =3D "okay";
+ opp-shared;
+
+ opp00 {
+ /*
+ * Supports all substrate and process versions for 0xF
+ * cuts, i.e. only first four cuts.
+ */
+ opp-supported-hw =3D <0xF 0xFFFFFFFF 0xFFFFFFFF>
+ opp-hz =3D /bits/ 64 <600000000>;
+ opp-microvolt =3D <900000 915000 925000>;
+ ...
+ };
+
+ opp01 {
+ /*
+ * Supports:
+ * - cuts: only one, 6th cut (represented by 6th bit).
+ * - substrate: supports 16 different substrate versions
+ * - process: supports 9 different process versions
+ */
+ opp-supported-hw =3D <0x20 0xff0000ff 0x0000f4f0>
+ opp-hz =3D /bits/ 64 <800000000>;
+ opp-microvolt =3D <900000 915000 925000>;
+ ...
+ };
+ };
+};
--=20
2.27.0.rc0

3801 - 3820 of 8596