On Wednesday 23 March 2005 9:03 pm, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-23 at 18:45 -0800, David Brownell wrote:
>
> > If you've hogtied your system by forcing some devices ("busses") into
> > certain states that prevent others from working, it seems only fair to
> > me that it stay hogtied.
>
> No. For example, I'm a host controller. I notice I didn't get any
> request for a while, I want to enter a suspended state. That means going
> through dependencies of my childs so they can all enter a state
> compatible with me going to suspend.
That's a different example though: you've given the host controller
flexibility. You have _not_ hogtied it.
The model we seem to be aiming towards in USB land is a bit different
than that though. When autosuspend is the goal, it bubbles up from
the bottom ... nodes (like HC) don't force children into idle, they
wait for the children to idle themselves and then take the opportunity
to snooze themselves. That's a model with wide applicability...
> > I suspect you're actually agreeing with me there that some of the
> > drivers need flexibility to manage their power states. And maybe
> > even that such modes will be the main ones of interest...
> >
> > My answer to the question of how those parent/child dependency
> > details should be managed was to ensure that the parent can do
> > what it needs to. That is, decentralize those issues. I don't
> > understand why you seem to dislike that approach, when so many
> > of your examples seem to confirm it would work.
>
> I want to have the driver in control, yes. But I also want to have a
> core that removes the burden from driver writers in the "generic" cases.
> It's all a tradeoff to find :)
And I don't want to aim for an all-singing/all-dancing pm core that
really can't deliver what's needed, because it's trying to centralize
things that are easier to address in a decentralized way. :)
