On Tue, Dec 08, 2009 at 09:35:59PM -0500, Alan Stern wrote: > On Tue, 8 Dec 2009, Linus Torvalds wrote: > > It's just that I think the "looping over children" is ugly, when I think > > that by doing it the other way around you can make the code simpler and > > only depend on the PM device list and a simple parent pointer access. > I agree that it is uglier. The only advantage is in handling > asynchronous non-tree suspend dependencies, of which we probably won't > have very many. In fact, I don't know of _any_ offhand. There's some potential for this in embedded audio - it wants to bring down the entire embedded audio subsystem at once before the individual devices (and their parents) get suspended since bringing them down out of sync can result in audible artifacts. Depending on the system the suspend may take a noticable amount of time so it'd be nice to be able to run it asynchronously, though we don't currently do so. At the minute we get away with this mostly through not being able to represent the cases that are likely to actually trip up over it. > Interestingly, this non-tree dependency problem does not affect resume. Embedded audio does potentially - the resume needs all the individual devices in the subsystem and can take a substantial proportion of the overall resume time. Currently we get away with a combination of assuming that all the drivers are live when we decide to start resuming them and using the ALSA userspace API to deal with bringing the resume out of line, but it's not ideal. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
