> Date: Mon, 1 Aug 2005 10:07:27 -0400 (EDT) > From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > > On Sun, 31 Jul 2005, Leo L. Schwab wrote: > > Besides, in the case of USB, you may not have any power at all until you > > notify the parent bus/hub manager to wake up. > > 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. A really complicated > state change might even require multiple intermediate parent > notifications, or separate notifications to multiple parents. For the example of a USB hub, usb_suspend_device(dev) effectively turns into "dev->parent, suspend device on your port N". Likewise, usb_resume_device(dev) turns into a "parent, resume port N". That's not a model I'd expect all PM linkages in Linux to fit in. Likewise, the current infrastructure has sufficed to achieve that. I believe that we can usefully talk about the "links" between a power domain and its managed children, but expect it will work best as more of a set of design patterns than a code library. (Folk do still get degrees in what's effectively just integrating new sorts of links into the web... most drivers should be simpler than a PhD!) > > > Or should the RTPM kernel thread > > > wake up every second to scan a list of devices that may have exceeded > > > their idle timeouts? > > If we have a kernel thread working like this, then there's no need for a > lot of kernel timers. Maybe low precision timers (LPET) would help? Upcoming LPET ticks could be rescheduled to maximize power savings ... the data structures are going to be much the same regardless of whether timers, workqueues, or LPET get used. - Dave
