late suspend/early resume

[Justin Hibbits]

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.
On May 13, 2013 12:19 PM, "Warner Losh" <imp at bsdimp.com> wrote:
>
>
> On May 13, 2013, at 1:14 PM, Julian Elischer wrote:
>
> > On 5/13/13 6:53 AM, Warner Losh wrote:
> >> Where is the northbridge in the object tree hierarchy?
> >>
> >> Since you are asking this, I'm guessing it isn't at the top of the
tree, and can't easily be.
> >>
> >> I don't like this idea. I think it is is silly and will lead only to
additional proliferation of late late late early late calls.
> >>
> >> Much better would be for the suspend routine to return a number
indicating how late to be called (and correspondingly how early resume
should be called). this way the tree walking code can insert these devices
into an ordered list that can then be walked at the end of suspend and
traversed backwards at the start of resume.
> >>
> >> There are many embedded systems where there's a bit of a partial
ordering between clock generation blocks and power blocks that need to be
handled specially since there's no ACPI on those platforms to do things
last. We don't model them well at all (or even at all), and having some
mechanism in place to help with that would be useful.
> >>
> >> So in short I understand the need, but feel that the kobj extensions
you propose are little better than the hard-coded calls and would like to
see something a little more generic since the in-order traversal of the
device tree seems a poor fit to 'special cases' like this.
> >
> > would not some dependency graph be more 'correct'?  not sure how one
would express it. Maybe by default it would go with the device hierarchy
but with the ability to add extra dependencies.
>
> A numeric value would completely encapsulate the graph and avoid loops in
said graph. Expressing the dependency graph would likely be a heavier lift
as well...
>
> Warner
>
> >> Warner
> >>
> >>
> >> On May 13, 2013, at 1:20 AM, Justin Hibbits wrote:
> >>
> >>> I'd like to solicit opinions on adding new kobj device API calls,
> >>> device_late_suspend and device_early_resume.
> >>>
> >>> I've been working on PowerPC suspend/resume, and certain devices must
be
> >>> suspended last and resumed first on Apple hardware, namely the
chipsets.
> >>> It happens that one device (uninorth) appears first in the devinfo
chain,
> >>> while the other (mac-io) appears off a later PCI bus.  So, rather than
> >>> special casing this to suspend the mac-io and its children, as well
as the
> >>> uninorth, last with specific calls, I'd like to add a
device_suspend_late
> >>> and device_resume_early, that would simply be identical to
> >>> device_suspend/device_resume, but could be called after and before,
> >>> respectively, to do last minute order suspend and first pass
> >>> initialization, to initialize things like clocks required for other
devices.
> >>>
> >>> It's not difficult to explicitly call suspend and resume functions on
the
> >>> chipsets, but I think it's cleaner to do it through the newbus/kobj
> >>> interface, and it might be useful for other architectures as well.
> >>>
> >>> Thoughts?
> >>>
> >>> - Justin