On Wednesday 05 August 2009, Zhang Rui wrote: > On Wed, 2009-08-05 at 01:33 +0800, Alan Stern wrote: > > On Tue, 4 Aug 2009, Rafael J. Wysocki wrote: > > > > > Not only that. I'd like to simplify the design, because IMO using one async > > > domain would be much more straightforward than using multiple ones. > > > > > If I understand the async framework correctly, the domains are only used for > > > synchronization, ie. if you want to wait for a group of async operations to > > > complete, you can put them all into one domain and then call > > > async_synchronize_full_domain() to wait for them all together. > > > > > > You don't need multiple domains to run multiple things in parallel. > > > > There's a basic confusion going on here. > > > > Rui is using "async domain" to mean a collection of devices which > > will be suspended or resumed serially. Different domains run in > > parallel. > > > > Rafael is using "async domain" to mean a collection of devices which > > will be suspended or resumed in parallel. Different domains run > > serially. > > > cool, thanks for stating the confusion so clearly, Alan. :) > > Hi, Rafael, > > maybe there is still some confusions about my proposal. > > I re-read kernel/async.c file, and notice that Arjan calls the domain as > *_synchronization_* domain. sorry I use the wrong word before. > > And I use the synchronization domains just to keep devices dependency. > > First, the general idea is to suspend/resume those slow devices in > parallel. So we don't suspend/resume them synchronously, instead, we > move these actions to the global domain. > > Then, I found that these actions can not be run asynchronously because > they depend on other devices. > For example, sd depends on SATA controller, we should make sure the PM > callbacks of sd and ahci sata controller are run serially. so a > synchronization domain is created for them. > This is how multiple synchronization domains come from in this proposal. I think I understand now, thanks. However, I'd like to avoid any naming confusion in future, so let's follow the convention of async.c, please. Best, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
