Re: [linux-pm] Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code)
From: Rafael J. Wysocki
Date: Tue Jun 09 2009 - 19:09:38 EST
On Tuesday 09 June 2009, Oliver Neukum wrote:
> Am Montag, 8. Juni 2009 23:31:58 schrieb Rafael J. Wysocki:
> > If ->autosuspend() fails, the device power state may be known, but the core
> > can't be sure if the device is active. This information is available to
> > the driver and/or the bus type, which should change the status to whatever
> > is appropriate.
>
> That is quite confusing. You'd better define error returns.
That might work too, but the information need not be available to the driver
immediately. It may need to schedule a reset of the device to recover from
the error condition, for example.
> One that would mean that the suspension has failed but the device is
> unaffected, and another one that means that the device is in an
> undefined state now.
>
> > > The scheme doesn't include any mechanism for communicating runtime
> > > power information up the device tree. When a device is autosuspended,
> > > its parent's driver should be told so that the driver can consider
> > > autosuspending the parent.
> >
> > I thought the bus type's ->autosuspend() callback could take care of this.
>
> That can't work because you have to operate between busses.
OK, point taken.
> > > Likewise, if we want to autoresume a device below an autosuspended
> > > parent, the parent should be autoresumed first. Did you want to make the
> > > bus subsystem responsible for all of this?
> >
> > Yes, that was the idea.
>
> That is an important point. Can some subsytems operate with a parent still
> suspended?
OK, I see the value of doing that at the core level.
I tried to address this in the new version of the patch, which has been sent
in my last reply to Alan.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/