Features Download
From: Preeti U Murthy <preeti <at> linux.vnet.ibm.com>
Subject: [PATCH V3 0/6] cpuidle/ppc: Enable broadcast support for deep idle states
Newsgroups: gmane.linux.power-management.general
Date: Wednesday 11th September 2013 02:50:49 UTC (over 4 years ago)
On PowerPC, when CPUs enter deep idle states, their local timers get
switched off. An external clock device needs to programmed to wake them
up at their next timer event.
	On PowerPC, we do not have an external device equivalent to HPET,
which is currently used on architectures like x86 under the same scenario.
Instead we assign the local timer of one of the CPUs to do this job.

This patchset is an attempt to hook onto the existing timer broadcast
framework in the kernel by using the local timer of one of the CPUs to do
job of the external clock device.

On expiry of this device, the broadcast framework today has the
to send ipis to all such CPUs whose local timers have expired. Hence the
"broadcast" and the ipi sent is called the broadcast ipi.

This patch series is ported ontop of 3.11-rc7 + the cpuidle driver backend
for power posted by Deepthi Dharwar recently.

Changes in V3:

1. Fix the way in which a broadcast ipi is handled on the idling cpus.
handling on a broadcast ipi is being done now without missing out any timer
stats generation.

2. Fix a bug in the programming of the hrtimer meant to do broadcast.
it to trigger at the earlier of a "broadcast period", and the next wakeup
event. By introducing the "broadcast period" as the maximum period after
which the broadcast hrtimer can fire, we ensure that we do not miss
wakeups in corner cases.

3. On hotplug of a broadcast cpu, trigger the hrtimer meant to do broadcast
to fire immediately on the new broadcast cpu. This will ensure we do not
doing a broadcast pending in the nearest future.

4. Change the type of allocation from GFP_KERNEL to GFP_NOWAIT while
initializing bc_hrtimer since we are in an atomic context and cannot sleep.

5. Use the broadcast ipi to wakeup the newly nominated broadcast cpu on
hotplug of the old instead of smp_call_function_single(). This is because
are interrupt disabled at this point and should not be using
smp_call_function_single or its children in this context to send an ipi.

6. Move GENERIC_CLOCKEVENTS_BROADCAST to arch/powerpc/Kconfig.

7. Fix coding style issues.

Changes in V2: https://lkml.org/lkml/2013/8/14/239

1. Dynamically pick a broadcast CPU, instead of having a dedicated one.
2. Remove the constraint of having to disable tickless idle on the
CPU by queueing a hrtimer dedicated to do broadcast.

V1 posting: https://lkml.org/lkml/2013/7/25/740.

The patchset has been tested for stability in idle and during multi
ebizzy runs.

Many thanks to Ben H, Frederic Weisbecker, Li Yang, Srivatsa S. Bhat and
Vaidyanathan Srinivasan for all their comments and suggestions so far.


Preeti U Murthy (4):
      cpuidle/ppc: Split timer_interrupt() into timer handling and
interrupt handling routines
      cpuidle/ppc: Add basic infrastructure to support the broadcast
framework on ppc
      cpuidle/ppc: Introduce the deep idle state in which the local timers
      cpuidle/ppc: Nominate new broadcast cpu on hotplug of the old

Srivatsa S. Bhat (2):
      powerpc: Free up the IPI message slot of ipi call function
      powerpc: Implement broadcast timer interrupt as an IPI message

 arch/powerpc/Kconfig                    |    1 
 arch/powerpc/include/asm/smp.h          |    3 -
 arch/powerpc/include/asm/time.h         |    4 +
 arch/powerpc/kernel/smp.c               |   23 +++-
 arch/powerpc/kernel/time.c              |  143 ++++++++++++++++++++------
 arch/powerpc/platforms/cell/interrupt.c |    2 
 arch/powerpc/platforms/ps3/smp.c        |    2 
 drivers/cpuidle/cpuidle-ibm-power.c     |  172
 scripts/kconfig/streamline_config.pl    |    0 
 9 files changed, 307 insertions(+), 43 deletions(-)
 mode change 100644 => 100755 scripts/kconfig/streamline_config.pl

To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
CD: 15ms