Re: Nested suspends; messages vs. states

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]

On Wednesday 23 March 2005 6:13 pm, Patrick Mochel wrote:
> 
> On Wed, 23 Mar 2005, David Brownell wrote:
> 
> > On Tuesday 22 March 2005 4:52 pm, Patrick Mochel wrote:
> > > >
> > > I think the core should always call ->suspend() for a device, regardless
> > > of whether it thinks it's in a low power state, or inactive. This is
> > > specifically for the reason that a device could be a low-power runtime
> > > state when the system is suspended.
> >
> > I don't quite see a need for this.  If the parent/bridge driver knows
> > the device is adequately suspended, why kick it again?  It's actually
> > rather annoying -- and error/bug prone! -- to have to code drivers to
> > detect and cope with superfluous suspend calls.
> 
> The call doesn't need to actually kick the device. It just needs to check
> some state field in the device object. My point was that the core
> shouldn't differentiate between not-suspended and suspended devices.

It just has devices that it calls suspend() for, and resume() for?
That could make sense.   Note that if it's not differentiating, then
it's not checking a state field... that task should IMO probably be
delegated to something that understands the relevant state fields.
(Like PCI code for PCI_D* states, USB code for USB states, etc.)


> Note that this point would be moot if we moved to a complete bus-centric
> view of the tree. We wouldn't care about individual devices; we would just
> call the bridge drivers, which could do their own checking on which
> devices were suspended and needed to be called. Note that that would be
> very trivial with lists of devices in each particular state, like I just
> suggested. :)

Well the data structure issues could be discussed a lot, but I basically
like that notion of pushing intelligence about "what is PM" into the
components that actually deal with hardware ... bridges, busses, hubs,
nexi, whatever you want to call them. 

We could call that "bus-centric" if you like, though there will be other
kinds of components with the intelligence too.

- Dave


 
> 
> 	Pat
> 

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]