On Wed, 9 Mar 2005, Benjamin Herrenschmidt wrote: > On Tue, 2005-03-08 at 09:13 -0800, Patrick Mochel wrote: > > > This would be doing something like partial-tree suspends, but I'm not sure > > if this is best done in the kernel or in userspace with a proper tool. > > Hrm... I think it's more complex than that. We need 2 way communication > between parents & childs. For example, if a parent is informed when a > child entered an idle-suspend state (local dynamic PM), it can enter > itself into some kind of suspend state when all it's offspring is in > such a state (like USB bus suspend when devices are idle, Apple does > that afaik, or did that in MacOS 9). > > But that means child -> parent notifications That seems pretty trivial to notify the parent. That doesn't have to be in the core; the low-level drivers could do that now.. > The more I think about it, the more I want to go toward something that > looks like what I described a while ago, taht is an array of states in > drivers (which also enables us to have driver provide meaningful state > names to sysfs, and to have user have something useful to write to > "power" entries in sysfs to trigger state transitions). > > This array would contain the state name, and eventually things like a > state enter function (unless we have a single change_state() callback ?) > and various infos describing the dependency between local states and bus > states (I'm still thinking about the simplest/cleanest way to describe > those, probably just a few bitfields with bit numbers matching bus state > numbers). I totally agree. I had started working on preliminary patches to do this about the time you posted something about it. Don't recall if I ever posted them. But, it started to get too complex too fast, without good insight of where to go.. > A device with "rich" PM features could expose several private state that > way, letting the user trigger them via sysfs. Yes. > One thing to keep in mind is the wakeup condition. With system-wide > suspend, it's a system-wide wakeup, while local suspend, it's a local > event. In the case described above of the USB bus, it's the child > activity that should trigger a resume request upward (and not downward) > the tree (thus bi-directional communication in the tree). Yes, on wake up, we need to walk the tree up until we find a parent that is awake, then walk back down, waking up the devices on the path to the target. Not Rocket Science, but trick to get right without the right support. > This is a bit difficult to set properly, but I'm convinced that if we > manage to define the model properly and bite the bullet with the > implementation issues (like locking), we can expose something that is > simple for drivers to use (which is the MAIN issue, or nobody will get > anything right). That's the key. :) > I want to avoid having as many system timers as drivers around, this > would impact system performances imho (we already have too many timers > bcs of things like netfilter afaik). Ugh, the number of timers impacts performance? I think I remember something like that. Well, we can see how bad it sucks and how poorly it scales, and if it's too bad, we can cheat (e.g. using 1 timer per bus/class/etc and internal checks, which might actually make the per-driver code a bit simpler in the long run). > What aboout a new IRC meeting to discuss those things ? Cool, how about weekly meetings at a specific time? And, with a specific agenda (like 1 item per person, stated before the meeting), so we stay focused and don't go too far over the alloted time? To be fair, we could pick 1 day (like Wednesday or Thursday), and rotate the time based on the timezones represented, so it's not always painful for each person. :) What timezones do we have? US Pacific: GMT - 08:00 US Eastern: GMT - 05:00 EU (Prague): GMT + 01:00 AU (Canberra): GMT + 10:00 Any others? Pat
