On Wednesday 03 November 2004 20:43, Benjamin Herrenschmidt wrote:
> On Wed, 2004-11-03 at 19:31 -0700, David Brownell wrote:
> > I posted a sketch of how to do subtree suspends a while back,
> > which had the nice side consequence that this would work:
> >
> > static inline int in_suspend(struct device *dev)
> > {
> > return !list_empty(&dev->power.entry);
> > }
> >
> > Actually, we should need only one function for in_suspend()
> > and in_resume().
> >
> > I hope that nobody's assuming devices only suspend as part of
> > system sleep state transitions ... one device tree might be
> > suspending while another (or its parent!) is fully active...
>
> Yes, but as far as I'm concerned, in_suspend() should be
> in_system_suspend() (same for resume)
No reason there shouldn't be both. On the other hand,
keep in mind that the typical case with selective suspend
is going to be that usermode is there, and working just
fine ... if you're concerned with shutdown sequences
that need userspace to behave, one strategy would be
to quiesce more intelligently: shutting down as much
as possible *BEFORE* userspace can no longer assist.
> and I think we shouldn't rely on
> the lists.
I'm not keen on the lists except as a way to avoid
recursion blowing up kernel stacks ... and as part
of the mutual exclusion strategy that'll keep various
concurrent PM tasks from stomping on each other.
> For example, on STD, we should have in_system_suspend()
> return 1 when the processes have been put in the refrigerator, that is
> before we start walking the device-tree.
And on resume, in_system_resume() would be true until
userspace is available again ... just one call needed?
But I don't think any "quiesce the system" strategy
that works well on complex systems can be very simple.
The firmware example is just one case from its
class ... quiescing (plus resuming) a component
that needs help both from kernel (driver, ...) and
userspace (firmware or other services). Single phase
"kernel only" quiesce models have obvious holes.
A two phase model is probably necessary, though
we don't have one. (I hope two is enough, but
that gets into larger design issues.)
- Dave
>
> Ben.
>
>
>
