[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150209094926.GQ5029@twins.programming.kicks-ass.net>
Date: Mon, 9 Feb 2015 10:49:26 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Thomas Gleixner <tglx@...utronix.de>,
"Li, Aubrey" <aubrey.li@...ux.intel.com>,
"Brown, Len" <len.brown@...el.com>,
Alan Cox <alan@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>,
Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [Update] Re: [PATCH v3]PM/Sleep: Timer quiesce in freeze state
On Fri, Feb 06, 2015 at 11:36:12PM +0100, Rafael J. Wysocki wrote:
> On Friday, February 06, 2015 07:29:22 PM Peter Zijlstra wrote:
> > > So I'm a wee bit confused; if we use an enter_freeze() state that keeps
> > > interrupts disabled; who is going to call the freeze_wake() thing?
> >
> > Ah, I think I see, so we wake up, keep the interrupt pending, re-enable
> > the tick and time and everybody, then re-enable interrupts, take the
> > interrupt and go around the idle loop to find we need a reschedule etc..
>
> Exactly.
So x86 mwait can do this; what other archs can 'sleep' and keep
interrupts disabled?
It looks like the ARM WFI thing wakes on pending interrupts and doesn't
actually require interrupts to be enabled, so that too would work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists