Hi! > Ok, PowerPC Decrementer 101 (Thanks for explanation). > Now, in addition to that, we have some weird motherboard stuff we need > to turn off/on, which has to be done after drivers (because it renders > various busses inaccessible in some cases, and might cause DMA snooping > to stop working, I'm not 100% sure, but I know for sure it has to be > done late) but can't be done as a sysdev because we need some > infrastructure like the i2c stuff (and others) that requires semaphores > and timers. It's based on something remotely akin to AML in that we have > to execute "scripts" provided by the firmware and the code to do so need > to run in an environment where scheduler & timers are operating. Does the "weird motherboard" stuff need to be suspended/resumed for swsusp memory snapshot? > For all those reasons, I do think that the proper, clean and incremental > approach to get our stuff working is to have that pair of hooks allowing > us to "replace" the local_irq_disable/enable calls... > > Now it does not need to be pm_ops. I'm fine with arch_pm_irq_quiesce() > kind of thing (or find a better name if you can, maybe Well, I guess arch_pm_irq_quiesce_for_s2ram() would be acceptable... but that would be only called for s2ram... which should be enough for decrementer AFAICT. > It's basically about quiescing the scheduler/timers, which on powerpc > (bcs of the way the DEC operates) requires a little bit more than just a > call to local_irq_disable. And once the hook is there, use it for some > other arch specific bits that we can't quite fit anywhere else at the > moment. As decrementer is special for s2ram, we can add the hook. (It is single hook). If we need to do something for snapshots, too... well, we can still add arch_pm_irq_quiesce_for_snapshot() and arch_pm_irq_quiesce_for_powerdown() etc, but it would get ugly fast. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
