late suspend/early resume

[Justin Hibbits]

On Thu, May 23, 2013 at 10:11 PM, Warner Losh <imp at bsdimp.com> wrote:

>
> On May 23, 2013, at 11:08 PM, Justin Hibbits wrote:
>
> > John,
> >
> >
> > On Wed, May 15, 2013 at 3: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
> >>
> >
> > I have an update in the projects/pmac_pmu branch.  It works for my
> > PowerBook, but I'm not certain how well it will fare in the end, because
> of
> > the way the PCI driver resumes its children.  It doesn't call
> > bus_generic_resume(), and instead suspends each child individually, which
> > can lead to devices being resumed multiple times, but I'm uncertain how
> to
> > fix that.  Any ideas?  One I had was to have some kind of
> > 'bus_generic_resume_filtered' or similar, that lets bus_generic_resume
> run
> > its logic, but filter through a function to determine if the child is
> > resumable.  But that doesn't quite feel right to me.
>
> How does it lead there? Did you change the suspend/resume function
> signatures? Or did you create new ones like I suggested that had a default
> method that called the old suspend/resume function iff pass was the last
> one....
>
>
> Warner
>
>
I must've misunderstood you during our discussion.  I simply reused the
existing bus_generic_suspend/resume, and used EAGAIN to pass a token of
'rescan this again'.

- Justin