On Tue, May 11, 2010 at 06:11:09PM -0700, Arve Hj?nnev?g wrote: > > 2.2 Usage in PM aware drivers > > ============================== > > [An example of how a driver already using runtime PM would use > > ?a suspend blocker would also be helpful. > An audio driver can block suspend while audio is playing. We don't > currently use the runtime pm framework since this is new, but we do > runtime pm by turning off clocks and power when the device is > inactive. Could you clarify what's going on here please? What do you mean by an "audio driver" here - there's several different classes of driver which work together to produce the embedded audio subsystem and I'm not clear which you're referring to here. I'd not expect a chip-specific audio driver to be taking suspend blockers at all except during things like accessory detect handling which can take a long time. A system-specific driver could reasonably block during playback but doing it in a chip specific driver sounds like a bit too much of a policy decision. The kernel runtime PM framwwork tends not to come into play for anything except MFD and SoC drivers with audio where they're a component of PM on the larger chip and it's useful for coordinating with the other drivers in play. Otherwise we already have very detailed automatic power management (especially for the CODECs) and there's no benefit in bouncing through runtime PM. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
