late suspend/early resume

[Warner Losh]

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