On Mon, 1 Aug 2005, Leo L. Schwab wrote: > > Just so. The important point is that the parent notification and the > > device state change must happen in the correct relative order, and that > > order depends on the exact nature of the change. [ ... ] > > > > In each case there is only _one_ notification. It's not necessary for the > > child to notify the parent both before and after each individual state > > change. [ ... ] > > Agreed. Once the relative order is established, everything falls > out nicely. But how this relative order is established wasn't made clear. > If I were implementing it, it'd be one of the first things I'd want to know. The implementation is up to the individual driver. In general, drivers should change as much state of the device as they can, then notify the parent of changes needed for the link, then go on modifying the device, then notify the parent of any more changes needed, and so on. Specific cases ought to be very clear-cut; it's pretty obvious when you're changing power levels at what points you need help from your parent. > > I don't understand this comment at all. Lots of things happen > > periodically in the kernel: threads wake up, timers go off... Are you > > suggesting that, for example, the page-flush thread shouldn't wake up > > from time to time either? > > > Of course not. However (one presumes) the page-flush thread doesn't > wake up every second, scan its entire list of candidate pages only to find > nothing ready to do yet, and go back to sleep again. (Off-topic: I don't know how the page-flush thread is implemented these days. Didn't it use to work exactly like that?) > Sweeping through a list of idle timeouts in a thread isn't likely to > consume a lot of CPU, but it could blow some cache lines doing it (not to > mention eating some battery). If the CPU can be put to sleep waiting for a > timeout, I believe it's worth doing. The thread wouldn't necessarily have to sweep through a list of idle timeouts. It could instead maintain a partially-sorted list (a heap, for example) where the earliest timeout always comes first. Of course, it then amount to little more than a special-purpose, poor-man's version of the kernel timer routines... I'm not sure this would be any better than just using timers. Contrariwise, if the CPU is asleep then who cares if we blow some cache line? But I agree that we want to minimize the overhead, particularly since we are supposed to be _saving_ power... :-) > > > If you wanted to get really fancy, you could establish via a > > > userspace API a named "device collection" [ ... ] > > > > I suspect that's fancier than we need, although perhaps it would come in > > handy in special circumstances. For now, it should be good enough to > > restrict such "device collections" to be subtrees of the device tree. > > > I was thinking of possibly useful cases where "conceptually related" > devices may be convenient to treat as a single group, but are located on > disparate busses. One example that comes to mind would be to spin down all > available graphics cards (which may be located on the AGP bus, PCI bus, and > USB bus). This may be one of those special circumstances. Alan Stern
