late suspend/early resume

[Justin Hibbits]

On Wed, May 15, 2013 at 6:56 AM, John Baldwin <jhb at freebsd.org> wrote:

> On 5/14/13 1:14 PM, Justin Hibbits wrote:
> > You are right that the late suspend could lead to silly proliferation,
> and
> > an ordered list is much better, but another API would need to be added to
> > do that as well.
> >
> > My north bridge is first in the top list of the tree, right under the
> > nexus, so to suspend it last I wrote the nexus suspend to traverse its
> > children in reverse. The problem comes that the clock controller is
> under a
> > later PCI bus, not even the immediate following one, and the north bridge
> > children are i2c devices, so suspending them after their clock head away
> is
> > problematic.  We can discuss this more at bsdcan, where it may be easier
> to
> > describe. But essentially I need the north bridge and that pesky clock
> > controller to be the last to suspend and the first to resume. I guess we
> > can take this as the starting discussion for modeling this relationship
> on
> > all platforms, since you mention it is common in embedded platforms.
>
> I think you can do this by having a notion of passes with drivers having
> a suspend pass level and doing passes over the tree suspending devices
> at each pass level and then walking the passes back up in reverse during
> resume.  You could borrow from the multipass stuff used on probe/attach
> for this.
>
> --
> John Baldwin


Here's a (very) rough cut of what I think you're getting at.  It uses the
existing pass identifier to convey the current pass number, and walks the
pass in reverse for suspend, and forwards for resume.  However, I can't
stress enough, that I only compiled it, I have no hardware here at BSDCan
to test, so I have no idea if it will work as expected.

The basic idea is to start at the last pass number, and any device can
suspend and resume if able, or can check and return EAGAIN if it's not
ready to suspend itself (it can still suspend its children if it wants).  I
could also add to bus_generic_resume() a check for the device's driver's
pass wrt bus_current_pass, as in the probe code.

Is this what you're thinking?

- Justin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: suspend.diff
Type: application/octet-stream
Size: 3068 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130516/f05c0039/attachment.obj>