On Thu, May 13, 2010 at 3:46 PM, Greg KH <gregkh@xxxxxxx> wrote: > On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote: >> >> > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- >> > owner@xxxxxxxxxxxxxxx] 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. Drivers with correct wakelock usage will play nice with opportunistic suspend. If you're not using opportunistic suspend, you probably don't need wakelocks at all, and the driver (unless it's broken) should work just fine for you. >> If the driver is added you want to make sure the benefit is there and >> testable for all userspaces. > > Agreed. Definitely. The fact that say the dsp audio driver or serial driver on MSM use wakelocks to play nice with opportunistic suspend should have no impact on, say, Debian-on-G1 which is not using that feature. Debian would still be able to play audio or write to the serial port. With wakelock support in the kernel, I'm able to maintain drivers that (provided they meet the normal style, correctness, etc requirements) that both can be submitted to mainline (yay!) and can ship on production hardware as-is (yay!). Porting other linux based environments to hardware like G1, N1, etc becomes that much easier too, which hopefully makes various folks happy. This helps get us ever closer to being able to build a production-ready kernel for various android devices "out of the box" from the mainline tree and gets me ever closer to not being in the business of maintaining a bunch of SoC-specific android-something-2.6.# trees, which seriously is not a business I particularly want to be in. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
