Suspend block api (version 6)
in [Kernel]
|
Prev: mm: fix race between shift_arg_pages and rmap_walk
Next: [PATCH -next] power: fix block_io.c printk warning
From: Alan Stern on 6 May 2010 10:10 On Wed, 5 May 2010, Brian Swetland wrote: > > Probably generalizing these into the LDM is the direction to go so > > userspace can set constraints on a per-device (or per-class?) basis: > > > > /sys/devices/.../power/constraint/throughput > > /sys/devices/.../power/constraint/wakeup_latency > > /sys/devices/.../power/constraint/... ? > > The constraint stuff is definitely something I'd love to talk about in > detail. It's a problem that I think is common to every SoC I've > worked with. Having a general solution for this problem (of > specifying and observing various constraints for clock, power, qos, > etc) kernel-wide would seem like a big win. > > Might be worth kicking some design ideas around and getting a bunch of > the interested parties together at some of the upcoming linux > conference things this fall on the east coast? The Linux Power-Management Summit is scheduled for August 9, at the start of the LinuxCon meeting in Boston. This would make an excellent topic for discussion. Alan Stern -- 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 May 2010 15:30 On Thursday 06 May 2010, Alan Stern wrote: > On Wed, 5 May 2010, Brian Swetland wrote: > > > > Probably generalizing these into the LDM is the direction to go so > > > userspace can set constraints on a per-device (or per-class?) basis: > > > > > > /sys/devices/.../power/constraint/throughput > > > /sys/devices/.../power/constraint/wakeup_latency > > > /sys/devices/.../power/constraint/... ? > > > > The constraint stuff is definitely something I'd love to talk about in > > detail. It's a problem that I think is common to every SoC I've > > worked with. Having a general solution for this problem (of > > specifying and observing various constraints for clock, power, qos, > > etc) kernel-wide would seem like a big win. > > > > Might be worth kicking some design ideas around and getting a bunch of > > the interested parties together at some of the upcoming linux > > conference things this fall on the east coast? > > The Linux Power-Management Summit is scheduled for August 9, at the > start of the LinuxCon meeting in Boston. This would make an excellent > topic for discussion. Agreed. 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: Mark Brown on 7 May 2010 06:10 On Wed, May 05, 2010 at 09:25:18PM -0700, Arve Hj�nnev�g wrote: > On Wed, May 5, 2010 at 4:40 PM, Mark Brown > > This really does depend heavily on system design and the intended > > function of the suspend on the part of the initiator. �In many systems > > suspend will remove sufficient power to stop audio running even if it > > were desired, and there's the idea with existing manually initiated > > suspends that the system should stop what it's doing and go into a low > > power, low responsiveness state. �Some systems will initiate a suspend > > with active audio paths (especially those to or from the AP) which they > > expect to be stopped. > You can support both in the same driver in some cases (without a > switch). If the hardware cannot wake the system when it needs more > audio buffers, then the driver needs to block suspend while audio is > playing. Since suspend blockers only block opportunistic suspend, the > driver can also implement suspend to stop audio playback and it will > only be called for forced suspend. As discussed elsewhere in the thread a suspend blocker is not desirable here - the AP is not doing anything useful on a voice call so blocking the suspend will just waste power unless runtime PM is good enough to mean opportunistic suspend isn't adding anything anyway. It will avoid the immediate issue with loosing audio but it's not really what we want to happen. -- 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 7 May 2010 07:00 2010/5/7 Mark Brown <broonie(a)opensource.wolfsonmicro.com>: > On Wed, May 05, 2010 at 09:25:18PM -0700, Arve Hj�nnev�g wrote: >> On Wed, May 5, 2010 at 4:40 PM, Mark Brown > >> > This really does depend heavily on system design and the intended >> > function of the suspend on the part of the initiator. �In many systems >> > suspend will remove sufficient power to stop audio running even if it >> > were desired, and there's the idea with existing manually initiated >> > suspends that the system should stop what it's doing and go into a low >> > power, low responsiveness state. �Some systems will initiate a suspend >> > with active audio paths (especially those to or from the AP) which they >> > expect to be stopped. > >> You can support both in the same driver in some cases (without a >> switch). If the hardware cannot wake the system when it needs more >> audio buffers, then the driver needs to block suspend while audio is >> playing. Since suspend blockers only block opportunistic suspend, the >> driver can also implement suspend to stop audio playback and it will >> only be called for forced suspend. > > As discussed elsewhere in the thread a suspend blocker is not desirable > here - the AP is not doing anything useful on a voice call so blocking > the suspend will just waste power unless runtime PM is good enough to > mean opportunistic suspend isn't adding anything anyway. �It will avoid > the immediate issue with loosing audio but it's not really what we want > to happen. > I was talking about audio from the AP. Why would you ever turn off another core's audio path on suspend? -- 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/
From: Mark Brown on 7 May 2010 07:30
On Fri, May 07, 2010 at 03:57:37AM -0700, Arve Hj�nnev�g wrote: > 2010/5/7 Mark Brown <broonie(a)opensource.wolfsonmicro.com>: > > As discussed elsewhere in the thread a suspend blocker is not desirable > > here - the AP is not doing anything useful on a voice call so blocking > > the suspend will just waste power unless runtime PM is good enough to > > mean opportunistic suspend isn't adding anything anyway. �It will avoid > > the immediate issue with loosing audio but it's not really what we want > > to happen. > I was talking about audio from the AP. Why would you ever turn off > another core's audio path on suspend? This goes back to the thing about a full system suspend being a sledgehammer which doesn't give enough information about what's going on when it's used like this. As discussed we need a way to know that the connections involved are able to stay live during suspend (on a large proportion of systems suspend is going to mean that the relevant bits of the board will loose power so need to be shut down) and that that the intention of the user is that they should do so (this isn't clear in the general system, especially not if the suspend is initiated manually). With a runtime PM approach this is trivial - we just turn off anything that isn't in use at the current time. I'll need to extend ASoC to add information about what to do on suspend to the existing power data. -- 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/ |