[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: Brian Swetland on 13 May 2010 19:30 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. 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-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: Mark Brown on 13 May 2010 19:40 On Fri, May 14, 2010 at 12:46:33AM +0200, Rafael J. Wysocki wrote: > On Friday 14 May 2010, Mark Brown wrote: > > 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. .... > > 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. See my first paragraph there. My point here is that we appear to have the standard vendor BSP ecosystem problem here rather than a wakelock problem. It's fairly common in the embedded space to get a whole bunch of work done which doesn't make its way into mainline due to a SoC vendor having produced a BSP for their SoC which is based around a particular kernel version which never gets updated. This means users with that SoC can't boot anything newer until someone does the work of mainlining support for the system, meaning that development on systems using that SoC gets stuck on an old kernel which mainline drifts away from. Users find it hard to contribute back since they can't run current code easily and often have to jump through serious hoops to backport drivers from newer kernels. If the SoC is successful enough then you do get something of an ecosystem around the BSP, though eventually that usually results in the community doing the mainline merge. > 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. This is still a work in progress in the embedded space (where wakelocks are primarily relevant). Many of the major vendors are working in the right direction here, but it's far from universal and it's not something that it's easy for vendors to change overnight. > 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. I don't think this is a major part of the trend - like I say, the fact that people have been working with an old kernel version is generally a much more substantial issue than the wakelocks in the code I've seen. > > 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 they can be compiled out then the updates really ought to be trivial. If not I really need to go back and reexamine what's going on here to make sure I understand what drivers are supposed to do, I have to confess that I haven't looked too closely at the driver side API yet. > > 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? As I have said previously I'm not actively opposed to merging wakelocks at this point. My major concern has been addressed, I now agree with most of what the PM guys are saying - it's not the nicest thing ever but it works for now. The issue was that when I originally noticed the patch series was being considered for mainline again was that one effect of using it in a mobile phone with the standard Linux embedded audio subsystem would be to break use cases such as audio on voice calls, which isn't really desirable, and that there was no roadmap for how to fix that or any other subsystems with similar issues. This didn't seem like it would have been a good situation given that the major user is expected to be Android, which is mainly for mobile phones. Since we seemed to all agree that no other subsystems were affected, meaning nothing general was required, I've now implemented support in the subsystem for ignoring suspends for some audio paths (this should appear In the next merge window). This should mesh well with wakelocks. -- 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 13 May 2010 19:50 On Thu, May 13, 2010 at 4:36 PM, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > >> 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. > > I don't think this is a major part of the trend - like I say, the fact > that people have been working with an old kernel version is generally > a much more substantial issue than the wakelocks in the code I've seen. Current published trees are based on .32 (used for the coming-soon froyo release that's been in late QA for a while now) and forward development is moving to .34 post final (or in the case of tegra2, tracking .34-rc series as it happens). We've been actively snapping up to track mainline since we started doing this around 2.6.16. We'd *love* to be able to get more stuff sanely upstream instead of maintaining branches and rebasing every other mainline release or so. > The issue was that when I originally noticed the patch series was being > considered for mainline again was that one effect of using it in a > mobile phone with the standard Linux embedded audio subsystem would be > to break use cases such as audio on voice calls, which isn't really > desirable, and that there was no roadmap for how to fix that or any > other subsystems with similar issues. This didn't seem like it would > have been a good situation given that the major user is expected to be > Android, which is mainly for mobile phones. I'd love to have a separate discussion on using standard linux embedded audio for mobile devices -- one of my goals for 2010 is to try to migrate from our "one off" approach on MSM to making use of ALSA and standard interfaces. I have a lot of questions about handing encoded data (mp3/aac/etc) that will be processed by the DSP, how to approach routing control, and how to best interact with the user/kernel interface, etc. 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: Mark Brown on 13 May 2010 20:10 On Thu, May 13, 2010 at 03:45:03PM -0700, Greg KH wrote: > 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: > > 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. Ah, that's surprising - I had thought most of the issues there were due to the substantial MSM architecture core code which most of the G1 stuff depended on (things like the DSP interface and so on) and the general need for staging-style updates which churned against the non-mainline versions rather than the wakelocks. It's true that the wakelocks weren't helping, though. Most of the cases I've seen have been off-CPU drivers that were either working to outdated APIs or having to jump through hoops because they really wanted to use new kernel features rather than CPU things. > > 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? :) Not if it's genuinely G1 specific, although presumably most of that driver is actually chip drivers for the various components of a camera subsystem which may well appear in other systems (not that I have the slightest bit of familiarity with how camera hardware is organised). > > 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. Well, like I've said I personally don't object to merging them now that the audio use case has been sorted. I suggested this because it would allow something to be put in place to facilitate driver merging which would avoid the core and userspace issues that people are still raising with the implementation and let people get on with at least the driver side. If wakelocks don't make the next merge window and there is a problem with drivers then it'd be nice to get the stubs in so that the APIs are present in subsystem trees for drivers to merge. -- 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: Mark Brown on 13 May 2010 20:40
On Thu, May 13, 2010 at 04:48:40PM -0700, Brian Swetland wrote: > On Thu, May 13, 2010 at 4:36 PM, Mark Brown > Current published trees are based on .32 (used for the coming-soon > froyo release that's been in late QA for a while now) and forward > development is moving to .34 post final (or in the case of tegra2, > tracking .34-rc series as it happens). We've been actively snapping > up to track mainline since we started doing this around 2.6.16. We'd Yeah, I had noticed the development stuff was more up to date - it'll be good once it gets out of QA and into general use since system integrators do seem to pick up your new releases fairly quickly. > *love* to be able to get more stuff sanely upstream instead of > maintaining branches and rebasing every other mainline release or so. Having greatly cut down the number of out of tree drivers I'm carrying I can only say that it's great when it happens :) > I'd love to have a separate discussion on using standard linux > embedded audio for mobile devices -- one of my goals for 2010 is to > try to migrate from our "one off" approach on MSM to making use of Probably best to do that, this thread is already quite big enough without going off on a tangent. FWIW we can usually be found in #alsa-soc on freenode as well as on the lists. A couple of pointers which might help your research, though: > ALSA and standard interfaces. I have a lot of questions about handing > encoded data (mp3/aac/etc) that will be processed by the DSP, how to This usually doesn't go through ALSA at all (the ALSA APIs can't cope with variable bitrate data), the data currently goes via DSP specific APIs and gets injected into the ALSA domain in much the same way as data from the baseband. > approach routing control, and how to best interact with the > user/kernel interface, etc. Routing control for embedded systems is done by exposing the routing control to userspace via ALSA controls which can be set by apps - using a GUI to configure the routes interactively is a massive usability win in development. Abstraction for generic user-visible apps is intended to be handled by a layer on top of that: http://www.slimlogic.co.uk/?p=40 which is currently in development but I believe is expected to come to fruition this year (Liam is driving this one). -- 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/ |