On Thu, Jun 25, 2015 at 12:10 AM, Michael Ellerman <mich...@ellerman.id.au> wrote: > > > On 24 June 2015 23:50:40 GMT+10:00, "Rafael J. Wysocki" <r...@rjwysocki.net> > wrote: >>On Wednesday, June 24, 2015 01:48:01 AM Preeti U Murthy wrote: >>> On some archs, the local clockevent device stops in deep cpuidle >>states. >>> The broadcast framework is used to wakeup cpus in these idle states, >>in >>> which either an external clockevent device is used to send wakeup >>ipis >>> or the hrtimer broadcast framework kicks in in the absence of such a >>> device. One cpu is nominated as the broadcast cpu and this cpu sends >>> wakeup ipis to sleeping cpus at the appropriate time. This is the >>> implementation in the oneshot mode of broadcast. >>> >>> In periodic mode of broadcast however, the presence of such cpuidle >>> states results in the cpuidle driver calling tick_broadcast_enable() >>> which shuts down the local clockevent devices of all the cpus and >>> appoints the tick broadcast device as the clockevent device for each >>of >>> them. This works on those archs where the tick broadcast device is a >>> real clockevent device. But on archs which depend on the hrtimer >>mode >>> of broadcast, the tick broadcast device hapens to be a pseudo device. >>> The consequence is that the local clockevent devices of all cpus are >>> shutdown and the kernel hangs at boot time in periodic mode. >>> >>> Let us thus not register the cpuidle states which have >>> CPUIDLE_FLAG_TIMER_STOP flag set, on archs which depend on the >>hrtimer >>> mode of broadcast in periodic mode. This patch takes care of doing >>this >>> on powerpc. The cpus would not have entered into such deep cpuidle >>> states in periodic mode on powerpc anyway. So there is no loss here. >>> >>> Signed-off-by: Preeti U Murthy <pre...@linux.vnet.ibm.com> >> >>4.2 material I suppose? > > Yes please, in fact it should be marked for stable too.
That can be done. Which -stable series should it go into? Rafael _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
