On Wednesday 12 August 2009, Alan Stern wrote:
> On Wed, 12 Aug 2009, Rafael J. Wysocki wrote:
>
> > Hi,
> >
> > The following patches introduce a mechanism allowing us to execute device
> > drivers' suspend and resume callbacks asynchronously during system sleep
> > transitions, such as suspend to RAM. The idea is explained in the [1/1] patch
> > message.
> >
> > Comments welcome.
>
> I get the idea. Not bad.
Thanks!
> Have you tried it in a serious way? For example, turning on the
> async_suspend flag for every device?
No, I've only tested it with a few selected drivers. I'm going to try the
"async everyone" scenario, though.
> In one way it isn't as efficient as it could be. You fire off a bunch
> of async threads and then make many of them wait for parent or child
> devices. They could be doing useful work instead.
I kind of agree, but then the patches would be more complicated.
> It would be interesting to invent a way of representing explicitly the
> non-tree dependencies -- assuming there aren't too many of them! (I
> can just hear the TI guys hollering about power and timer domains...)
I have an idea.
Every such dependency involves two devices, one of which is a "master"
and the second of which is a "slave", meaning that the "slave" have to be
suspended before the "master" and cannot be resumed before it. In principle
we could give each device two lists of "dependency objects", one containing
"dependency objects" where the device is the "master" and the other containing
"dependency objects" where the device is the "slave". Then, each "dependency
object" could be represented as
struct pm_connection {
struct device *master;
struct list_head master_hook;
struct device *slave;
struct list_head slave_hook;
};
Add some locking, helpers for adding / removing "dependency objects" etc.
and it should work. Instead of checking the parent, walk the list of
"masters", instead of walking the list of children, walk the list of "slaves".
The core could create those objects for parent-child relationships
automatically, the other ones would have to be added by platforms / bus types /
drivers etc.
This approach has a problem that it's prone to adding circular dependencies by
mistake, but then I think it would apply to any other approach just as well.
Best,
Rafael
--
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
