On Tue, Jan 5, 2016 at 3:46 AM Thomas Gleixner <t...@linutronix.de> wrote: > > On Sat, 2 Jan 2016, Russell King - ARM Linux wrote: > > On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote: > > > I have no real opinion about that patch. It does no harm to > > > unconditionally > > > setup the hrtimer based broadcast even if it's never used. > > > > > > Up to the arch maintainer to decide. > > > > That's really not fair to keep shovelling these kinds of decisions onto > > architecture maintainers without any kind of explanation about how an > > architecture maintainer should make such a decision. > > > > Do I roll a 6-face dice, and if it gives an odd number, I apply this > > patch, otherwise I reject it? > > > > Is there a technical basis for making the decision? If so, please > > explain what the technical arguments are against having or not having > > this change. > > The hrtimer based broadcast device is used when you have per cpu timers which > stop in deeper power states, but you have no other timer hardware on the chip > which can backup the per cpu timer in deep power states. The trick is that it > emulates a timer hardware via a hrtimer and then tells the cpu idle code not > to go into deep power states on the cpu which owns that hrtimer. All other > cpus can go as deep as they want and still get woken up. > > The only downside of adding this unconditionally is extra code in case that it > is not needed on a particular platform. > > Hope that helps.
Hi Russell, This has been pending for so long time. I assume this is an ack from Thomas. And given the same thing has been added for arm64 and powerpc architecture, can you also merge this for ARM? Regards, Leo
