[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100527173118.GE2468@srcf.ucam.org>
Date: Thu, 27 May 2010 18:31:18 +0100
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Alan Stern <stern@...land.harvard.edu>,
Peter Zijlstra <peterz@...radead.org>,
Paul@...p1.linux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Linux PM <linux-pm@...ts.linux-foundation.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
> Oh no. They paper over a short coming. If there is a pending event,
> the kernel knows that. It just does not make use of this
> information. Blockers just paper over this by sprinkling
> do_not_suspend() calls all over the place. What a sensible solution.
Even if we could use suspend-via-deep-idle-state on PCs, we still need
to be able to enter suspend while the system isn't idle. There's two
ways to do that:
1) Force the system to be idle. Doing this race-free is difficult.
2) Enter suspend even though the system isn't idle. Since we can't rely
on the scheduler, we need drivers to know whether userspace has consumed
all wakeup events before allowing the transition to occur. Doing so
requires either in-kernel suspend blockers or something that's almost
identical.
--
Matthew Garrett | mjg59@...f.ucam.org
--
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