* [PATCH V2 4/4] arm64: dts: imx8mm: Add opp-suspend property to OPP table
From: Anson.Huang @ 2019-07-09 8:00 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh+dt, mark.rutland, shawnguo, s.hauer,
kernel, festevam, leonard.crestez, p.zabel, ping.bai,
daniel.baluta, l.stach, abel.vesa, angus, andrew.smirnov, ccaione,
agx, linux-pm, devicetree, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <20190709080015.43442-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
Add opp-suspend property to each OPP, the of opp core will
select the OPP HW supported and with highest rate to be
suspend opp, it will speed up the suspend/resume process.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 398318b..973f457 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -108,6 +108,7 @@
opp-microvolt = <850000>;
opp-supported-hw = <0xe>, <0x7>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1600000000 {
@@ -115,6 +116,7 @@
opp-microvolt = <900000>;
opp-supported-hw = <0xc>, <0x7>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1800000000 {
@@ -122,6 +124,7 @@
opp-microvolt = <1000000>;
opp-supported-hw = <0x8>, <0x3>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH V2 1/4] dt-bindings: opp: Support multiple opp-suspend properties
From: Anson.Huang @ 2019-07-09 8:00 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh+dt, mark.rutland, shawnguo, s.hauer,
kernel, festevam, leonard.crestez, p.zabel, ping.bai,
daniel.baluta, l.stach, abel.vesa, angus, andrew.smirnov, ccaione,
agx, linux-pm, devicetree, linux-kernel, linux-arm-kernel
Cc: Linux-imx
From: Anson Huang <Anson.Huang@nxp.com>
Update opp-suspend property's description to support multiple
opp-suspend properties defined in DT, the OPP with highest opp-hz
and with opp-suspend property present will be used as suspend opp.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
New patch.
---
Documentation/devicetree/bindings/opp/opp.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 76b6c79..6859227 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -140,8 +140,8 @@ Optional properties:
frequency for a short duration of time limited by the device's power, current
and thermal limits.
-- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
- the table should have this.
+- opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
+ in the table have this, the OPP with highest opp-hz will be used.
- 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
--
2.7.4
^ permalink raw reply related
* [PATCH v5] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()
From: Wen Yang @ 2019-07-09 8:04 UTC (permalink / raw)
To: linux-kernel
Cc: xue.zhihong, wang.yi59, cheng.shengyu, Wen Yang,
Rafael J. Wysocki, Viresh Kumar, Michael Ellerman, linuxppc-dev,
linux-pm
The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.
Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
v5: put together the code to get, use, and release cpu device_node.
v4: restore the blank line.
v3: fix a leaked reference.
v2: clean up the code according to the advice of viresh.
drivers/cpufreq/pasemi-cpufreq.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 6b1e4ab..1f0beb7 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -131,10 +131,17 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
int err = -ENODEV;
cpu = of_get_cpu_node(policy->cpu, NULL);
-
- of_node_put(cpu);
if (!cpu)
goto out;
+ max_freqp = of_get_property(cpu, "clock-frequency", NULL);
+ of_node_put(cpu);
+ if (!max_freqp) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ /* we need the freq in kHz */
+ max_freq = *max_freqp / 1000;
dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
if (!dn)
@@ -171,16 +178,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
}
pr_debug("init cpufreq on CPU %d\n", policy->cpu);
-
- max_freqp = of_get_property(cpu, "clock-frequency", NULL);
- if (!max_freqp) {
- err = -EINVAL;
- goto out_unmap_sdcpwr;
- }
-
- /* we need the freq in kHz */
- max_freq = *max_freqp / 1000;
-
pr_debug("max clock-frequency is at %u kHz\n", max_freq);
pr_debug("initializing frequency table\n");
--
2.9.5
^ permalink raw reply related
* RE: [PATCH 1/3] opp: of: Support multiple suspend OPPs defined in DT
From: Anson Huang @ 2019-07-09 7:54 UTC (permalink / raw)
To: Viresh Kumar
Cc: robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
vireshk@kernel.org, nm@ti.com, sboyd@kernel.org, Leonard Crestez,
Aisheng Dong, Daniel Baluta, Jacky Bai, l.stach@pengutronix.de,
Abel Vesa, ccaione@baylibre.com, angus@akkea.ca,
andrew.smirnov@gmail.com, agx@sigxcpu.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
dl-linux-imx
In-Reply-To: <20190709075119.rg6ktsg7nwdadsmd@vireshk-i7>
Hi, Viresh
> On 09-07-19, 15:10, Anson.Huang@nxp.com wrote:
> > From: Anson Huang <Anson.Huang@nxp.com>
> >
> > With property "opp-supported-hw" introduced, the OPP table in DT could
> > be a large OPP table and ONLY a subset of OPPs are available, based on
> > the version of the hardware running on. That introduces restriction of
> > using "opp-suspend"
> > property to define the suspend OPP, as we are NOT sure if the OPP
> > containing "opp-suspend" property is available for the hardware
> > running on, and the of opp core does NOT allow multiple suspend OPPs
> > defined in DT OPP table.
> >
> > To eliminate this restrition, make of opp core allow multiple suspend
> > OPPs defined in DT, and pick the OPP with highest rate and with
> > "opp-suspend" property present to be suspend OPP, it can speed up the
> > suspend/resume process.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > drivers/opp/of.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
>
> Please update the DT bindings first.
OK, will send a V2 containing DT binding changes.
>
> FWIW, all three patches look fine otherwise.
Thank you!
Anson.
^ permalink raw reply
* Re: [PATCH 1/3] opp: of: Support multiple suspend OPPs defined in DT
From: Viresh Kumar @ 2019-07-09 7:51 UTC (permalink / raw)
To: Anson.Huang
Cc: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
vireshk, nm, sboyd, leonard.crestez, aisheng.dong, daniel.baluta,
ping.bai, l.stach, abel.vesa, ccaione, angus, andrew.smirnov, agx,
devicetree, linux-arm-kernel, linux-kernel, linux-pm, Linux-imx
In-Reply-To: <20190709071056.26361-1-Anson.Huang@nxp.com>
On 09-07-19, 15:10, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> With property "opp-supported-hw" introduced, the OPP table
> in DT could be a large OPP table and ONLY a subset of OPPs
> are available, based on the version of the hardware running
> on. That introduces restriction of using "opp-suspend"
> property to define the suspend OPP, as we are NOT sure if the
> OPP containing "opp-suspend" property is available for the
> hardware running on, and the of opp core does NOT allow multiple
> suspend OPPs defined in DT OPP table.
>
> To eliminate this restrition, make of opp core allow multiple
> suspend OPPs defined in DT, and pick the OPP with highest rate
> and with "opp-suspend" property present to be suspend OPP, it
> can speed up the suspend/resume process.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> drivers/opp/of.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
Please update the DT bindings first.
FWIW, all three patches look fine otherwise.
--
viresh
^ permalink raw reply
* Re: [PATCH v4 1/1] power: supply: Add HWMON compatibility layer
From: Andrey Smirnov @ 2019-07-09 7:27 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Linux PM list, Guenter Roeck, Chris Healy, Cory Tusar,
Lucas Stach, Fabio Estevam, linux-kernel
In-Reply-To: <20190627182725.v3mgmy35fxoogofe@earth.universe>
On Thu, Jun 27, 2019 at 11:27 AM Sebastian Reichel <sre@kernel.org> wrote:
>
> Hi,
>
> On Wed, Jun 12, 2019 at 01:44:04AM -0700, Andrey Smirnov wrote:
> > Add code implementing HWMON adapter/compatibility layer to allow
> > expositing various sensors present on power supply devices via HWMON
> > subsystem. This is done in order to allow userspace to use single
> > ABI/library(libsensors) to access/manipulate all of the sensors of the
> > system.
> >
> > Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> > Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> > Tested-by: Chris Healy <cphealy@gmail.com>
> > ---
>
> Thanks, queued.
>
Hmm, I just realized that power supply exposing POWER_SUPPLY_PROP_TEMP
will have a thermal zone created for it by default, which will expose
said reading via thermal/HWMON integration layer. Do we want to do
anything about this duplication of functionality? Maybe hide it here
if desc->no_thermal is true? Or just drop reporting temperature from
this patch?
Thanks,
Andrey Smirnov
^ permalink raw reply
* Re: cpufreq notifiers break suspend -- Re: suspend broken in next-20190704 on Thinkpad X60
From: Viresh Kumar @ 2019-07-09 7:26 UTC (permalink / raw)
To: Pavel Machek
Cc: Rafael J. Wysocki, Matthias Kaehlcke, Ulf Hansson,
Rafael J. Wysocki, Linux-pm mailing list, kernel list,
Stephen Rothwell
In-Reply-To: <20190708141302.GA7436@amd>
On 08-07-19, 16:13, Pavel Machek wrote:
> On Mon 2019-07-08 14:58:40, Viresh Kumar wrote:
> > Though it makes me wonder why I didn't hit this thing. I was using the
> > cpu_cooling device the other day, which calls cpufreq_update_policy()
> > very frequently on heat-up. And I had a hair dryer blowing over my
> > board to heat it up. Lemme check that again :)
>
> Can you test on some x86 ACPI? No dryers needed :-).
>
Found out why I didn't hit it then. I tested it after converting
cpu_cooling driver to use QoS APIs and there is no double locking with
that.
--
viresh
^ permalink raw reply
* Re: [PATCH v3 6/6] interconnect: Add OPP table support for interconnects
From: Vincent Guittot @ 2019-07-09 7:25 UTC (permalink / raw)
To: Saravana Kannan
Cc: Georgi Djakov, Rob Herring, Mark Rutland, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki, Sweeney, Sean,
daidavid1, Rajendra Nayak, sibis, Bjorn Andersson, Evan Green,
Android Kernel Team, open list:THERMAL,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel
In-Reply-To: <CAGETcx912kpi9DejPCoWMUF5AMm4=o1C0C45zwMfUy6aX_jcYg@mail.gmail.com>
On Sun, 7 Jul 2019 at 23:48, Saravana Kannan <saravanak@google.com> wrote:
>
> On Thu, Jul 4, 2019 at 12:12 AM Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
> >
> > On Wed, 3 Jul 2019 at 23:33, Saravana Kannan <saravanak@google.com> wrote:
> > >
> > > On Tue, Jul 2, 2019 at 11:45 PM Vincent Guittot
> > > <vincent.guittot@linaro.org> wrote:
> > > >
> > > > On Wed, 3 Jul 2019 at 03:10, Saravana Kannan <saravanak@google.com> wrote:
> > > > >
> > > > > Interconnect paths can have different performance points. Now that OPP
> > > > > framework supports bandwidth OPP tables, add OPP table support for
> > > > > interconnects.
> > > > >
> > > > > Devices can use the interconnect-opp-table DT property to specify OPP
> > > > > tables for interconnect paths. And the driver can obtain the OPP table for
> > > > > an interconnect path by calling icc_get_opp_table().
> > > >
> > > > The opp table of a path must come from the aggregation of OPP tables
> > > > of the interconnect providers.
> > >
> > > The aggregation of OPP tables of the providers is certainly the
> > > superset of what a path can achieve, but to say that OPPs for
> > > interconnect path should match that superset is an oversimplification
> > > of the reality in hardware.
> > >
> > > There are lots of reasons an interconnect path might not want to use
> > > all the available bandwidth options across all the interconnects in
> > > the route.
> > >
> > > 1. That particular path might not have been validated or verified
> > > during the HW design process for some of the frequencies/bandwidth
> > > combinations of the providers.
> >
> > All these constraint are provider's constraints and not consumer's one
> >
> > The consumer asks for a bandwidth according to its needs and then the
> > providers select the optimal bandwidth of each interconnect after
> > aggregating all the request and according to what OPP have been
> > validated
>
> Not really. The screening can be a consumer specific issue. The
> consumer IP itself might have some issue with using too low of a
> bandwidth or bandwidth that's not within some range. It should not be
How can an IP ask for not enough bandwidth ?
It asks the needed bandwidth based on its requirements
> the provider's job to take into account all the IP that might be
> connected to the interconnects. If the interconnect HW itself didn't
That's not what I'm saying. The provider knows which bandwidth the
interconnect can provide as it is the ones which configures it. So if
the interconnect has a finite number of bandwidth point based probably
on the possible clock frequency and others config of the interconnect,
it selects the best final config after aggregating the request of the
consumer.
> change, the provider driver shouldn't need to change. By your
> definition, a provider driver will have to account for all the
> possible bus masters that might be connected to it across all SoCs.
you didn't catch my point
> That's not good design nor is it scalable.
>
> > >
> > > 2. Similarly during parts screening in the factory, some of the
> > > combinations might not have been screened and can't be guaranteed
> > > to work.
> >
> > As above, it's the provider's job to select the final bandwidth
> > according to its constraint
>
> Same reply as above.
>
> > >
> > > 3. Only a certain set of bandwidth levels might make sense to use from
> > > a power/performance balance given the device using it. For example:
> > > - The big CPU might not want to use some of the lower bandwidths
> > > but the little CPU might want to.
> > > - The big CPU might not want to use some intermediate bandwidth
> > > points if they don't save a lot of power compared to a higher
> > > bandwidth levels, but the little CPU might want to.
> > > - The little CPU might never want to use the higher set of
> > > bandwidth levels since they won't be power efficient for the use
> > > cases that might run on it.
> >
> > These example are quite vague about the reasons why little might never
> > want to use higher bandwidth.
>
> How is it vague? I just said because of power/performance balance.
>
> > But then, if little doesn't ask high bandwidth it will not use them.
>
> If you are running a heuristics based algorithm to pick bandwidth,
> this is how it'll know NOT to use some of the bandwidth levels.
so you want to set a bandwidth according to the cpu frequency which is
what has been proposed in other thread
>
> > >
> > > 4. It might not make sense from a system level power perspective.
> > > Let's take an example of a path S (source) -> A -> B -> C -> D
> > > (destination).
> > > - A supports only 2, 5, 7 and 10 GB/s. B supports 1, 2 ... 10 GB/s.
> > > C supports 5 and 10 GB/s
> > > - If you combine and list the superset of bandwidth levels
> > > supported in that path, that'd be 1, 2, 3, ... 10 GB/s.
> > > - Which set of bandwidth levels make sense will depend on the
> > > hardware characteristics of the interconnects.
> > > - If B is the biggest power sink, then you might want to use all 10
> > > levels.
> > > - If A is the biggest power sink, then you might want to use all 2,
> > > 5 and 10 GB/s of the levels.
> > > - If C is the biggest power sink then you might only want to use 5
> > > and 10 GB/s
> > > - The more hops and paths you get the more convoluted this gets.
> > >
> > > 5. The design of the interconnects themselves might have an impact on
> > > which bandwidth levels are used.
> > > - For example, the FIFO depth between two specific interconnects
> > > might affect the valid bandwidth levels for a specific path.
> > > - Say S1 -> A -> B -> D1, S2 -> C -> B -> D1 and S2 -> C -> D2 are
> > > three paths.
> > > - If C <-> B FIFO depth is small, then there might be a requirement
> > > that C and B be closely performance matched to avoid system level
> > > congestion due to back pressure.
> > > - So S2 -> D1 path can't use all the bandwidth levels supported by
> > > C-B combination.
> > > - But S2 -> D2 can use all the bandwidth levels supported by C.
> > > - And S1 -> D1 can use all the levels supported by A-B combination.
> > >
> >
> > All the examples above makes sense but have to be handle by the
> > provider not the consumer. The consumer asks for a bandwidth according
> > to its constraints. Then the provider which is the driver that manages
> > the interconnect IP, should manage all this hardware and platform
> > specific stuff related to the interconnect IP in order to set the
> > optimal bandwidth that fit both consumer constraint and platform
> > specific configuration.
>
> Sure, but the provider itself can have interconnect properties to
> indicate which other interconnects it's tied to. And the provider will
> still need the interconnect-opp-table to denote which bandwidth levels
> are sensible to use with each of its connections.
>
> So in some instances the interconnect-opp-table covers the needs of
> purely consumers and in some instances purely providers. But in either
> case, it's still needed to describe the hardware properly.
>
> -Saravana
>
> > > These are just some of the reasons I could recollect in a few minutes.
> > > These are all real world cases I had to deal with in the past several
> > > years of dealing with scaling interconnects. I'm sure vendors and SoCs
> > > I'm not familiar with have other good reasons I'm not aware of.
> > >
> > > Trying to figure this all out by aggregating OPP tables of
> > > interconnect providers just isn't feasible nor is it efficient. The
> > > OPP tables for an interconnect path is describing the valid BW levels
> > > supported by that path and verified in hardware and makes a lot of
> > > sense to capture it clearly in DT.
> > >
> > > > So such kind of OPP table should be at
> > > > provider level but not at path level.
> > >
> > > They can also use it if they want to, but they'll probably want to use
> > > a frequency OPP table.
> > >
> > >
> > > -Saravana
> > >
> > > >
> > > > >
> > > > > Signed-off-by: Saravana Kannan <saravanak@google.com>
> > > > > ---
> > > > > drivers/interconnect/core.c | 27 ++++++++++++++++++++++++++-
> > > > > include/linux/interconnect.h | 7 +++++++
> > > > > 2 files changed, 33 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> > > > > index 871eb4bc4efc..881bac80bc1e 100644
> > > > > --- a/drivers/interconnect/core.c
> > > > > +++ b/drivers/interconnect/core.c
> > > > > @@ -47,6 +47,7 @@ struct icc_req {
> > > > > */
> > > > > struct icc_path {
> > > > > size_t num_nodes;
> > > > > + struct opp_table *opp_table;
> > > > > struct icc_req reqs[];
> > > > > };
> > > > >
> > > > > @@ -313,7 +314,7 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
> > > > > {
> > > > > struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
> > > > > struct icc_node *src_node, *dst_node;
> > > > > - struct device_node *np = NULL;
> > > > > + struct device_node *np = NULL, *opp_node;
> > > > > struct of_phandle_args src_args, dst_args;
> > > > > int idx = 0;
> > > > > int ret;
> > > > > @@ -381,10 +382,34 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
> > > > > dev_err(dev, "%s: invalid path=%ld\n", __func__, PTR_ERR(path));
> > > > > mutex_unlock(&icc_lock);
> > > > >
> > > > > + opp_node = of_parse_phandle(np, "interconnect-opp-table", idx);
> > > > > + if (opp_node) {
> > > > > + path->opp_table = dev_pm_opp_of_find_table_from_node(opp_node);
> > > > > + of_node_put(opp_node);
> > > > > + }
> > > > > +
> > > > > +
> > > > > return path;
> > > > > }
> > > > > EXPORT_SYMBOL_GPL(of_icc_get);
> > > > >
> > > > > +/**
> > > > > + * icc_get_opp_table() - Get the OPP table that corresponds to a path
> > > > > + * @path: reference to the path returned by icc_get()
> > > > > + *
> > > > > + * This function will return the OPP table that corresponds to a path handle.
> > > > > + * If the interconnect API is disabled, NULL is returned and the consumer
> > > > > + * drivers will still build. Drivers are free to handle this specifically, but
> > > > > + * they don't have to.
> > > > > + *
> > > > > + * Return: opp_table pointer on success. NULL is returned when the API is
> > > > > + * disabled or the OPP table is missing.
> > > > > + */
> > > > > +struct opp_table *icc_get_opp_table(struct icc_path *path)
> > > > > +{
> > > > > + return path->opp_table;
> > > > > +}
> > > > > +
> > > > > /**
> > > > > * icc_set_bw() - set bandwidth constraints on an interconnect path
> > > > > * @path: reference to the path returned by icc_get()
> > > > > diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
> > > > > index dc25864755ba..0c0bc55f0e89 100644
> > > > > --- a/include/linux/interconnect.h
> > > > > +++ b/include/linux/interconnect.h
> > > > > @@ -9,6 +9,7 @@
> > > > >
> > > > > #include <linux/mutex.h>
> > > > > #include <linux/types.h>
> > > > > +#include <linux/pm_opp.h>
> > > > >
> > > > > /* macros for converting to icc units */
> > > > > #define Bps_to_icc(x) ((x) / 1000)
> > > > > @@ -28,6 +29,7 @@ struct device;
> > > > > struct icc_path *icc_get(struct device *dev, const int src_id,
> > > > > const int dst_id);
> > > > > struct icc_path *of_icc_get(struct device *dev, const char *name);
> > > > > +struct opp_table *icc_get_opp_table(struct icc_path *path);
> > > > > void icc_put(struct icc_path *path);
> > > > > int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
> > > > >
> > > > > @@ -49,6 +51,11 @@ static inline void icc_put(struct icc_path *path)
> > > > > {
> > > > > }
> > > > >
> > > > > +static inline struct opp_table *icc_get_opp_table(struct icc_path *path)
> > > > > +{
> > > > > + return NULL;
> > > > > +}
> > > > > +
> > > > > static inline int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
> > > > > {
> > > > > return 0;
> > > > > --
> > > > > 2.22.0.410.gd8fdbe21b5-goog
> > > > >
> >
> > --
> > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
> >
^ permalink raw reply
* RE: [PATCH] cpufreq: imx-cpufreq-dt: Assign max supported frequency as suspend frequency
From: Anson Huang @ 2019-07-09 7:24 UTC (permalink / raw)
To: Leonard Crestez, viresh.kumar@linaro.org
Cc: rjw@rjwysocki.net, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx, Lucas Stach
In-Reply-To: <AM6PR0402MB3911ED00DB7CCD6866DB8AE2F5F10@AM6PR0402MB3911.eurprd04.prod.outlook.com>
> > On 7/8/2019 10:55 AM, Anson.Huang@nxp.com wrote:
> > > To reduce the suspend/resume latency, CPU's max supported frequency
> > > should be used during low level suspend/resume phase, "opp-suspend"
> > > property is NOT feasible since OPP defined in DT could be NOT
> > > supported according to speed garding and market segment fuse settings.
> > > So we can assign the cpufreq policy's suspend_freq with max
> > > available frequency provided by cpufreq driver.
> > >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> >
> > > diff --git a/drivers/cpufreq/imx-cpufreq-dt.c
> > > b/drivers/cpufreq/imx-cpufreq-dt.c
> >
> > > +static int __init imx_cpufreq_dt_setup_suspend_opp(void)
> > > +{
> > > + struct cpufreq_policy *policy = cpufreq_cpu_get(0);
> > > +
> > > + policy->suspend_freq = cpufreq_quick_get_max(0);
> > > +
> > > + return 0;
> > > +}
> > > +late_initcall(imx_cpufreq_dt_setup_suspend_opp);
> >
> > The imx-cpufreq-dt driver is built as a module by default and this
> > patch produces an error:
> >
> > In file included from ../drivers/cpufreq/imx-cpufreq-dt.c:11:
> > ../include/linux/module.h:131:42: error: redefinition of ‘__inittest’
> > static inline initcall_t __maybe_unused __inittest(void) \
> > ^~~~~~~~~~
> > ../include/linux/device.h:1656:1: note: in expansion of macro ‘module_init’
> > module_init(__driver##_init); \
> > ^~~~~~~~~~~
> >
> > As far as I can tell late_initcall is not supported for modules.
>
> Ah, yes, I have NOT test the module build, I ONLY tested the built-in case,
> thanks for reminder.
>
> >
> > Viresh: "max freq as suspend freq" is something that could be useful
> > for other SOC families. The hardware can suspend at any freq; it's
> > just that the highest one makes sense because it makes suspend/resume
> slightly faster.
>
> Agree.
>
> >
> > Could this behavior be pushed to cpufreq-dt as a bool flag inside
> > struct cpufreq_dt_platform_data?
> >
> > Only a few other platforms use this, most others pass NULL like imx.
> > But passing custom SOC-specific flags to cpufreq-dt makes a lot of
> > sense
>
> Although we have other methods to make it work for i.MX platforms, like
> setting the suspend freq as this patch did but ONLY be called before suspend,
> but if common cpufreq-dt can handle this case, that would benefit us and
> other platforms a lot, waiting for your opinion.
Please ignore this patch, based on the discussion, I have sent out a new patch
series to support this feature. Please review them:
https://patchwork.kernel.org/patch/11036505/
Thanks,
Anson
^ permalink raw reply
* [PATCH 1/3] opp: of: Support multiple suspend OPPs defined in DT
From: Anson.Huang @ 2019-07-09 7:10 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
vireshk, nm, sboyd, leonard.crestez, aisheng.dong, daniel.baluta,
ping.bai, l.stach, abel.vesa, ccaione, angus, andrew.smirnov, agx,
devicetree, linux-arm-kernel, linux-kernel, linux-pm
Cc: Linux-imx
From: Anson Huang <Anson.Huang@nxp.com>
With property "opp-supported-hw" introduced, the OPP table
in DT could be a large OPP table and ONLY a subset of OPPs
are available, based on the version of the hardware running
on. That introduces restriction of using "opp-suspend"
property to define the suspend OPP, as we are NOT sure if the
OPP containing "opp-suspend" property is available for the
hardware running on, and the of opp core does NOT allow multiple
suspend OPPs defined in DT OPP table.
To eliminate this restrition, make of opp core allow multiple
suspend OPPs defined in DT, and pick the OPP with highest rate
and with "opp-suspend" property present to be suspend OPP, it
can speed up the suspend/resume process.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/opp/of.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index b313aca..7e8ec6c 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -617,9 +617,12 @@ static struct dev_pm_opp *_opp_add_static_v2(struct opp_table *opp_table,
/* OPP to select on device suspend */
if (of_property_read_bool(np, "opp-suspend")) {
if (opp_table->suspend_opp) {
- dev_warn(dev, "%s: Multiple suspend OPPs found (%lu %lu)\n",
- __func__, opp_table->suspend_opp->rate,
- new_opp->rate);
+ /* Pick the OPP with higher rate as suspend OPP */
+ if (new_opp->rate > opp_table->suspend_opp->rate) {
+ opp_table->suspend_opp->suspend = false;
+ new_opp->suspend = true;
+ opp_table->suspend_opp = new_opp;
+ }
} else {
new_opp->suspend = true;
opp_table->suspend_opp = new_opp;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: imx8mq: Add opp-suspend property to OPP table
From: Anson.Huang @ 2019-07-09 7:10 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
vireshk, nm, sboyd, leonard.crestez, aisheng.dong, daniel.baluta,
ping.bai, l.stach, abel.vesa, ccaione, angus, andrew.smirnov, agx,
devicetree, linux-arm-kernel, linux-kernel, linux-pm
Cc: Linux-imx
In-Reply-To: <20190709071056.26361-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
Add opp-suspend property to each OPP, the of opp core will
select the OPP HW supported and with highest rate to be
suspend opp, it will speed up the suspend/resume process.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 58f66cb..4ba6a25f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -156,6 +156,7 @@
/* Industrial only */
opp-supported-hw = <0xf>, <0x4>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1000000000 {
@@ -164,6 +165,7 @@
/* Consumer only */
opp-supported-hw = <0xe>, <0x3>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1300000000 {
@@ -171,6 +173,7 @@
opp-microvolt = <1000000>;
opp-supported-hw = <0xc>, <0x4>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1500000000 {
@@ -178,6 +181,7 @@
opp-microvolt = <1000000>;
opp-supported-hw = <0x8>, <0x3>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: imx8mm: Add opp-suspend property to OPP table
From: Anson.Huang @ 2019-07-09 7:10 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
vireshk, nm, sboyd, leonard.crestez, aisheng.dong, daniel.baluta,
ping.bai, l.stach, abel.vesa, ccaione, angus, andrew.smirnov, agx,
devicetree, linux-arm-kernel, linux-kernel, linux-pm
Cc: Linux-imx
In-Reply-To: <20190709071056.26361-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
Add opp-suspend property to each OPP, the of opp core will
select the OPP HW supported and with highest rate to be
suspend opp, it will speed up the suspend/resume process.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 398318b..973f457 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -108,6 +108,7 @@
opp-microvolt = <850000>;
opp-supported-hw = <0xe>, <0x7>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1600000000 {
@@ -115,6 +116,7 @@
opp-microvolt = <900000>;
opp-supported-hw = <0xc>, <0x7>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1800000000 {
@@ -122,6 +124,7 @@
opp-microvolt = <1000000>;
opp-supported-hw = <0x8>, <0x3>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
};
--
2.7.4
^ permalink raw reply related
* RE: Re: [PATCH] devfreq: tegra20: add COMMON_CLK dependency
From: MyungJoo Ham @ 2019-07-09 6:08 UTC (permalink / raw)
To: Chanwoo Choi, Arnd Bergmann, Kyungmin Park
Cc: Dmitry Osipenko, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <87564032-015a-323f-6d15-0abc67f6cc60@samsung.com>
On 19. 6. 28. 오후 7:32, Arnd Bergmann wrote:
> Compile-testing the new driver on platforms without CONFIG_COMMON_CLK
> leads to a link error:
>
> drivers/devfreq/tegra20-devfreq.o: In function `tegra_devfreq_target':
> tegra20-devfreq.c:(.text+0x288): undefined reference to `clk_set_min_rate'
>
> Add a dependency on COMMON_CLK to avoid this.
>
> Fixes: 1d39ee8dad6d ("PM / devfreq: Introduce driver for NVIDIA Tegra20")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/devfreq/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index f3b242987fd9..defe1d438710 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -107,6 +107,7 @@ config ARM_TEGRA_DEVFREQ
> config ARM_TEGRA20_DEVFREQ
> tristate "NVIDIA Tegra20 DEVFREQ Driver"
> depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST
> + depends on COMMON_CLK
> select DEVFREQ_GOV_SIMPLE_ONDEMAND
> select PM_OPP
> help
>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Thanks!
Cheers,
MyungJoo.
^ permalink raw reply
* Re: [PATCH v1 6/6] cpuidle: tegra: Remove CPUIDLE_FLAG_TIMER_STOP from all states
From: Dmitry Osipenko @ 2019-07-09 5:49 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, Peter De Schrijver,
Rafael J. Wysocki, Daniel Lezcano
Cc: linux-pm, linux-tegra, linux-kernel
In-Reply-To: <20190707233809.14400-7-digetx@gmail.com>
08.07.2019 2:38, Dmitry Osipenko пишет:
> The Tegra's clocksource driver got some rework recently and now the
> internal/local CPU timers usage is discouraged on Tegra20/30 SoCs in
> a favor of the platform-specific timers that are assigned as per-CPU
> clocksources because they do not suffer from the CPU-freq changes and
> are always-ON during of CPU-idling. That happened in the commit
> f6d50ec5f85c ("clocksource/drivers/tegra: Support per-CPU timers on all
> Tegra's"). The Tegra's clocksource driver is the essential arch-driver
> that is guaranteed to always present on all Tegra SoCs up to Tegra124.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
> drivers/cpuidle/cpuidle-tegra.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle-tegra.c b/drivers/cpuidle/cpuidle-tegra.c
> index 464b2376905a..e2aa46231c05 100644
> --- a/drivers/cpuidle/cpuidle-tegra.c
> +++ b/drivers/cpuidle/cpuidle-tegra.c
> @@ -143,7 +143,6 @@ static struct cpuidle_driver tegra_idle_driver = {
> .exit_latency = 2000,
> .target_residency = 2200,
> .power_usage = 0,
> - .flags = CPUIDLE_FLAG_TIMER_STOP,
> .name = "powered-down",
> .desc = "CPU core powered-off",
> },
> @@ -152,8 +151,7 @@ static struct cpuidle_driver tegra_idle_driver = {
> .exit_latency = 5000,
> .target_residency = 10000,
> .power_usage = 0,
> - .flags = CPUIDLE_FLAG_COUPLED |
> - CPUIDLE_FLAG_TIMER_STOP,
> + .flags = CPUIDLE_FLAG_COUPLED,
> .name = "powered-down",
> .desc = "CPU cluster powered-off",
> },
>
Actually, it should be fine to keep this flag because I found that
tick_broadcast_oneshot_control() checks for the C3STOP flag and thus
CPUIDLE_FLAG_TIMER_STOP has no effect in that case. Will drop this patch in the next revision.
^ permalink raw reply
* Re: [PATCH 03/14] power: supply: sc27xx: Introduce local variable 'struct device *dev'
From: Baolin Wang @ 2019-07-09 5:44 UTC (permalink / raw)
To: Fuqian Huang; +Cc: Sebastian Reichel, Linux PM list, LKML
In-Reply-To: <20190708123251.11759-1-huangfq.daxian@gmail.com>
On Mon, 8 Jul 2019 at 20:33, Fuqian Huang <huangfq.daxian@gmail.com> wrote:
>
> Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatly.
>
> Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
Looks good to me. Thanks.
Reviewed-by: Baolin Wang <baolin.wang@linaro.org>
> ---
> drivers/power/supply/sc27xx_fuel_gauge.c | 47 ++++++++++++++++----------------
> 1 file changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c b/drivers/power/supply/sc27xx_fuel_gauge.c
> index 24895cc3b41e..9c184d80088b 100644
> --- a/drivers/power/supply/sc27xx_fuel_gauge.c
> +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
> @@ -957,81 +957,82 @@ static int sc27xx_fgu_hw_init(struct sc27xx_fgu_data *data)
>
> static int sc27xx_fgu_probe(struct platform_device *pdev)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> struct power_supply_config fgu_cfg = { };
> struct sc27xx_fgu_data *data;
> int ret, irq;
>
> - data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> if (!data)
> return -ENOMEM;
>
> - data->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> + data->regmap = dev_get_regmap(dev->parent, NULL);
> if (!data->regmap) {
> - dev_err(&pdev->dev, "failed to get regmap\n");
> + dev_err(dev, "failed to get regmap\n");
> return -ENODEV;
> }
>
> - ret = device_property_read_u32(&pdev->dev, "reg", &data->base);
> + ret = device_property_read_u32(dev, "reg", &data->base);
> if (ret) {
> - dev_err(&pdev->dev, "failed to get fgu address\n");
> + dev_err(dev, "failed to get fgu address\n");
> return ret;
> }
>
> - data->channel = devm_iio_channel_get(&pdev->dev, "bat-temp");
> + data->channel = devm_iio_channel_get(dev, "bat-temp");
> if (IS_ERR(data->channel)) {
> - dev_err(&pdev->dev, "failed to get IIO channel\n");
> + dev_err(dev, "failed to get IIO channel\n");
> return PTR_ERR(data->channel);
> }
>
> - data->charge_chan = devm_iio_channel_get(&pdev->dev, "charge-vol");
> + data->charge_chan = devm_iio_channel_get(dev, "charge-vol");
> if (IS_ERR(data->charge_chan)) {
> - dev_err(&pdev->dev, "failed to get charge IIO channel\n");
> + dev_err(dev, "failed to get charge IIO channel\n");
> return PTR_ERR(data->charge_chan);
> }
>
> - data->gpiod = devm_gpiod_get(&pdev->dev, "bat-detect", GPIOD_IN);
> + data->gpiod = devm_gpiod_get(dev, "bat-detect", GPIOD_IN);
> if (IS_ERR(data->gpiod)) {
> - dev_err(&pdev->dev, "failed to get battery detection GPIO\n");
> + dev_err(dev, "failed to get battery detection GPIO\n");
> return PTR_ERR(data->gpiod);
> }
>
> ret = gpiod_get_value_cansleep(data->gpiod);
> if (ret < 0) {
> - dev_err(&pdev->dev, "failed to get gpio state\n");
> + dev_err(dev, "failed to get gpio state\n");
> return ret;
> }
>
> data->bat_present = !!ret;
> mutex_init(&data->lock);
> - data->dev = &pdev->dev;
> + data->dev = dev;
> platform_set_drvdata(pdev, data);
>
> fgu_cfg.drv_data = data;
> fgu_cfg.of_node = np;
> - data->battery = devm_power_supply_register(&pdev->dev, &sc27xx_fgu_desc,
> + data->battery = devm_power_supply_register(dev, &sc27xx_fgu_desc,
> &fgu_cfg);
> if (IS_ERR(data->battery)) {
> - dev_err(&pdev->dev, "failed to register power supply\n");
> + dev_err(dev, "failed to register power supply\n");
> return PTR_ERR(data->battery);
> }
>
> ret = sc27xx_fgu_hw_init(data);
> if (ret) {
> - dev_err(&pdev->dev, "failed to initialize fgu hardware\n");
> + dev_err(dev, "failed to initialize fgu hardware\n");
> return ret;
> }
>
> - ret = devm_add_action(&pdev->dev, sc27xx_fgu_disable, data);
> + ret = devm_add_action(dev, sc27xx_fgu_disable, data);
> if (ret) {
> sc27xx_fgu_disable(data);
> - dev_err(&pdev->dev, "failed to add fgu disable action\n");
> + dev_err(dev, "failed to add fgu disable action\n");
> return ret;
> }
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> - dev_err(&pdev->dev, "no irq resource specified\n");
> + dev_err(dev, "no irq resource specified\n");
> return irq;
> }
>
> @@ -1046,17 +1047,17 @@ static int sc27xx_fgu_probe(struct platform_device *pdev)
>
> irq = gpiod_to_irq(data->gpiod);
> if (irq < 0) {
> - dev_err(&pdev->dev, "failed to translate GPIO to IRQ\n");
> + dev_err(dev, "failed to translate GPIO to IRQ\n");
> return irq;
> }
>
> - ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
> + ret = devm_request_threaded_irq(dev, irq, NULL,
> sc27xx_fgu_bat_detection,
> IRQF_ONESHOT | IRQF_TRIGGER_RISING |
> IRQF_TRIGGER_FALLING,
> pdev->name, data);
> if (ret) {
> - dev_err(&pdev->dev, "failed to request IRQ\n");
> + dev_err(dev, "failed to request IRQ\n");
> return ret;
> }
>
> --
> 2.11.0
>
--
Baolin Wang
Best Regards
^ permalink raw reply
* Re: [PATCH 04/14] power: supply: sc27xx: Replace devm_add_action() followed by failure action with devm_add_action_or_reset()
From: Baolin Wang @ 2019-07-09 5:44 UTC (permalink / raw)
To: Fuqian Huang; +Cc: Sebastian Reichel, Linux PM list, LKML
In-Reply-To: <20190708123259.11805-1-huangfq.daxian@gmail.com>
Hi Fuqian,
On Mon, 8 Jul 2019 at 20:33, Fuqian Huang <huangfq.daxian@gmail.com> wrote:
>
> devm_add_action_or_reset() is introduced as a helper function which
> internally calls devm_add_action(). If devm_add_action() fails
> then it will execute the action mentioned and return the error code.
> This reduce source code size (avoid writing the action twice)
> and reduce the likelyhood of bugs.
>
> Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
Looks good to me. Thanks.
Reviewed-by: Baolin Wang <baolin.wang@linaro.org>
> ---
> drivers/power/supply/sc27xx_fuel_gauge.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c b/drivers/power/supply/sc27xx_fuel_gauge.c
> index 9c184d80088b..58b2970cd359 100644
> --- a/drivers/power/supply/sc27xx_fuel_gauge.c
> +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
> @@ -1023,9 +1023,8 @@ static int sc27xx_fgu_probe(struct platform_device *pdev)
> return ret;
> }
>
> - ret = devm_add_action(dev, sc27xx_fgu_disable, data);
> + ret = devm_add_action_or_reset(dev, sc27xx_fgu_disable, data);
> if (ret) {
> - sc27xx_fgu_disable(data);
> dev_err(dev, "failed to add fgu disable action\n");
> return ret;
> }
> --
> 2.11.0
>
--
Baolin Wang
Best Regards
^ permalink raw reply
* Re: [PATCH 1/3] opp: core: add regulators enable and disable
From: Viresh Kumar @ 2019-07-09 5:40 UTC (permalink / raw)
To: k.konieczny
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Chanwoo Choi,
Krzysztof Kozlowski, Kukjin Kim, Kyungmin Park, Mark Rutland,
MyungJoo Ham, Nishanth Menon, Rob Herring, Stephen Boyd,
Viresh Kumar, devicetree, linux-arm-kernel, linux-kernel,
linux-pm, linux-samsung-soc
In-Reply-To: <20190708141140.24379-2-k.konieczny@partner.samsung.com>
On 08-07-19, 16:11, k.konieczny@partner.samsung.com wrote:
> From: Kamil Konieczny <k.konieczny@partner.samsung.com>
>
> Add enable regulators to dev_pm_opp_set_regulators() and disable
> regulators to dev_pm_opp_put_regulators(). This prepares for
> converting exynos-bus devfreq driver to use dev_pm_opp_set_rate().
>
> Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com>
> ---
> drivers/opp/core.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 0e7703fe733f..947cac452854 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -1580,8 +1580,19 @@ struct opp_table *dev_pm_opp_set_regulators(struct device *dev,
> if (ret)
> goto free_regulators;
>
> + for (i = 0; i < opp_table->regulator_count; i++) {
> + ret = regulator_enable(opp_table->regulators[i]);
> + if (ret < 0)
> + goto disable;
> + }
I am wondering on why is this really required as this isn't done for
any other platform, probably because the regulators are enabled by
bootloader and are always on.
--
viresh
^ permalink raw reply
* Re: [PATCH v3 1/3] cpuidle-powernv : forced wakeup for stop states
From: Abhishek @ 2019-07-09 5:32 UTC (permalink / raw)
To: Nicholas Piggin, linux-kernel, linux-pm, linuxppc-dev
Cc: daniel.lezcano, dja, ego, mpe, rjw
In-Reply-To: <1562493994.wseoth6w1s.astroid@bobo.none>
Hi Nick,
Will post next version with the changes you have suggested.
There is a comment below.
On 07/07/2019 03:43 PM, Nicholas Piggin wrote:
> Abhishek Goel's on July 4, 2019 7:18 pm:
>> Currently, the cpuidle governors determine what idle state a idling CPU
>> should enter into based on heuristics that depend on the idle history on
>> that CPU. Given that no predictive heuristic is perfect, there are cases
>> where the governor predicts a shallow idle state, hoping that the CPU will
>> be busy soon. However, if no new workload is scheduled on that CPU in the
>> near future, the CPU may end up in the shallow state.
>>
>> This is problematic, when the predicted state in the aforementioned
>> scenario is a shallow stop state on a tickless system. As we might get
>> stuck into shallow states for hours, in absence of ticks or interrupts.
>>
>> To address this, We forcefully wakeup the cpu by setting the
>> decrementer. The decrementer is set to a value that corresponds with the
>> residency of the next available state. Thus firing up a timer that will
>> forcefully wakeup the cpu. Few such iterations will essentially train the
>> governor to select a deeper state for that cpu, as the timer here
>> corresponds to the next available cpuidle state residency. Thus, cpu will
>> eventually end up in the deepest possible state.
>>
>> Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
>> ---
>>
>> Auto-promotion
>> v1 : started as auto promotion logic for cpuidle states in generic
>> driver
>> v2 : Removed timeout_needed and rebased the code to upstream kernel
>> Forced-wakeup
>> v1 : New patch with name of forced wakeup started
>> v2 : Extending the forced wakeup logic for all states. Setting the
>> decrementer instead of queuing up a hrtimer to implement the logic.
>> v3 : Cleanly handle setting/resetting of decrementer so as to not break
>> irq work
>>
>> arch/powerpc/include/asm/time.h | 2 ++
>> arch/powerpc/kernel/time.c | 40 +++++++++++++++++++++++++++++++
>> drivers/cpuidle/cpuidle-powernv.c | 32 +++++++++++++++++++++++++
>> 3 files changed, 74 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
>> index 54f4ec1f9..a3bd4f3c0 100644
>> --- a/arch/powerpc/include/asm/time.h
>> +++ b/arch/powerpc/include/asm/time.h
>> @@ -188,6 +188,8 @@ static inline unsigned long tb_ticks_since(unsigned long tstamp)
>> extern u64 mulhdu(u64, u64);
>> #endif
>>
>> +extern int set_dec_before_idle(u64 timeout);
>> +extern void reset_dec_after_idle(void);
>> extern void div128_by_32(u64 dividend_high, u64 dividend_low,
>> unsigned divisor, struct div_result *dr);
>>
>> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>> index 694522308..814de3469 100644
>> --- a/arch/powerpc/kernel/time.c
>> +++ b/arch/powerpc/kernel/time.c
>> @@ -576,6 +576,46 @@ void arch_irq_work_raise(void)
>>
>> #endif /* CONFIG_IRQ_WORK */
>>
>> +/*
>> + * Returns 1 if we have reprogrammed the decrementer for idle.
>> + * Returns 0 if the decrementer is unchanged.
>> + */
>> +int set_dec_before_idle(u64 timeout)
>> +{
>> + u64 *next_tb = this_cpu_ptr(&decrementers_next_tb);
>> + u64 now = get_tb_or_rtc();
>> +
>> + /*
>> + * Ensure that the timeout is at least one microsecond
>> + * before the current decrement value. Else, we will
>> + * unnecesarily wakeup again within a microsecond.
>> + */
>> + if (now + timeout + 512 > *next_tb)
> I would pass this 512 in as a parameter and put the comment in the
> idle code. Timer code does not know/care.
>
> Maybe return bool and call it try_set_dec_before_idle.
>> + return 0;
>> +
>> + set_dec(timeout);
> This needs to have
>
> if (test_irq_work_pending())
> set_dec(1);
>
> here AFAIKS
>
>> +
>> + return 1;
>> +}
>> +
>> +void reset_dec_after_idle(void)
>> +{
>> + u64 now;
>> + u64 *next_tb;
>> +
>> + if (test_irq_work_pending())
>> + return;
>> +
>> + now = get_tb_or_rtc();
>> + next_tb = this_cpu_ptr(&decrementers_next_tb);
>> + if (now >= *next_tb)
>> + return;
> Are you sure it's okay to escape early in this case?
Yeah, It looks safe. In power9_idle_type, we call irq_set_pending_from_srr1
which sets the irq_happened. If reason is IRQ_DEC, in __check_irq_replay,
decrementer_check_overflow will be called which will set dec to a positive
valid value.
Also, we typically disable MSR EE before entering stop. And if a decrementer
wakes us up, before we enable EE, check for pending interrupt will be done.
And we finally reset dec to a positive value before we set EE=1.
> Thanks,
> Nick
>
Thanks,
Abhishek
^ permalink raw reply
* Re: [PATCH v3] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()
From: Michael Ellerman @ 2019-07-09 4:47 UTC (permalink / raw)
To: Wen Yang, linux-kernel
Cc: xue.zhihong, wang.yi59, cheng.shengyu, Wen Yang,
Rafael J. Wysocki, Viresh Kumar, linuxppc-dev, linux-pm
In-Reply-To: <1562575726-17438-1-git-send-email-wen.yang99@zte.com.cn>
Wen Yang <wen.yang99@zte.com.cn> writes:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> v3: fix a leaked reference.
> v2: clean up the code according to the advice of viresh.
>
> drivers/cpufreq/pasemi-cpufreq.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
> index 6b1e4ab..9dc5163 100644
> --- a/drivers/cpufreq/pasemi-cpufreq.c
> +++ b/drivers/cpufreq/pasemi-cpufreq.c
> @@ -128,20 +128,20 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
> int cur_astate, idx;
> struct resource res;
> struct device_node *cpu, *dn;
> - int err = -ENODEV;
> + int err;
>
> cpu = of_get_cpu_node(policy->cpu, NULL);
> -
> - of_node_put(cpu);
> if (!cpu)
> - goto out;
> + return -ENODEV;
I don't think introducing another exit path is an improvement.
> dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
> if (!dn)
> dn = of_find_compatible_node(NULL, NULL,
> "pasemi,pwrficient-sdc");
> - if (!dn)
> + if (!dn) {
> + err = -ENODEV;
> goto out;
> + }
> err = of_address_to_resource(dn, 0, &res);
> of_node_put(dn);
> if (err)
> @@ -196,6 +196,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
> policy->cur = pas_freqs[cur_astate].frequency;
> ppc_proc_freq = policy->cur * 1000ul;
>
> + of_node_put(cpu);
> return cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
>
> out_unmap_sdcpwr:
> @@ -204,6 +205,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
> out_unmap_sdcasr:
> iounmap(sdcasr_mapbase);
> out:
> + of_node_put(cpu);
> return err;
> }
Notice that cpu is only used for the max_freq calculation, so we could
instead do:
diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 6b1e4abe3248..42a0a4b8e87d 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -131,11 +131,20 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
int err = -ENODEV;
cpu = of_get_cpu_node(policy->cpu, NULL);
-
- of_node_put(cpu);
if (!cpu)
goto out;
+ max_freqp = of_get_property(cpu, "clock-frequency", NULL);
+ if (!max_freqp) {
+ of_node_put(cpu);
+ err = -EINVAL;
+ goto out;
+ }
+
+ /* we need the freq in kHz */
+ max_freq = *max_freqp / 1000;
+ of_node_put(cpu);
+
dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
if (!dn)
dn = of_find_compatible_node(NULL, NULL,
@@ -172,15 +181,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
pr_debug("init cpufreq on CPU %d\n", policy->cpu);
- max_freqp = of_get_property(cpu, "clock-frequency", NULL);
- if (!max_freqp) {
- err = -EINVAL;
- goto out_unmap_sdcpwr;
- }
-
- /* we need the freq in kHz */
- max_freq = *max_freqp / 1000;
-
pr_debug("max clock-frequency is at %u kHz\n", max_freq);
pr_debug("initializing frequency table\n");
Though arguably this function should hold a reference to cpu anyway,
because it doesn't want the CPU to removed out from under it. It's a
CPUfreq driver after all.
cheers
^ permalink raw reply related
* RE: [PATCH] cpufreq: imx-cpufreq-dt: Assign max supported frequency as suspend frequency
From: Anson Huang @ 2019-07-09 3:09 UTC (permalink / raw)
To: Leonard Crestez, viresh.kumar@linaro.org
Cc: rjw@rjwysocki.net, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx, Lucas Stach
In-Reply-To: <VI1PR04MB5055565FFF1241B61B47F22AEEF60@VI1PR04MB5055.eurprd04.prod.outlook.com>
Hi, Leonard
> On 7/8/2019 10:55 AM, Anson.Huang@nxp.com wrote:
> > To reduce the suspend/resume latency, CPU's max supported frequency
> > should be used during low level suspend/resume phase, "opp-suspend"
> > property is NOT feasible since OPP defined in DT could be NOT
> > supported according to speed garding and market segment fuse settings.
> > So we can assign the cpufreq policy's suspend_freq with max available
> > frequency provided by cpufreq driver.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>
> > diff --git a/drivers/cpufreq/imx-cpufreq-dt.c
> > b/drivers/cpufreq/imx-cpufreq-dt.c
>
> > +static int __init imx_cpufreq_dt_setup_suspend_opp(void)
> > +{
> > + struct cpufreq_policy *policy = cpufreq_cpu_get(0);
> > +
> > + policy->suspend_freq = cpufreq_quick_get_max(0);
> > +
> > + return 0;
> > +}
> > +late_initcall(imx_cpufreq_dt_setup_suspend_opp);
>
> The imx-cpufreq-dt driver is built as a module by default and this patch
> produces an error:
>
> In file included from ../drivers/cpufreq/imx-cpufreq-dt.c:11:
> ../include/linux/module.h:131:42: error: redefinition of ‘__inittest’
> static inline initcall_t __maybe_unused __inittest(void) \
> ^~~~~~~~~~
> ../include/linux/device.h:1656:1: note: in expansion of macro ‘module_init’
> module_init(__driver##_init); \
> ^~~~~~~~~~~
>
> As far as I can tell late_initcall is not supported for modules.
Ah, yes, I have NOT test the module build, I ONLY tested the built-in case, thanks for
reminder.
>
> Viresh: "max freq as suspend freq" is something that could be useful for
> other SOC families. The hardware can suspend at any freq; it's just that the
> highest one makes sense because it makes suspend/resume slightly faster.
Agree.
>
> Could this behavior be pushed to cpufreq-dt as a bool flag inside struct
> cpufreq_dt_platform_data?
>
> Only a few other platforms use this, most others pass NULL like imx. But
> passing custom SOC-specific flags to cpufreq-dt makes a lot of sense
Although we have other methods to make it work for i.MX platforms, like setting
the suspend freq as this patch did but ONLY be called before suspend, but if common
cpufreq-dt can handle this case, that would benefit us and other platforms a lot, waiting
for your opinion.
Thanks,
Anson
^ permalink raw reply
* Re: [PATCH v4] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()
From: Viresh Kumar @ 2019-07-09 2:42 UTC (permalink / raw)
To: Wen Yang
Cc: linux-kernel, xue.zhihong, wang.yi59, cheng.shengyu,
Rafael J. Wysocki, linuxppc-dev, linux-pm
In-Reply-To: <1562629144-13584-1-git-send-email-wen.yang99@zte.com.cn>
On 09-07-19, 07:39, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> v4: restore the blank line.
I don't find it restored in the below code.
> v3: fix a leaked reference.
> v2: clean up the code according to the advice of viresh.
>
> drivers/cpufreq/pasemi-cpufreq.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
> index 6b1e4ab..f0c98fc 100644
> --- a/drivers/cpufreq/pasemi-cpufreq.c
> +++ b/drivers/cpufreq/pasemi-cpufreq.c
> @@ -128,20 +128,21 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
> int cur_astate, idx;
> struct resource res;
> struct device_node *cpu, *dn;
> - int err = -ENODEV;
> + int err;
>
> cpu = of_get_cpu_node(policy->cpu, NULL);
>
> - of_node_put(cpu);
> if (!cpu)
> - goto out;
> + return -ENODEV;
>
> dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
> if (!dn)
> dn = of_find_compatible_node(NULL, NULL,
> "pasemi,pwrficient-sdc");
> - if (!dn)
> + if (!dn) {
> + err = -ENODEV;
> goto out;
> + }
> err = of_address_to_resource(dn, 0, &res);
> of_node_put(dn);
> if (err)
> @@ -196,6 +197,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
> policy->cur = pas_freqs[cur_astate].frequency;
> ppc_proc_freq = policy->cur * 1000ul;
>
> + of_node_put(cpu);
> return cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
>
> out_unmap_sdcpwr:
> @@ -204,6 +206,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
> out_unmap_sdcasr:
> iounmap(sdcasr_mapbase);
> out:
> + of_node_put(cpu);
> return err;
> }
>
> --
> 2.9.5
--
viresh
^ permalink raw reply
* [PATCH v4] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()
From: Wen Yang @ 2019-07-08 23:39 UTC (permalink / raw)
To: linux-kernel
Cc: xue.zhihong, wang.yi59, cheng.shengyu, Wen Yang,
Rafael J. Wysocki, Viresh Kumar, linuxppc-dev, linux-pm
The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.
Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
v4: restore the blank line.
v3: fix a leaked reference.
v2: clean up the code according to the advice of viresh.
drivers/cpufreq/pasemi-cpufreq.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 6b1e4ab..f0c98fc 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -128,20 +128,21 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
int cur_astate, idx;
struct resource res;
struct device_node *cpu, *dn;
- int err = -ENODEV;
+ int err;
cpu = of_get_cpu_node(policy->cpu, NULL);
- of_node_put(cpu);
if (!cpu)
- goto out;
+ return -ENODEV;
dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
if (!dn)
dn = of_find_compatible_node(NULL, NULL,
"pasemi,pwrficient-sdc");
- if (!dn)
+ if (!dn) {
+ err = -ENODEV;
goto out;
+ }
err = of_address_to_resource(dn, 0, &res);
of_node_put(dn);
if (err)
@@ -196,6 +197,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
policy->cur = pas_freqs[cur_astate].frequency;
ppc_proc_freq = policy->cur * 1000ul;
+ of_node_put(cpu);
return cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
out_unmap_sdcpwr:
@@ -204,6 +206,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
out_unmap_sdcasr:
iounmap(sdcasr_mapbase);
out:
+ of_node_put(cpu);
return err;
}
--
2.9.5
^ permalink raw reply related
* [PATCH v2] tools/power/x86/intel-speed-select: Add .gitignore file
From: Prarit Bhargava @ 2019-07-08 23:17 UTC (permalink / raw)
To: linux-pm
Cc: Prarit Bhargava, Srinivas Pandruvada, Andy Shevchenko,
David Arcari
Add a .gitignore file for build include/ and final binary.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: David Arcari <darcari@redhat.com>
---
tools/power/x86/intel-speed-select/.gitignore | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 tools/power/x86/intel-speed-select/.gitignore
diff --git a/tools/power/x86/intel-speed-select/.gitignore b/tools/power/x86/intel-speed-select/.gitignore
new file mode 100644
index 000000000000..f61145925ce9
--- /dev/null
+++ b/tools/power/x86/intel-speed-select/.gitignore
@@ -0,0 +1,2 @@
+include/
+intel-speed-select
--
2.21.0
^ permalink raw reply related
* [GIT PULL] ACPI updates for v5.3-rc1
From: Rafael J. Wysocki @ 2019-07-08 21:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: ACPI Devel Maling List, Linux Kernel Mailing List, Linux PM
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-5.3-rc1
with top-most commit 64372c0b7dcbc9ad08b1bad877ae8d8cddb62e45
Merge branches 'acpi-apei', 'acpi-doc' and 'acpi-soc'
on top of commit 6fbc7275c7a9ba97877050335f290341a1fd8dbf
Linux 5.2-rc7
to receive ACPI updates for 5.3-rc1.
These update the ACPICA code in the kernel to upstream revision
20190703, fix up the handling of GPEs in ACPICA, allow some more ACPI
code to be built on ARM64 platforms, allow BGRT to be overridden, fix
minor issues and clean up assorted pieces of ACPI code.
Specifics:
- Update the ACPICA code in the kernel to upstream revision 20190703
including:
* Initial/defalut namespace creation simplification (Bob Moore).
* Object initialization sequence update (Bob Moore).
* Removal of legacy module-level (dead) code (Erik Schmauss).
* Table load object initialization update (Erik Schmauss, Nikolaus
Voss).
- Fix GPE enabling issue in ACPICA causing premature wakeups from
suspend-to-idle to occur (Rafael Wysocki).
- Allow ACPI AC and battery drivers to be built on non-X86 (Ard
Biesheuvel).
- Fix address space handler removal in the ACPI PMIC driver for
Intel platforms (Andy Shevchenko).
- Allow BGRT to be overridden via initrd or configfs (Andrea Oliveri).
- Fix object resolution on table loads via configfs (Nikolaus Voss).
- Clean up assorted pieces of ACPI code and tools (Colin Ian King,
Liguang Zhang, Masahiro Yamada).
- Fix documentation build warning, convert the extcon document to
ReST and add it to the ACPI documentation (Mauro Carvalho Chehab,
Qian Cai).
Thanks!
---------------
Andrea Oliveri (1):
ACPI: tables: Allow BGRT to be overridden
Andy Shevchenko (1):
ACPI / PMIC: intel: Drop double removal of address space handler
Ard Biesheuvel (1):
ACPI: Make AC and battery drivers available on !X86
Bob Moore (3):
ACPICA: Namespace: simplify creation of the initial/default namespace
ACPICA: Update for object initialization sequence
ACPICA: Update version to 20190703
Colin Ian King (1):
ACPI: APD: remove redundant assignment to pointer clk
Erik Schmauss (2):
ACPICA: remove legacy module-level code due to deprecation
ACPICA: Update table load object initialization
Liguang Zhang (1):
ACPI / APEI: Remove needless __ghes_check_estatus() calls
Masahiro Yamada (1):
ACPI: tools: Exclude tools/* from .gitignore patterns
Mauro Carvalho Chehab (1):
docs: extcon: convert it to ReST and move to ACPI dir
Nikolaus Voss (1):
ACPI: configfs: Resolve objects on host-directed table loads
Qian Cai (1):
ACPI: OSL: Make a W=1 kernel-doc warning go away
Rafael J. Wysocki (1):
ACPICA: Clear status of GPEs on first direct enable
---------------
.../acpi/extcon-intel-int3496.rst} | 14 +-
Documentation/firmware-guide/acpi/index.rst | 1 +
MAINTAINERS | 6 +-
drivers/acpi/Kconfig | 2 -
drivers/acpi/acpi_apd.c | 2 +-
drivers/acpi/acpi_configfs.c | 6 +-
drivers/acpi/acpica/acevents.h | 3 +-
drivers/acpi/acpica/acglobal.h | 1 -
drivers/acpi/acpica/acnamesp.h | 2 -
drivers/acpi/acpica/dsinit.c | 2 +-
drivers/acpi/acpica/evgpe.c | 8 +-
drivers/acpi/acpica/evgpeblk.c | 2 +-
drivers/acpi/acpica/evxface.c | 2 +-
drivers/acpi/acpica/evxfgpe.c | 2 +-
drivers/acpi/acpica/exconfig.c | 16 +-
drivers/acpi/acpica/nsaccess.c | 54 ++++--
drivers/acpi/acpica/nseval.c | 190 ---------------------
drivers/acpi/acpica/nsinit.c | 49 +++---
drivers/acpi/acpica/nsload.c | 12 --
drivers/acpi/acpica/nsutils.c | 12 --
drivers/acpi/acpica/tbdata.c | 13 --
drivers/acpi/acpica/tbxfload.c | 7 +
drivers/acpi/acpica/utinit.c | 1 -
drivers/acpi/acpica/utxfinit.c | 18 +-
drivers/acpi/apei/ghes.c | 2 +-
drivers/acpi/osl.c | 4 +-
drivers/acpi/pmic/intel_pmic.c | 2 -
drivers/acpi/tables.c | 21 +--
include/acpi/acpi_io.h | 4 +-
include/acpi/acpixf.h | 2 +-
tools/power/acpi/.gitignore | 8 +-
31 files changed, 131 insertions(+), 337 deletions(-)
^ permalink raw reply
* [GIT PULL] Power management updates for v5.3-rc1
From: Rafael J. Wysocki @ 2019-07-08 21:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux PM, ACPI Devel Maling List, Linux PCI,
Linux Kernel Mailing List
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-5.3-rc1
with top-most commit 586a07dca8c51b966960d1f0d8be9c27d7e0a95c
Merge branch 'pm-cpufreq'
on top of commit 6fbc7275c7a9ba97877050335f290341a1fd8dbf
Linux 5.2-rc7
to receive power management updates for 5.3-rc1.
These update PCI and ACPI power management (improved handling of
ACPI power resources and PCIe link delays, fixes related to corner
cases, hibernation handling rework), fix and extend the operating
performance points (OPP) framework, add new cpufreq drivers for
Raspberry Pi and imx8m chips, update some other cpufreq drivers,
clean up assorted pieces of PM code and documentation and update
tools.
Specifics:
- Improve the handling of shared ACPI power resources in the PCI
bus type layer (Mika Westerberg).
- Make the PCI layer take link delays required by the PCIe spec
into account as appropriate and avoid polling devices in D3cold
for PME (Mika Westerberg).
- Fix some corner case issues in ACPI device power management and
in the PCI bus type layer, optimiza and clean up the handling of
runtime-suspended PCI devices during system-wide transitions to
sleep states (Rafael Wysocki).
- Rework hibernation handling in the ACPI core and the PCI bus type
to resume runtime-suspended devices before hibernation (which
allows some functional problems to be avoided) and fix some ACPI
power management issues related to hiberation (Rafael Wysocki).
- Extend the operating performance points (OPP) framework to support
a wider range of devices (Rajendra Nayak, Stehpen Boyd).
- Fix issues related to genpd_virt_devs and issues with platforms
using the set_opp() callback in the OPP framework (Viresh Kumar,
Dmitry Osipenko).
- Add new cpufreq driver for Raspberry Pi (Nicolas Saenz Julienne).
- Add new cpufreq driver for imx8m and imx7d chips (Leonard Crestez).
- Fix and clean up the pcc-cpufreq, brcmstb-avs-cpufreq, s5pv210,
and armada-37xx cpufreq drivers (David Arcari, Florian Fainelli,
Paweł Chmiel, YueHaibing).
- Clean up and fix the cpufreq core (Viresh Kumar, Daniel Lezcano).
- Fix minor issue in the ACPI system sleep support code and export
one function from it (Lenny Szubowicz, Dexuan Cui).
- Clean up assorted pieces of PM code and documentation (Kefeng Wang,
Andy Shevchenko, Bart Van Assche, Greg Kroah-Hartman, Fuqian Huang,
Geert Uytterhoeven, Mathieu Malaterre, Rafael Wysocki).
- Update the pm-graph utility to v5.4 (Todd Brandt).
- Fix and clean up the cpupower utility (Abhishek Goel, Nick Black).
Thanks!
---------------
Abhishek Goel (1):
cpupower : frequency-set -r option misses the last cpu in related cpu list
Andy Shevchenko (1):
ACPI / sleep: Switch to use acpi_dev_get_first_match_dev()
Bart Van Assche (1):
PM: sleep: Show how long dpm_suspend_start() and dpm_suspend_end() take
Daniel Lezcano (1):
cpufreq: Move the IS_ENABLED(CPU_THERMAL) macro into a stub
David Arcari (1):
cpufreq: pcc-cpufreq: Fail initialization if driver cannot be registered
Dexuan Cui (1):
ACPI: PM: Make acpi_sleep_state_supported() non-static
Dmitry Osipenko (1):
opp: Don't use IS_ERR on invalid supplies
Florian Fainelli (2):
cpufreq: brcmstb-avs-cpufreq: Fix initial command check
cpufreq: brcmstb-avs-cpufreq: Fix types for voltage/frequency
Fuqian Huang (1):
kernel: power: swap: use kzalloc() instead of kmalloc() followed
by memset()
Geert Uytterhoeven (2):
PM / clk: Remove error message on out-of-memory condition
Documentation: ABI: power: Add missing newline at end of file
Greg Kroah-Hartman (2):
power: avs: smartreflex: no need to check return value of
debugfs_create functions
drivers: base: power: remove wakeup_sources_stats_dentry variable
Kefeng Wang (1):
drivers: base: power: clock_ops: Use of_clk_get_parent_count()
Lenny Szubowicz (1):
ACPI / LPIT: Correct LPIT end address for lpit_process()
Leonard Crestez (5):
cpufreq: Add imx-cpufreq-dt driver
dt-bindings: imx-cpufreq-dt: Document opp-supported-hw usage
cpufreq: imx-cpufreq-dt: Fix no OPPs available on unfused parts
cpufreq: imx-cpufreq-dt: Remove global platform match list
cpufreq: Switch imx7d to imx-cpufreq-dt for speed grading
Mathieu Malaterre (1):
PM: hibernate: powerpc: Expose pfn_is_nosave() prototype
Mika Westerberg (5):
PCI: Add missing link delays required by the PCIe spec
PCI: Do not poll for PME if the device is in D3cold
PCI / ACPI: Use cached ACPI device state to get PCI device power state
ACPI / PM: Introduce concept of a _PR0 dependent device
PCI / ACPI: Add _PR0 dependent devices
Nick Black (1):
cpupower: correct spelling of interval
Nicolas Saenz Julienne (1):
cpufreq: add driver for Raspberry Pi
Paweł Chmiel (1):
cpufreq: s5pv210: Don't flood kernel log after cpufreq change
Rafael J. Wysocki (14):
PCI: PM: Avoid resuming devices in D3hot during system suspend
PCI: PM: Replace pci_dev_keep_suspended() with two functions
PM: suspend: Rename pm_suspend_via_s2idle()
PM: sleep: Update struct wakeup_source documentation
ACPI: PM: Avoid evaluating _PS3 on transitions from D3hot to D3cold
ACPI: PM: Allow transitions to D0 to occur in special cases
PCI: PM/ACPI: Refresh all stale power state data in pci_pm_complete()
PM: ACPI/PCI: Resume all devices during hibernation
PCI: PM: Simplify bus-level hibernation callbacks
ACPI: PM: Simplify and fix PM domain hibernation callbacks
ACPI: PM: Introduce "poweroff" callbacks for ACPI PM domain and LPSS
ACPI: PM: Drop unused function and function header
ACPI: PM: Unexport acpi_device_get_power()
PM: sleep: Drop dev_pm_skip_next_resume_phases()
Rajendra Nayak (1):
opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes
Stephen Boyd (1):
opp: Don't overwrite rounded clk rate
Todd Brandt (3):
Update to pm-graph 5.3
Update to pm-graph 5.4
Add README and update pm-graph and sleepgraph docs
Viresh Kumar (7):
opp: Attach genpds to devices from within OPP core
opp: Allocate genpd_virt_devs from dev_pm_opp_attach_genpd()
cpufreq: Remove redundant !setpolicy check
cpufreq: Use has_target() instead of !setpolicy
cpufreq: Don't skip frequency validation for has_target() drivers
cpufreq: Consolidate cpufreq_update_current_freq() and __cpufreq_get()
cpufreq: Avoid calling cpufreq_verify_current_freq() from handle_update()
YueHaibing (1):
cpufreq: armada-37xx: Remove set but not used variable 'freq'
---------------
Documentation/ABI/testing/sysfs-power | 2 +-
.../devicetree/bindings/cpufreq/imx-cpufreq-dt.txt | 37 +
arch/powerpc/kernel/suspend.c | 1 +
arch/s390/kernel/entry.h | 1 -
drivers/acpi/acpi_lpit.c | 7 +-
drivers/acpi/acpi_lpss.c | 111 ++-
drivers/acpi/device_pm.c | 165 ++--
drivers/acpi/internal.h | 7 +
drivers/acpi/power.c | 135 ++++
drivers/acpi/sleep.c | 22 +-
drivers/base/power/clock_ops.c | 6 +-
drivers/base/power/main.c | 36 +-
drivers/base/power/wakeup.c | 6 +-
drivers/cpufreq/Kconfig.arm | 17 +
drivers/cpufreq/Makefile | 2 +
drivers/cpufreq/armada-37xx-cpufreq.c | 4 +-
drivers/cpufreq/brcmstb-avs-cpufreq.c | 12 +-
drivers/cpufreq/cpufreq-dt-platdev.c | 5 +-
drivers/cpufreq/cpufreq.c | 121 ++-
drivers/cpufreq/imx-cpufreq-dt.c | 97 +++
drivers/cpufreq/pcc-cpufreq.c | 4 +-
drivers/cpufreq/raspberrypi-cpufreq.c | 97 +++
drivers/cpufreq/s5pv210-cpufreq.c | 2 +-
drivers/input/serio/i8042.c | 2 +-
drivers/opp/core.c | 174 +++--
drivers/opp/of.c | 30 +-
drivers/pci/pci-acpi.c | 14 +-
drivers/pci/pci-driver.c | 74 +-
drivers/pci/pci.c | 116 ++-
drivers/pci/pci.h | 8 +-
drivers/pci/pcie/portdrv_core.c | 66 ++
drivers/power/avs/smartreflex.c | 41 +-
drivers/soc/imx/soc-imx8.c | 3 +
include/acpi/acpi_bus.h | 11 +-
include/linux/acpi.h | 14 +-
include/linux/cpufreq.h | 6 +
include/linux/pm.h | 1 -
include/linux/pm_opp.h | 8 +-
include/linux/pm_wakeup.h | 2 +-
include/linux/suspend.h | 5 +-
kernel/power/power.h | 2 -
kernel/power/suspend.c | 6 +-
kernel/power/swap.c | 3 +-
tools/power/cpupower/man/cpupower-monitor.1 | 2 +-
tools/power/cpupower/po/cs.po | 2 +-
tools/power/cpupower/po/de.po | 2 +-
tools/power/cpupower/po/fr.po | 2 +-
tools/power/cpupower/po/it.po | 2 +-
tools/power/cpupower/po/pt.po | 2 +-
tools/power/cpupower/utils/cpufreq-set.c | 2 +
tools/power/pm-graph/README | 552 +++++++++++++
tools/power/pm-graph/bootgraph.py | 8 +-
tools/power/pm-graph/config/example.cfg | 26 +
tools/power/pm-graph/sleepgraph.8 | 16 +-
tools/power/pm-graph/sleepgraph.py | 857 ++++++++++++++++-----
55 files changed, 2325 insertions(+), 631 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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).