suspend blockers & Android integration
in [Kernel]
|
Prev: How do I ignore the changes made by CVS keyword substitution efficiently?
Next: [PATCH 1/2] x86: make save_stack_address() !CONFIG_FRAME_POINTER friendly
From: Vitaly Wool on 6 Jun 2010 11:50 2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: > On Sun, Jun 06, 2010 at 05:26:09PM +0200, Vitaly Wool wrote: >> 2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: >> > Holding a suspend blocker is entirely orthogonal to runtime pm. The >> > "whole kernel" will not be "active" - it can continue to hit the same >> > low power state in the idle loop, and any runtime pm implementation in >> > the drivers will continue to be active. >> >> Yeah, that might also be the case, But then again, what's the use of >> suspend blockers in this situation? > > The difference between idle-based suspend and opportunistic suspend is > that the former will continue to wake up for timers and will never be > entered if something is using CPU, whereas the latter will be entered > whenever no suspend blocks are held. The problem with opportunistic > suspend is that you might make the decision to suspend simultaneusly > with a wakeup event being received. Suspend blocks facilitate > synchronisation between the kernel and userspace to ensure that all such > events have been consumed and handld appropriately. Right, and then you start taking suspend blockers in kernel here and there which eventually interferes with runtime PM. So I don't buy the "orthogonality" point. Generally speaking, it's not true. ~Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 6 Jun 2010 12:50 On Sun, Jun 06, 2010 at 05:47:10PM +0200, Vitaly Wool wrote: > 2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: > > The difference between idle-based suspend and opportunistic suspend is > > that the former will continue to wake up for timers and will never be > > entered if something is using CPU, whereas the latter will be entered > > whenever no suspend blocks are held. The problem with opportunistic > > suspend is that you might make the decision to suspend simultaneusly > > with a wakeup event being received. Suspend blocks facilitate > > synchronisation between the kernel and userspace to ensure that all such > > events have been consumed and handld appropriately. > > Right, and then you start taking suspend blockers in kernel here and > there which eventually interferes with runtime PM. Suspend blocks prevent system suspend, not any per-device suspend. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 6 Jun 2010 13:10 On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote: > On Sun, 6 Jun 2010, James Bottomley wrote: > > > > 3. We've lost sight of one of the original goals, which was to > > bring the android tree close enough to the kernel so that the > > android downstream driver and board producers don't have to > > choose between the android kernel and vanilla kernel. > > There are two ways to do that w/o creating a dependcy on anything. > > 1) merge the drivers w/o the suspend_blockers. It's not rocket science > to have a patch which brings them back for android. Well, we sort of tried this when Greg pulled some of them into the staging tree. The problem is that without the annotations, the drivers are still different, and patches won't apply, so, unsurprisingly, they didn't get improved or even maintained. > 2) merge the drivers with empty stub implementations for annotation. > android just has to patch in the real one. That's also possible. This time, we would have a cosmetically closer tree ... however, what's in the kernel wouldn't be compilable for android ... which is where all the downstream wants to test, so they'd still be building for the android tree ... we just might have an easier time of it picking up their fixes. > While I'd prefer #1, I' not in the way of #2. I think 1 is unviable ... I'm not opposed to 2 but I'd like to try to get the kernel really closer to android before we go for the cosmetic only option. > Both ways can get the drivers into the kernel and it could/should have > been done right from the beginning, but now we face a situation where > drivers are held hostage. > > Then we can sit down more relaxed and fix the stuff in a way which > makes both sides happy. If we manage to replace them, we can deprecate > the stub implementation and remove it after a grace period. If we > rename them it's not an issue either. We can rename them right away to > a qos interface, but that does not really make a difference. > > What we really want to avoid is implementing an user space contract in > a frenzy which binds us forever. Well, that's why the QoS proposal ... it already has a userspace API ... we'd just be extending it for statistics, which looks like a wothwhile goal independent of android anyway. > It's not the suspend_blockers which are the causing the nightmare, > it's solely the drivers itself especially when there are different > implementations in both trees. And frankly, the drivers in android are > not in a shape which makes them flood in within 2 weeks. That's > serious work to get them brushed up and polished. So that gives us > quite a period of time to solve the suspend problem. Right, so the sooner we make it easier for the drivers to use the kernel as their main repository, the better. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Vitaly Wool on 6 Jun 2010 13:30 2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: > Suspend blocks prevent system suspend, not any per-device suspend. Can you suspend a device which is holding a wake lock? ~Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 6 Jun 2010 13:40
On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote: > 2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: > > > Suspend blocks prevent system suspend, not any per-device suspend. > > Can you suspend a device which is holding a wake lock? Yes. Suspend blocks are orthogonal to runtime PM. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |