Hi, Russell, > 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. > [Alison Wang] What's your opinion about this explanation? Is this patch acceptable?
Best Regards, Alison Wang