gmane.linux.power-management.general

Re: [PATCH 0/2] bug fixes for coupled cpuidle

Santosh Shilimkar — 2012-05-21T06:44:49

I confirm that these two fixes are needed to get couple idle
v4 series working.

Regards
Santosh

[PATCH][v2] ARM: davinci: cpuidle - remove ops

Daniel Lezcano — 2012-05-20T22:07:20

This patch removes the ops usage because we have the index
passed as parameter to the idle function and we can determine
if we do WFI or memory retention.

The benefit of this cleanup is the removal of:
 * the ops
 * the statedata usage because we want to get rid of it in all the drivers
 * extra structure definition
 * extra functions definition
 * remove macro definition using BIT(0)

It also benefits the readability.

Signed-off-by: Daniel Lezcano <daniel.lezcano< at >linaro.org>
---
 arch/arm/mach-davinci/cpuidle.c |   81 +++++++++++++--------------------------
 1 files changed, 27 insertions(+), 54 deletions(-)

diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index f0f179c..1b0782a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
< at >< at > -25,35 +25,46 < at >< at >
 
 #define DAVINCI_CPUIDLE_MAX_STATES2
 
-struct davinci_ops {
-void (*enter) (u32 flags);
-void (*exit) (u32 flags);
-u32 flags;
-};
+static bool ddr2_pwdn;
+
+static void __iomem *ddr2_reg_bas

Re: [PATCH 2/2] ARM: DAVINCI: cpuidle - remove ops

Daniel Lezcano — 2012-05-20T10:37:02

Sure, I will resend a version without the initialization and the 
_raw_write variant.

Thanks
   -- Daniel

Re: [PATCH 0/2] ARM: DAVINCI: cpuidle - cleanups

Daniel Lezcano — 2012-05-19T09:26:24

Hi,

maybe these patches did not raise attention.
Do you think they sound good ?

Thanks

Re: [PATCHv3 0/4] coupled cpuidle state support

Shilimkar, Santosh — 2012-05-19T07:04:07

Great !!
I will pull Len's tree and rebase OMAP patches against it.

Regards
Santosh

Re: [PATCHv3 0/4] coupled cpuidle state support

Colin Cross — 2012-05-18T20:18:35

Len silently picked up the last version.  I just posted two fixes to
it, hopefully he'll pick up those too.

Re: [PATCHv3 0/4] coupled cpuidle state support

Rafael J. Wysocki — 2012-05-18T19:03:55

That should be Len, but he's been silent recently.

How urgent is it?

Rafael

[PATCH 0/2] bug fixes for coupled cpuidle

Colin Cross — 2012-05-18T18:05:22

The last modifications made to the coupled cpuidle patches introduced
two bugs that I missed during testing.  The online count was never
initialized, causing coupled idle to always wait and never enter the
ready loop.  That hid the second bug, the ready count could never be
decremented after exiting idle.

Len, these two patches could be squashed into patch 3 of the original
set.  If you do squash them, you could also add Rafael's tags to the
set (Reviewed-by on 1 and 2, acked-by on 3).  Or I can reupload the
whole stack as v5 if you prefer.

[PATCH 1/2] cpuidle: coupled: fix count of online cpus

Colin Cross — 2012-05-18T18:05:23

online_count was never incremented on boot, and was also counting
cpus that were not part of the coupled set.  Fix both issues by
introducting a new function that counts online coupled cpus, and
call it from register as well as the hotplug notifier.

Signed-off-by: Colin Cross <ccross< at >android.com>
---
 drivers/cpuidle/coupled.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index 3e65de1..b02810a 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
< at >< at > -532,6 +532,13 < at >< at > int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
 return entered_state;
 }
 
+static void cpuidle_coupled_update_online_cpus(struct cpuidle_coupled *coupled)
+{
+cpumask_t cpus;
+cpumask_and(&cpus, cpu_online_mask, &coupled->coupled_cpus);
+coupled->online_count = cpumask_weight(&cpus);
+}
+
 /**
  * cpuidle_coupled_register_device - register a coupled cpuidle device
  * < at >dev: struct cpuidle_device for the current cpu
< at >< at >

[PATCH 2/2] cpuidle: coupled: fix decrementing readycount

Colin Cross — 2012-05-18T18:05:24

cpuidle_coupled_set_not_ready sometimes refuses to decrement the
ready count in order to prevent a race condition.  This makes it
unsuitable for use when finished with idle.  Add a new function
cpuidle_coupled_set_done that decrements both the ready count and
waiting count, and call it after idle is complete.

Signed-off-by: Colin Cross <ccross< at >android.com>
---
 drivers/cpuidle/coupled.c |   18 ++++++++++++++++--
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index b02810a..fc427fa 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
< at >< at > -388,6 +388,21 < at >< at > static void cpuidle_coupled_set_not_waiting(int cpu,
 }
 
 /**
+ * cpuidle_coupled_set_done - mark this cpu as leaving the ready loop
+ * < at >cpu: the current cpu
+ * < at >coupled: the struct coupled that contains the current cpu
+ *
+ * Marks this cpu as no longer in the ready and waiting loops.  Decrements
+ * the waiting count first to prevent another cpu looping back in an

Re: [PATCHv3 0/4] coupled cpuidle state support

Santosh Shilimkar — 2012-05-18T10:36:01

[...]


I haven't seen any response so far on who is lining up this
series for 3.5 ? Not sure if it made it to linux-next either.

Regards
santosh

Re: Plumbers: PM constraints micro-conf RFP

Sundar — 2012-05-17T11:30:35

:(

I received this:

Your message (attached below) was not delivered to:

 paulmck< at >vnet.ibm.com

because:

 Bad destination mailbox address

Final-recipient: rfc822;paulmck< at >vnet.ibm.com
Action: failed
Status: 5.1.1
Diagnostic-code: X-Xagent; Bad destination mailbox address

On Thu, May 17, 2012 at 4:47 PM, Sundar <sunder.svit< at >gmail.com> wrote:

Re: Plumbers: PM constraints micro-conf RFP

Sundar — 2012-05-17T11:17:48

I put in a rough draft < at >
https://blueprints.launchpad.net/lpc/+spec/lpc2012-power-management-constraints

Cheers!

On Wed, May 16, 2012 at 5:43 AM, mark gross <markgross< at >thegnar.org> wrote:

Re: Plumbers: PM constraints micro-conf RFP

Amit Kucheria — 2012-05-15T12:58:59

Jean,

Do you already consider GPU drivers, backlight drivers and battery
charging for setting constraints (performance and thermal) ?

Between your, Eduardo's and Antti's proposals, a lot of ground is
being covered and I don't want to make a new proposal just for these
three. But we're keen on helping consolidate on generic interfaces to
deal with these three kinds of devices.

Re: Plumbers: PM constraints micro-conf RFP

Kevin Hilman — 2012-05-09T18:54:39

Hi Mark,

mark gross <markgross< at >thegnar.org> writes:


Thanks for organizing this.

I won't be at Plumbers this year (I'll be on vacation), but will
certainly participate by email as I have an interest in these topics.

I've added Jean Pihet to Cc as he is also working on QoS/constraints
related topics.

Kevin

Re: Plumbers: PM constraints micro-conf RFP

Kevin Hilman — 2012-05-09T18:35:09

Hi Mark,

mark gross <markgross< at >thegnar.org> writes:


Thanks for organizing this.

I won't be at Plumbers this year (I'll be on vacation), but will
certainly participate by email as I have an interest in these topics.

I've added Jean Pihet to Cc as he is also working on QoS/constraints
related topics.

Kevin

Re: Plumbers: PM constraints micro-conf RFP

Mansoor, Illyas — 2012-05-16T09:45:40

Valentin,
plumbers
critical mass
extending pm-
of
developers
long as
limiting
participate in
the
linux-
correspondence
me.  I know
think its a
cases.
Mark,

Please find a draft proposal on priority based PM-QoS Parameters,
https://blueprints.launchpad.net/lpc/+spec/lpc-2012-priority-based-pmqos-paramet
ers

Thanks,

Re: Plumbers: PM constraints micro-conf RFP

mark gross — 2012-05-16T00:13:35

It will be great to have you there in any case.

It feels like we have enough content to come up with portable
requirements and maybe an ok design that can work for multiple SoC's.

--mark

Re: Plumbers: PM constraints micro-conf RFP

mark gross — 2012-05-16T00:09:33

looks great to me!  you should toss it up on the plumbers site.

--mark

Re: Plumbers: PM constraints micro-conf RFP

Valentin, Eduardo — 2012-05-15T11:00:23

Hello,

I submitted a blueprint on launchpad as well, available here:
https://blueprints.launchpad.net/linux/+spec/lpc2012-cf-thermal-pm-constraint

On Tue, May 15, 2012 at 12:40 PM, Jean Pihet <jean.pihet< at >newoldbits.com> wrote:

Re: Plumbers: PM constraints micro-conf RFP

Jean Pihet — 2012-05-15T09:40:44

Hi!

Here is my proposal for the PM constraints micro-conf RFP, as e-mailed today:

Session title: A New Model for the System and Devices Latency

Name of microconference (if applicable): PM constraints micro-conf,
led by Mark Gross

Abstract:
 Due to the nature of the new SoC architectures the Power Management
needs a new model for the various system latencies. The talk presents:
  . the concepts of system, devices, wake-up and resume latencies,
  . the recent changes in the devices framework for the latency, why
and how to make it generic,
  . the link with the other PM QoS frameworks: thermal, cpuidle,
  . the recent changes in the ARM/OMAP platform code for the system latency,
  . the problems encountered while modelling and measuring the
various latencies,
  . a proposal on the model and on the way to implement it,
  . the planned changes in the device framework, the platform code
and the APIs.

 This talk is oriented towards Linux power management developers. The
goal is to agree on a framework impleme