On Sunday 06 December 2009, Rafael J. Wysocki wrote: > On Sunday 06 December 2009, Linus Torvalds wrote: > > > > On Sun, 6 Dec 2009, Rafael J. Wysocki wrote: > > > > > > The approach you're suggesting would require modifying individual drivers which > > > I just wanted to avoid. > > > > In the init path, we had the reverse worry - not wanting to make > > everything (where "everything" can be some subsystem like just the set of > > PCI drivers, of course - not really "everything" in an absolute sense) > > async, and then having to try to work out with the random driver that > > couldn't handle it. > > > > And there were _lots_ of drivers that couldn't handle it, because they > > knew they got woken up serially. The ATA layer needed to know about > > asynchronous things, because sometimes those independent devices aren't so > > independent at all. Which is why I don't think your approach is safe. > > While the current settings are probably unsafe (like enabling PCI devices > to be suspended asynchronously by default if there are not any direct > dependences between them), there are provisions to make eveything safe, if > we have enough information (which also is needed to put the required logic into > the drivers). The device tree represents a good deal of the dependences > between devices and the other dependences may be represented as PM links > enforcing specific ordering of the PM callbacks. > > > Just to take an example of the whole "independent devices are not > > necessarily independent" thing - things like multi-port PCMCIA controllers > > generally show up as multiple PCI devices. But they are _not_ independent, > > and they actually share some registers. Resuming them asynchronously might > > well be ok, but maybe it's not. Who knows? > > I'd say if there's a worry that the same register may be accessed concurrently > from two different code paths, there should be some locking in place. > > > In contrast, a device driver can generally know that certain _parts_ of > > the initialization is safe. As an example of that, I think the libata > > layer does all the port enumeration synchronously, but then once the ports > > have been identified, it does the rest async. > > > > That's the kind of decision we can sanely make when we do the async part > > as a "drivers may choose to do certain parts asynchronously". Doing it at > > a higher level sounds like a problem to me. > > The difference between suspend and initialization is that during suspend we > have already enumerated all devices and we should know how they depend on > each other (and we really should know that if we are to actually understand how > things work), so we can represent that information somehow and use it to do > things at the higher level. > > How to represent it is a different matter, but in principle it should be > possible. > > > > If you don't like that, we'll have to take the longer route, although > > > I'm afraid that will take lots of time and we won't be able to exploit > > > the entire possible parallelism this way. > > > > Sure. But I'd rather do the safe thing. Especially since there are likely > > just a few cases that really take a long time. > > And there are lots of small sleeps here and there that accumulate and are > entirely avoidable. I mean, it is avoidable to do all these sleeps sequentially. Thanks, 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
