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: Matthew Garrett on 6 Jun 2010 13:50 On Sun, Jun 06, 2010 at 07:37:59PM +0200, Vitaly Wool wrote: > 2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: > > 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. > > That's nice, but that means that it can hold the wake lock > indefinitely. Brilliant design, I'd say. Putting a device in a low power state doesn't mean you can't run code in the driver. If a device generates an event and that event gets handled by the driver, the driver can take a suspend block and then release it when userspace reads the event. It's perfectly valid for the device to go into a low power state in the meantime. When I say that these things are orthogonal, I really do mean it. -- 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: Thomas Gleixner on 6 Jun 2010 14:10 James, On Sun, 6 Jun 2010, James Bottomley wrote: > 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. The downstream users will be bound to the android tree anyway until the full set of drivers for a given platform is completely merged. So optimistically that would be 2.6.36, which gives us a couple of months to sort out the whole thing. Once a driver is merged mainline and the android tree switched over to use the mainline version, fixes can be sent both ways and that's not a real problem. > > 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. Right, but there is no dependency for the driver merge on that. > > 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. Yep, the fastest way is to provide two stub inlines in pm.h and let the driver flood come in. I think all of us involved in that can do with a break, where we sit back, calm down and rethink w/o time pressure. Thanks, tglx -- 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: Brian Swetland on 6 Jun 2010 14:50 On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner <tglx(a)linutronix.de> wrote: >> >> Right, so the sooner we make it easier for the drivers to use the kernel >> as their main repository, the better. > > Yep, the fastest way is to provide two stub inlines in pm.h and let > the driver flood come in. As mentioned previously, we didn't know this was an option (stubs without an implementation behind them). If it is, and thus we can simplify the driver merging process short-term while sorting out a long-term implementation or replacement for suspend blockers, then I think we're making real progress. There is no reason that drivers that support suspend blockers cannot (or should not) support regular suspend/resume or runtime suspend/resume, so that shouldn't be a worry. The various operating modes complement, not compete with each other (we want the lowest possible power consumption in all states, be that fully active, fully suspended, or anything in between -- I think everyone involved agrees with this). > I think all of us involved in that can do with a break, where we sit > back, calm down and rethink w/o time pressure. Total agreement. Brian -- 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: Rafael J. Wysocki on 6 Jun 2010 15:10 On Sunday 06 June 2010, Matthew Garrett wrote: > 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. Yes, they are. The idea that they would somehow interfere with runtime PM has always been pure nonsense. They wouldn't and there's no way in which they could. Whether or not they are really necessary to address the Android requirements is a different question, though, and I don't really think so right now. At least not in the form submitted by Arve. Also, there's some overlap between suspend blockers and the PM QoS framework, so it seems to be a good idea to extend PM QoS (which already is in the kernel) to express some requirements that suspend blockers are supposed to express. Rafael -- 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: Christoph Hellwig on 6 Jun 2010 15:10
On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote: > 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. Err, the biggest pile in staging was meta drivers like the binder or some oom killer magic which are flat out braindead and wrong and have no chance going into mainline anyway. That's something different from real hardware drivers, although a few of those made it into staging as well if I remember correctly. -- 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/ |