On Wed, 26 May 2010, Linus WALLEIJ wrote: > Overall as a driver writer I'm quite confused at this point, if > I have a driver X, how is that code going to look if it is going > to support both runtime PM *and* suspend blockers? I don't say > it has to support both mechanisms in parallell, I'm even fine > with putting it in #ifdef:s, but how will the source code look? > A real-world example on a simple driver out of the Motorola Droid > git or so would help a lot. > > It's quite relevant since e.g. all OMAP drivers will need this > modification to be used with Android-like systems, and at > ST-Ericsson we will need both runtime PM and suspend blockers for > our drivers as well. It will as a consequence affect the drivers > for all ARM reference boards since we use the drivers for ARM > PrimeCells. etc... > > Now if this mechanism is going in, my main interest is that there > is some clearly cut way and design pattern for supporting both > runtime PM and suspend blocks. It's not difficult. You just have to decide what situations should block opportunistic suspend. For example, let's say that opportunistic suspend should be blocked when your event queue is non-empty. Then in the routine that adds new events to the queue, while still holding the spinlock that protects your queue, you enable your suspend blocker. Likewise, in the routine that takes events off the queue and sends them to userspace, while holding the spinlock you test whether the queue has become empty; if it has you disable your suspend blocker. That's all. No other changes are needed (except to create and destroy the suspend blocker, of course). No other interaction with suspend, resume, or runtime PM. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
