On Wednesday 09 March 2005 6:23 am, Patrick Mochel wrote: > > On Wed, 9 Mar 2005, Benjamin Herrenschmidt wrote: > > > On Tue, 2005-03-08 at 09:13 -0800, Patrick Mochel wrote: > > > > 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.. Sort of true. The parent/child relationship are in the device tree, generally accessible. But there's no "notify" call to use ... that might be something to add to struct device_driver, along the lines of a notify(parent, child, some_event_descriptor). What sorts of notification are going to be needed? For USB there would be "I'm suspending", and that'd make sense for other kinds of bus too. > > 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.. I seem to remember suggesting the same thing, and being a bit surprised (and pleased!) to see the preliminary patches from Patrick. Agreed that we need to know "where to go". > > 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. And that support involves managing the same sorts of tree issues that USB has. Locking is one issue (maybe the driver model would be better farming out locking to bus or subsystem...) and managing the up/down traffic would IMO best involve common infrastructure rather than being entirely bus/subsystem specific (as it is today). > > What aboout a new IRC meeting to discuss those things ? > > Cool, how about weekly meetings at a specific time? Seems rather a lot. Maybe every other week; that'd give more folk time to get things done between meetings. It usually takes time to get useful results written up afterward, and then they'd need more general discussion/review ... > 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? What, get organized? Radical. Are you sure this is still Linux? :) - Dave > 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 >
