Hi! > > That it is same old hack it used to be. There's nothing magic about > > decrementer, and I do not think it is _neccessary_ to touch it just > > before cli. Just disable it from sysdev handler or something. > > No, you cannot disable it from sysdev handler because you have to be > able to take interrupts. Can we *please* move on to some more productive > discussion? So what happens if you disable it as a platform device? There has to be better solution than this. What is so special about decrementer? We were able to handle MTRR registers on PC. Timer setup fit into the model too... > > > > @@ -135,9 +135,19 @@ typedef int __bitwise suspend_disk_metho > > > > * @prepare: Prepare the platform for the given suspend state. Can return a > > > > * negative error code if necessary. > > > > * > > > > + * @quiesce: This callback is called after devices are suspended but before > > > > + * they are powered down. If assigned, this callback must at least turn > > > > + * off local IRQs. If left unassigned, a default callback that does > > > > + * nothing but turn off local IRQs is assigned during pm_set_ops(). > > > > Is it called for s2ram? swsusp? uswsusp? > > Whoops, I had that in an earlier version, it's not supposed to be called > for (u)swsusp because pm_ops involvement there is a hack anyway. I'll > fix the description. But (u)swsusp needs to shut down the devices, and it does both suspend and powerdown, too...? 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
