On Wed, 11 Apr 2007, Benjamin Herrenschmidt wrote: > > Is it feasible to improve sysdev handling to allow this? > > It would be an absolutely ugly hack imho... > > The trick to get the decrementer right is to really do it at the same > time as we turn irqs off... hence the idea to make the whole "turning > irqs off" platform specific to get the platform a chance to perform > whatever trickery is necessary after normal driver suspend and around > IRQ disabling. > > (In the decrementer case, it looks approx like: > 1- set decrementer to max value > 2- switch irqs off > 3- set decrementer to max value (again) > ) > > Along with that, we have all sort of platform specific hackery we need > to perform just before disabling IRQs on suspend and just after > re-enabling them on resume. That's really the simplest/easiest way to do > it. > > In fact, I'm pretty sure ACPI would love to use such a hook into as > well, in order to run all that motherboard stuff that needs to be able > to sleep, take semaphores, etc... before IRQs are off but after all > devices have suspended. > > sysdev's are just a pain in the neck if you ask me... Most of the > problems I've seen with cpufreq are due to the fact that it's a sysdev. > They were a bad idea in the first place and keep being abused :-) Have you guys considered using a notifier chain for this? The platform code could register itself on the chain at boot time. When suspending you send out notifications just before and just after disabling interrupts, and inversely on resume. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
