On Mon, 1 Aug 2005 david-b@xxxxxxxxxxx wrote: > > Date: Mon, 1 Aug 2005 17:58:42 -0700 (PDT) > > From: Patrick Mochel <mochel@xxxxxxxxxxxxxxxxxx> > > > > On Sat, 30 Jul 2005, Alan Stern wrote: > > > > > When a driver changes a device's state, it will notify all of the > > > power parents about link state changes while doing so. > > > > > These notifications are one-way, child-to-parent only. We don't need > > > pre- and post-notifications; each message will inform the parent of a > > > single link-state change, which the parent will then carry out. > > > > This may not be true. There could be a race between children notifying > > their parent of state changes if e.g. the states of two children are > > opposite and in the process of inverting (there is one suspended one that > > tries to resume, and one resumed device that tries to suspend). > > > > I haven't thought this all the way through, so it might just represent a > > glitch in performance rather than a potential error condition. Regardless, > > it's an implementation detail that I don't want to get bogged down with > > right now. > > This is specifically why when I did the USB suspend resume stuff > I adopted a tree-oriented lock chaining scheme. Everyone locks in > the same order ... whether suspending or resuming. It also ensures > a fully serialized (in the database sense) execution. You always need to lock in the same order to prevent deadlocks. The thing that isn't clear is how far we have to go to lock when suspending or resuming a device, especially if it has multiple parents. And, if it has multiple parents at the same level in the graph, then what order do we lock them in? Depending on the order by which we discover devices and associate them with their parents, these could very easily be in a different order from device to device. It could be nasty and/or confusing to get this right. I'm inclined at this point in the night to suggest just having a global Runtime suspend lock. > > We decided in Ottawa to create a completely seperate hierarchy for power > ^^^^^^^^^ > Hierarchy normally implies tree; power relations can be directed > acyclic graphs (DAGs). A device on some particular data bus > could need three power supplies, switched using devices on two > different busses; and also use two additional control or data > busses. I wouldn't want to model that as a tree, and might not > need to model quite everything in software anyway! I'll remember to use that word more judiciously. > I remember talking about the power network as orthogonal to the > current device model tree, but I don't remember that "it should > show up in sysfs" ever got discussed. However, I'm sure we did > talk about clocks as device power networks that would be fine as > orthogonal to the current logical/physical driver model tree, > and didn't seem to need to appear in sysfs either. > > Why would that power network need to be exported in sysfs? Why wouldn't it? The main reason I want it exported is that it's the closest thing to tangible objects that we have to collectively visualize the problem and the entities involved. We don't have a way to share foam + wire models (or white boards or play-doh). But, we do have filesystem entities that we can fiddle with and stare at until we a) find the bug we're trying to fix, b) implement the piece of necessary infrastructure we're fretting over, or c) figure out where and how the devices we're implementing support for fit in to the model. > Couldn't it be as transparent as the clock network? Why shouldn't the clocks be exported? Maybe more people would understand them a bit better if they were.. Pat
