On Thursday, 12 April 2007 13:23, Benjamin Herrenschmidt wrote: > On Thu, 2007-04-12 at 12:16 +0200, Pavel Machek wrote: > > > Adding platform hook to disable interrupts just because we need one > > platform device last is not nice, either. (And does decrementer even > > need to come last?) > > > > Anyway, platform devices may need specific ordering on more than power > > pc, so perhaps we should just make ordering more stable so that > > relying on it is no longer a hack? > > It would be pretty hard to do cleanly without raping the core driver > suspend/resume core. Agreed. > I have experience implementing suspend/resume in all sorts of > environments, and I do strongly beleive that an arch hook right at this > point will be useful to more than that anyway. > > There are actions the arch code might need to take after drivers and > before going to "atomic" mode (irqs off mean you can no longer sleep or > take semaphores etc...), and in a similar vein, actions to take on > resume just after interrupts are back and before all the drivers get > woken up. > > The decrementer is one example, there might be other processor specific > bits or arch specific bits that are better done at that stage. > > I think the way to go for 2.6.22 is to have that hook unless you can > propose me a way to cleanly provide a platform device that is guaranteed > to suspend last and resume first in all cases (and even then, I wouldn't > be that happy since the proper decrementer stop procedure involves > really wrapping the "irqs off" operation). > > Why not give this added flexibility ? Archs who don't care don't need to > bother and it will make us happy... it's not like we are about to -add- > burden to other architectures. Well, I think it would be reasonable to add the quiesce()/activate() hooks for all of the above reasons. However, once we've done that, it'll be quite difficult to remove them, so we should better be sure they are really really needed and there's no other way to implement what you need (or all of the alternative ways are far worse). Greetings, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
