[V2,0/6] PM / Domains: Implement domain performance states

Message ID cover.1486611268.git.viresh.kumar@linaro.org
Headers show
Series
  • PM / Domains: Implement domain performance states
Related show

Message

Viresh Kumar Feb. 9, 2017, 3:41 a.m.
Hi,

An earlier series[1] tried to implement bindings for PM domain
performance states. Rob Herring suggested that we can actually merge the
supporting code first instead of bindings, as that will make things
easier to understand for all. The bindings can be decided and merged
later.

The bindings [1] aren't discarded yet and this series is based on a
version of those only. The bindings are only used by the last patch,
which should not be applied and is only sent for completeness.

IOW, this series doesn't have any dependencies and can be merged
straight away without waiting for the DT bindings.

A brief summary of the problem this series is trying to solve:

Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.

We decided earlier that we should extend Power Domain framework to
support active state power management as well.  The power-domains until
now were only concentrating on the idle state management of the device
and this needs to change in order to reuse the infrastructure of power
domains for active state management.

The first 5 patches update the PM domain and QoS frameworks to support
that and the last one presents the front end interface to it.

The V1 series was tested by hacking the OPP core a bit but this one is
also tested by Rajendra Nayak (Qcom) on *real* Qualcomm hardware for
which this work is done. And most of his feedback is incorporated here.

V1->V2:
- Based over latest pm/linux-next
- It is mostly a resend of what is sent earlier as this series hasn't
  got any reviews so far and Rafael suggested that its better I resend
  it.
- Only the 4/6 patch got an update, which was shared earlier as reply to
  V1 as well. It has got several fixes for taking care of power domain
  hierarchy, etc.

--
viresh

[1] https://marc.info/?l=linux-kernel&m=148154020127722&w=2

Viresh Kumar (6):
  PM / QOS: Add default case to the switch
  PM / QOS: Pass request type to dev_pm_qos_{add|remove}_notifier()
  PM / QOS: Add 'performance' request
  PM / domain: Register for PM QOS performance notifier
  PM / domain: Save/restore performance state at runtime suspend/resume
  PM / OPP: Add support to parse domain-performance-state

 Documentation/power/pm_qos_interface.txt |  11 ++-
 drivers/base/power/domain.c              | 125 +++++++++++++++++++++++++++++--
 drivers/base/power/opp/core.c            |  75 +++++++++++++++++++
 drivers/base/power/opp/debugfs.c         |   4 +
 drivers/base/power/opp/of.c              |  44 +++++++++++
 drivers/base/power/opp/opp.h             |  12 +++
 drivers/base/power/qos.c                 |  74 ++++++++++++++++--
 include/linux/pm_domain.h                |   6 ++
 include/linux/pm_qos.h                   |  16 +++-
 9 files changed, 345 insertions(+), 22 deletions(-)

-- 
2.7.1.410.g6faf27b

Comments

Ulf Hansson Feb. 17, 2017, 7:46 a.m. | #1
On 17 February 2017 at 06:38, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 09-02-17, 09:11, Viresh Kumar wrote:

>> The first 5 patches update the PM domain and QoS frameworks to support

>> that and the last one presents the front end interface to it.

>

> @Kevin and Ulf,

>

> Is there something wrong with this series? Its been 7 weeks since this

> series is getting posted and I haven't received a single review from

> you guys. We will get into the merge window very soon and then it

> wouldn't be good for me to ask for reviews as everyone would be busy.

>

> This stuff and the rest of the development around it is getting

> delayed unnecessarily.

>

> Please see if you guys can take some time out to get this reviewed.


Apologize for the delay! I will have a look asap.

Kind regards
Uffe
Kevin Hilman Feb. 17, 2017, 11:22 p.m. | #2
Viresh Kumar <viresh.kumar@linaro.org> writes:

> An earlier series[1] tried to implement bindings for PM domain

> performance states. Rob Herring suggested that we can actually merge the

> supporting code first instead of bindings, as that will make things

> easier to understand for all. The bindings can be decided and merged

> later.

>

> The bindings [1] aren't discarded yet and this series is based on a

> version of those only. The bindings are only used by the last patch,

> which should not be applied and is only sent for completeness.

>

> IOW, this series doesn't have any dependencies and can be merged

> straight away without waiting for the DT bindings.

>

> A brief summary of the problem this series is trying to solve:

>

> Some platforms have the capability to configure the performance state of

> their Power Domains. The performance levels are represented by positive

> integer values, a lower value represents lower performance state.


And what about domains where the performance levels are represented by
someting other than positive integer values? 

IMO, this implementation should start with a more generic approach
(e.g. OPPs) that would be useful on more SoCs that just qcom.  For SoCs
like QCOM, you could use dummy/simplfied OPPs that represent the integer
values passed to the qcom firmware.

> We decided earlier that we should extend Power Domain framework to

> support active state power management as well. The power-domains until

> now were only concentrating on the idle state management of the device

> and this needs to change in order to reuse the infrastructure of power

> domains for active state management.


Yes.  Thanks for working on it!

Kevin
Viresh Kumar Feb. 20, 2017, 9:18 a.m. | #3
On 17-02-17, 15:58, Kevin Hilman wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:

> 

> > With runtime PM, the devices get suspended while the system is up and

> > running in order to save power. At such times, it is important to

> > re-evaluate the required performance state of the domain, in order to

> > choose a lower state if possible.

> >

> > This patch updates the genpd suspend/resume callbacks to do that.

> >

> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

> 

> Doesn't this assume that a device in the domain would need to change

> performance state while runtime suspended.  How would that happen?

> 

> Rather than adding this here, I would think that drivers would instead

> remove any QoS requests before going into runtime suspend, which would

> trigger an update before runtime suspending.


Okay, lets leave it for the drivers, at least for the time being. I
will drop this patch.

-- 
viresh