> 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.
> > Practical considerations
> >
> > Power-parent relations: How should we represent the extra power
> > parent-child relationships that aren't present in the device tree?
> > Would it be enough to give each device that needs it a subdirectory in
> > sysfs with symlinks to its power parents? Do we also need a symlink
> > from each parent to the child?
>
> 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!
> relationships. This will coexist with the device tree and will, by virtue
> of the kernel infrastructure, be automatically represented in sysfs. There
> will of course be symlinks connecting the physical tree with the power
> tree.
>
> The fact that some devices will have multiple ancestral dependencies is a
> problem that we must solve with the right data structure. I'm not sure of
> the best way to do it, but it shouldn't be too hard.
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?
Couldn't it be as transparent as the clock network?
- Dave
