Re: [PATCH 06/13] PM: Implement early suspend api

Rafael J. Wysocki
2009-02-08T13:33:03Z

On Sunday 08 February 2009, Benjamin Herrenschmidt wrote:
> On Sat, 2009-02-07 at 23:47 +0100, Rafael J. Wysocki wrote:
> > On Thursday 05 February 2009, Arve Hjønnevåg wrote:
> > > Signed-off-by: Arve Hjønnevåg <arve@android.com>
> >
> > I don't really agree with this design, because I don't think it's suitable for
> > all bus types. Namely, if any bus type partially handles suspend-resume of
> > its devices to offload device drivers, I don't see how that is going to work
> > along with your design.
> >
> > You seem to require the drivers that will register the early resume handlers
> > to take care of everything, along with the operations that should really belong
> > to bus types. I don't think it's a good approach.
>
> More specifically, with the work you (Rafael) are doing at the moment,
> things like PCI or other low level busses would be fully restored in
> the early resume phase before drivers gets their resume_early.
> Henceforth, it would be possible for things like fbdev's etc... to
> resume from resume_early() which is probably soon enough.

That's correct IMO.

> Ie. I currently have this hack in radeonfb to resume it even before that
> while IRQs are still off etc... but it's a can of worms due to various
> might_sleep() hits in subsystems left and right (PCI, AGP, etc...).
>
> I'm actually thinking that when I migrate all of that to radeon DRM/KMS,
> I'll probably stick it all just in late_suspend/early_resume provided
> our plans to change the interrupt disabling go in and might_sleep()
> becomes safe in that phase.

I'm going to start working on the disabling of interrupts shortly.

> I don't see this Android early_suspend stuff fitting anywhere in that
> scheme... looks to me like some people hacked up some ad-hoc trick for
> their own local need without instead trying to figure out how to fit
> things with the existing infrastructure (or possibly propose changes to
> the existing infrastructure to fit their needs).

This also is my impression.

Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org