[PATCH 0/8] Suspend block api (version 6)
in [Kernel]
|
Prev: [PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending
Next: [PATCH 7/8] Input: Block suspend while event queue is not empty.
From: Mark Brown on 13 May 2010 18:30 On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote: > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: > > You get the driver mainlined, then maintain a small patch to add > > wakelocks. Not hard at all , with lots of incentive to do so since you > > don't have to maintain such a large block of code out of tree. > Sorry, but it doesn't seem to work that way. Look at the large number > of out-of-tree android device drivers that remain sitting there because > of the lack of this interface being in the kernel. Is that really the issue? The ones I've looked at have mostly suffered from being built on 2.6.29 and needing refreshes for current kernel APIs or from general code quality issues - I don't recall ever looking at one and thinking that the wakelocks were the one issue. > Also note that such a driver, without wakelocks, would never get tested, > and so, things start quickly diverging. Chances are that if the driver is useful people will start using it in non-Android systems anyway. As people have already observed wakelocks needn't have any practical effect on the running system so if the drivers are broken without wakelocks they'd be broken anyway. If this really is a big concern with getting drivers into mainline then surely we could just add some noop wakelock functions for the drivers to call? It's not particularly pretty but it'd deal with the driver merge side of things. -- 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: Woodruff, Richard on 13 May 2010 18:40 > From: linux-omap-owner(a)vger.kernel.org [mailto:linux-omap- > owner(a)vger.kernel.org] On Behalf Of Greg KH > Sent: Thursday, May 13, 2010 4:47 PM > Also note that such a driver, without wakelocks, would never get tested, > and so, things start quickly diverging. Do wakelock enabled drivers require a wakelock aware user space to function properly? If the driver is added you want to make sure the benefit is there and testable for all userspaces. Early Android service managers did take/release userspace locks to ensure the handoff worked. Getting all these drivers is positive. Getting to some constraint mechanism is positive. It does need to exist end to end to make a difference at the battery. Regards, Richard W. -- 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 13 May 2010 18:50 On Friday 14 May 2010, Mark Brown wrote: > On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote: > > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: > > > > You get the driver mainlined, then maintain a small patch to add > > > wakelocks. Not hard at all , with lots of incentive to do so since you > > > don't have to maintain such a large block of code out of tree. > > > Sorry, but it doesn't seem to work that way. Look at the large number > > of out-of-tree android device drivers that remain sitting there because > > of the lack of this interface being in the kernel. > > Is that really the issue? The ones I've looked at have mostly suffered > from being built on 2.6.29 and needing refreshes for current kernel APIs > or from general code quality issues - I don't recall ever looking at one > and thinking that the wakelocks were the one issue. > > > Also note that such a driver, without wakelocks, would never get tested, > > and so, things start quickly diverging. > > Chances are that if the driver is useful people will start using it in > non-Android systems anyway. You're missing the point IMO. Even if they are only used on Android, there still is a problem if they don't go into the mainline, because that leads to code divergence that's growing over time and will ultimately create an entire ecosystem that's independent of the mainline. We've been successful in avoiding that for quite some time and I don't think we should allow that to happen right now because of the opportunistic suspend feature. I'm not a big fan of suspend blockers myself, but let's face it, _currently_ there's no alternative and we need to stop the trend, the sooner the better. > As people have already observed wakelocks > needn't have any practical effect on the running system so if the > drivers are broken without wakelocks they'd be broken anyway. You need to prove the reverse, ie. that a driver working correctly with wakelocks will also work correctly without them, which is not a given. > If this really is a big concern with getting drivers into mainline then > surely we could just add some noop wakelock functions for the drivers to > call? Well, I don't see a big difference between that and adding the feature depending on a .config option. Really. > It's not particularly pretty but it'd deal with the driver merge > side of things. Again, I don't see why you hate that feature so much. What is there to worry about? 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: Greg KH on 13 May 2010 18:50 On Thu, May 13, 2010 at 11:27:49PM +0100, Mark Brown wrote: > On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote: > > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: > > > > You get the driver mainlined, then maintain a small patch to add > > > wakelocks. Not hard at all , with lots of incentive to do so since you > > > don't have to maintain such a large block of code out of tree. > > > Sorry, but it doesn't seem to work that way. Look at the large number > > of out-of-tree android device drivers that remain sitting there because > > of the lack of this interface being in the kernel. > > Is that really the issue? The ones I've looked at have mostly suffered > from being built on 2.6.29 and needing refreshes for current kernel APIs > or from general code quality issues - I don't recall ever looking at one > and thinking that the wakelocks were the one issue. Yes, it is an issue. See the mess that we have had in trying to get some of the original G1 drivers merged in the staging tree for proof of this. > > Also note that such a driver, without wakelocks, would never get tested, > > and so, things start quickly diverging. > > Chances are that if the driver is useful people will start using it in > non-Android systems anyway. No, not usually. Do you really think that someone else is going to use the G1 camera driver for anything else? :) > As people have already observed wakelocks needn't have any practical > effect on the running system so if the drivers are broken without > wakelocks they'd be broken anyway. > > If this really is a big concern with getting drivers into mainline then > surely we could just add some noop wakelock functions for the drivers to > call? It's not particularly pretty but it'd deal with the driver merge > side of things. I fail to see why getting the real functionality of the wakelocks into the kernel is a problem. Especially as they fit a real need, and work well for that. thanks, greg k-h -- 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: Arve Hjønnevåg on 13 May 2010 19:10
On Thu, May 13, 2010 at 3:46 PM, Greg KH <gregkh(a)suse.de> wrote: > On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote: >> >> > From: linux-omap-owner(a)vger.kernel.org [mailto:linux-omap- >> > owner(a)vger.kernel.org] On Behalf Of Greg KH >> > Sent: Thursday, May 13, 2010 4:47 PM >> >> > Also note that such a driver, without wakelocks, would never get tested, >> > and so, things start quickly diverging. >> >> Do wakelock enabled drivers require a wakelock aware user space to >> function properly? > > Not that I can tell, but others might know more. > Some of our drivers may not work correctly with forced suspend, but if you don't use suspend at all, the wakelocks have no effect and all the drivers will work correctly. >> If the driver is added you want to make sure the benefit is there and >> testable for all userspaces. > > Agreed. > > thanks, > > greg k-h > -- Arve Hj�nnev�g -- 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/ |